Weird crash w/ MGA + RandR 1.2

[Tilman Sauerbeck]

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?

Regards,
Tilman

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20070307/341e93e9/attachment.pgp>