If firefox loads a large image (say the 32888x90 from the original bug report), cairo fails to create it and whole browser crashes with X error. Firefox used to check maximal image size and didn't allow to create such kind of images. The check seems to be gone now. Backtrace: #0 gfxPlatformGtk::CreateOffscreenSurface (this=0x808ee48, size=@0x8ee34b0, imageFormat=gfxASurface::ImageFormatRGB24) at gfxPlatformGtk.cpp:121 #1 0x01d5651a in gfxPlatform::OptimizeImage (this=0x808ee48, aSurface=0x8ee34a0, format=gfxASurface::ImageFormatRGB24) at gfxPlatform.cpp:241 #2 0x01b9fae2 in nsThebesImage::Optimize (this=0x8f133d8, aContext=0x0) at nsThebesImage.cpp:335 #3 0x01d3408f in gfxImageFrame::SetMutable (this=0x8ecb800, aMutable=0) at gfxImageFrame.cpp:191 #4 0x00fef454 in term_source (jd=0x8ee301c) at nsJPEGDecoder.cpp:1009 #5 0x01d7a711 in jpeg_finish_decompress (cinfo=0x8ee301c) at jdapimin.c:478 #6 0x00ff0a41 in nsJPEGDecoder::ProcessData (this=0x8ee3000, data=0x8c3a044 "Cn\rI\026\n#c�\001�@)j?N�s{+\177�ƽ*\003\226{��'�J\021��XR\225�D\\n\221�����\231}m\223�%% h�\t\"�\020?\217��\\\005�\230�Q>\206�?\030\221h�i$�n����\"d\204CS\bDMHk\207\001$�~H߶<8T\205)��.#YR\024\r���7^�5$\235�J�Ol@f\027\024�F\205\024l\203�6��|a�y\2351�μ<�\231JvF�\200��I'����\230�c��B\027�\016!Z·��\034��0H�\177��nsM"..., count=197, writeCount=0xbfee22f0) at nsJPEGDecoder.cpp:643 #7 0x00ff0bca in ReadDataOut (in=0x8e807ec, closure=0x8ee3000, fromRawSegment=0x8c3a044 "Cn\rI\026\n#c�\001�@)j?N�s{+\177�ƽ*\003\226{��'�J\021��XR\225�D\\n\221�����\231}m\223�%% h�\t\"�\020?\217��\\\005�\230�Q>\206�?\030\221h�i$�n����\"d\204CS\bDMHk\207\001$�~H߶<8T\205)��.#YR\024\r���7^�5$\235�J�Ol@f\027\024�F\205\024l\203�6��|a�y\2351�μ<�\231JvF�\200��I'����\230�c��B\027�\016!Z·��\034��0H�\177��nsM"..., toOffset=4096, count=197, writeCount=0xbfee22f0) at nsJPEGDecoder.cpp:248 #8 0x01cc0648 in nsPipeInputStream::ReadSegments (this=0x8e807ec, writer=0xff0b9e <ReadDataOut>, closure=0x8ee3000, count=197, readCount=0xbfee2580) at nsPipe3.cpp:799 #9 0x00fef2fa in nsJPEGDecoder::WriteFrom (this=0x8ee3000, inStr=0x8e807ec, count=4293, writeCount=0xbfee2580) at nsJPEGDecoder.cpp:266 #10 0x00fe1eb1 in imgRequest::OnDataAvailable (this=0x821da28, aRequest=0x8221ee0, ctxt=0x0, inStr=0x8e807ec, sourceOffset=0, count=4293) at imgRequest.cpp:861 #11 0x00fdcbbf in ProxyListener::OnDataAvailable (this=0x8ec9248, aRequest=0x8221ee0, ctxt=0x0, inStr=0x8e807ec, sourceOffset=0, count=4293) at imgLoader.cpp:877 #12 0x01440e34 in nsMediaDocumentStreamListener::OnDataAvailable (this=0x8ea5680, request=0x8221ee0, ctxt=0x0, inStr=0x8e807ec, sourceOffset=0, count=4293) at nsMediaDocument.cpp:115 #13 0x01867f81 in nsDocumentOpenInfo::OnDataAvailable (this=0x8ea9d68, request=0x8221ee0, aCtxt=0x0, inStr=0x8e807ec, sourceOffset=0, count=4293) at nsURILoader.cpp:306 #14 0x00e07cc6 in nsBaseChannel::OnDataAvailable (this=0x8221eb0, request=0x8e856c0, ctxt=0x0, stream=0x8e807ec, offset=0, count=4293) at nsBaseChannel.cpp:650 #15 0x00e18ad5 in nsInputStreamPump::OnStateTransfer (this=0x8e856c0) at nsInputStreamPump.cpp:508 #16 0x00e1902f in nsInputStreamPump::OnInputStreamReady (this=0x8e856c0, stream=0x8e807ec) at nsInputStreamPump.cpp:398 #17 0x01cc2574 in nsInputStreamReadyEvent::Run (this=0x8e965c8) at nsStreamUtils.cpp:111 #18 0x01ceb7f9 in nsThread::ProcessNextEvent (this=0x80a64c0, mayWait=1, result=0xbfee2900) at nsThread.cpp:510 #19 0x01c876fd in NS_ProcessNextEvent_P (thread=0x80a64c0, mayWait=1) at nsThreadUtils.cpp:227 #20 0x01b8088e in nsBaseAppShell::Run (this=0x8180868) at nsBaseAppShell.cpp:170 #21 0x01921381 in nsAppStartup::Run (this=0x823ce80) at nsAppStartup.cpp:181 #22 0x00d70e04 in XRE_main (argc=2, argv=0xbfee60d4, aAppData=0x80681f0) at nsAppRunner.cpp:3170 #23 0x08049316 in main (argc=2, argv=0xbfee60d4) at nsXULStub.cpp:364

dupe of bug 390768?

Yep. is it.

The patch in bug 424333 fixes this.