Weird crash w/ MGA + RandR 1.2
tilman at code-monkey.de
Wed Mar 7 11:23:48 PST 2007
Tilman Sauerbeck [2007-02-23 08:14]:
> Program received signal SIGSEGV, Segmentation fault.
> 0x081b9301 in damagePaintWindow (pWindow=0x8290758, prgn=0xbfc4f694, what=0) at
> 1645 if ((what != PW_BACKGROUND || pWindow->backgroundState != None) &&
> (gdb) bt
> #0 0x081b9301 in damagePaintWindow (pWindow=0x8290758, prgn=0xbfc4f694, what=0)
> #1 0x08128050 in compPaintWindowBackground (pWin=0x8290758, pRegion=0xbfc4f694,
> #2 0x08149f05 in miWindowExposures (pWin=0x8290758, prgn=0xbfc4f694, other_expo
> #3 0x080787e5 in MapWindow (pWin=0x8290758, client=0x8260790) at window.c:2829
> #4 0x080737c9 in InitRootWindow (pWin=0x8290758) at window.c:537
> #5 0x0806f91b in main (argc=1, argv=0xbfc4f7c4, envp=0xbfc4f7cc) at main.c:430
> I haven't checked what exact code path is chosen in
> getDrawableDamageRef(), but the PixmapPtr that it returns doesn't have a
> valid devPrivates field (valgrind complains about an invalid read).
I called fbScreenInit() with the "width" parameter being 0.
That in turn causes miCreateScreenResources() to not creating a pixmap
at all - instead, pScreen->devPrivate is set to pScrInitParms->pbits.
Whatever that is, it's not a pointer to a pixmap.
The fb layer doesn't seem to know about this limitation, which leads to
the above described crash.
So, should fbScreenInit() reject a zero width parameter?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Q: What is the most annoying thing on usenet and in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the xorg