X crashes when Browse views http://wiki.laptop.org/go/Hardware_specification

[tomeu]

seems like mozilla requests a pixmap too big for the available memory, then X tries to free the failed pixmap (NULL).

Program received signal SIGSEGV, Segmentation fault.
XvDestroyPixmap (pPix=0x0) at xvmain.c:348
348	  pScreen = pPix->drawable.pScreen;
(gdb) bt
#0  XvDestroyPixmap (pPix=0x0) at xvmain.c:348
#1  0x0808119f in ProcCreatePixmap (client=0x9450950) at dispatch.c:1342
#2  0x08085dbf in Dispatch () at dispatch.c:454
#3  0x0806b63d in main (argc=7, argv=0xbfa7c494, envp=0x0) at main.c:441
(gdb) l
343	  XvAdaptorPtr pa;
344	  int na;
345	  XvPortPtr pp;
346	  int np;
347	
348	  pScreen = pPix->drawable.pScreen;
349	
350	  SCREEN_PROLOGUE(pScreen, DestroyPixmap);
351	
352	  pxvs = (XvScreenPtr)dixLookupPrivate(&pScreen->devPrivates, XvScreenKey);
(gdb) up
#1  0x0808119f in ProcCreatePixmap (client=0x9450950) at dispatch.c:1342
1342	    (*pDraw->pScreen->DestroyPixmap)(pMap);
(gdb) l
1337		    return rc;
1338		}
1339		if (AddResource(stuff->pid, RT_PIXMAP, (pointer)pMap))
1340		    return(client->noClientException);
1341	    }
1342	    (*pDraw->pScreen->DestroyPixmap)(pMap);
1343	    return (BadAlloc);
1344	}
1345	
1346	int

I guess XvDestroyPixmap should check the state of the pointer, but I guess that depends on the X conventions.

We should check if upstream has already fixed this and in that case backport the fix.

[tomeu]

Maybe we can ask mozilla not to request too big pixmaps via #7078 , but I guess we want to fix any bugs that kill X.

[erikos]

I tested this bug with the wikiactivity which has the cache size set to 5000 but it crashed anyway.

[cjb]

Tomeu/Simon -- I wouldn't expect setting the RAM *cache* lower to affect loading an image on a current page. The cache specifies how many images to keep in RAM only.

[tomeu]

Well, if you have a maximum cache size of 50MB and are already using 48MB, I hope mozilla won't try to allocate a 10MB pixmap. But that may not be how it is implemented, yeah.

[jg]

What in the world is Xv doing involved in dealing with that page?

This stinks of something else going on...

[dsd]

I'll work on this

[dsd]

avoiding the DestroyPixmap call when there is a NULL pixmap avoids the issue.

Browse still crashes on the Hardware page, but at least it does not kill X, and this is not a regression over 8.1 (browse crashes there too)

Sent an xserver patch upstream: http://lists.freedesktop.org/archives/xorg/2008-September/038155.html

[dsd]

Patch accepted upstream, fixed in xorg-x11-server-1.4.99.906-2.olpc3.3

[dsd]

Tested, works fine (Browse crashes like it does in 8.1, but at least it does not kill X)

Please approve xorg-x11-server-1.4.99.906-2.olpc3.3 for 8.2

Changelog:

• Fix an X server crash when it cannot satisfy a large memory allocation request

|TestCase|

Open http://wiki.laptop.org/go/Hardware_specification in browse, confirm that X does not crash (note that Browse may be unresponsive for a while, this is not a regression)

[cscott]

Added to stable repo; please test in build 758 and following.

[dsd]

Confirmed working in build 759: X no longer crashes.

Instead, Browse freezes for a long time (there are other tickets for this) or it crashes quickly with BadAlloc (#8326). This is the same as it was on update1.

[frances]

tested http on 3 different computers, all connected to the xstest/school server and there was no delay or crash. Smooth sailing.

[frances]

Replying to frances:

tested http on 3 different computers, all connected to the xstest/school server and there was no delay or crash. Smooth sailing.

tested on 8.2-759

[dsd]

This isn't fixed, we just made the hardware page images smaller. This page will still exhibit the bug: http://dev.laptop.org/~seth/crashX.html