reliable crash on http://www.gronet.pl/ [@ nsImageGTK::UpdateCachedImage] [@ XCreatePixmap]

RESOLVED WORKSFORME

Status

Core Graveyard
GFX: Gtk
--
critical
RESOLVED WORKSFORME
11 years ago
4 years ago

People

(Reporter: Andrzej Mendel, Unassigned)

Tracking

({crash, pp})

1.8 Branch
PowerPC
Linux
crash, pp

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(1 attachment, 1 obsolete attachment)

9.76 KB, text/plain
Details
(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; en; rv:1.8.1.1) Gecko/20061201 Epiphany/2.16 Firefox/2.0.0.1 (Ubuntu-feisty)
Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; pl-PL; rv:1.8.1.1) Gecko/20061201 Firefox/2.0.0.1 (Ubuntu-feisty)

Firefox reliably crashes on http://www.gronet.pl/ All I need to do is enter the site and after few moments it dies. I'm attaching gdb backtrace (with debugging symbols) I managed to get. Epiphany also dies this way.
However, this only happens on this system (That is Ubuntu Feisty on PPC). I've tried to reproduce this crash on Ubuntu system on i386 and WinXP (the later in Qemu), but to no avail.

Reproducible: Always

Steps to Reproduce:
1. Enter www.gronet.pl
Actual Results:  
Browser crashes

Expected Results:  
Browser displays content
(Reporter)

Comment 1

11 years ago
Created attachment 253116 [details]
backtrace

Comment 2

11 years ago
There is an object on that page asking for Flash 6.0.29, do you have flash installed? Do you use Flash-blocking extensions?

http://www.gronet.pl/swf/dombezzobowiazan.swf

Updated

11 years ago
Attachment #253116 - Attachment mime type: application/octet-stream → text/plain

Updated

11 years ago
Severity: normal → critical
Component: General → GFX: Gtk
Keywords: crash, pp
Product: Firefox → Core
QA Contact: general → gtk
Version: unspecified → 1.8 Branch

Comment 3

11 years ago
in the future, please fill in steps to reproduce with more details
step one is:

firefox --sync -g -d gdb

in this case, because you *are* running with --sync, that means that what we see in the stack really is relevant.

also, your actual results should clearly include the output you get when firefox quits (it doesn't crash, it's killed by gdk in response to the xerror).
Whiteboard: DUPEME
(Reporter)

Comment 4

11 years ago
Created attachment 253157 [details]
The better backtrace

kelner@luther:~/Geek/firefox-crash-gdk$ firefox --sync -g -d gdb
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) Quit
(gdb) quit
kelner@luther:~/Geek/firefox-crash-gdk$ LD_LIBRARY_PATH=/usr/lib/debug firefox --sync -g -d gdb
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-linux-gnu"...
Using host libthread_db library "/usr/lib/debug/libthread_db.so.1".
(gdb) break gdk_x_error
Function "gdk_x_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (gdk_x_error) pending.
(gdb)  handle SIG33 noprint nostop
Signal        Stop      Print   Pass to program Description
SIG33         No        No      Yes             Real-time event 33
(gdb) run
Starting program: /usr/lib/firefox/firefox-bin --sync -d gdb -a firefox
[Thread debugging using libthread_db enabled]
[New Thread 805526032 (LWP 16827)]
Breakpoint 2 at 0xf87e2cc: file gdkmain-x11.c, line 607.
Pending breakpoint "gdk_x_error" resolved
[Switching to Thread 805526032 (LWP 16827)]

Breakpoint 2, gdk_x_error (display=0x1003bfc0, error=0x7f905e5c)
    at gdkmain-x11.c:607
607     gdkmain-x11.c: No such file or directory.
        in gdkmain-x11.c
Current language:  auto; currently c
(gdb) continue
Continuing.

Breakpoint 2, gdk_x_error (display=0x1003bfc0, error=0x7f905e5c)
    at gdkmain-x11.c:607
607     in gdkmain-x11.c
(gdb) continue
Continuing.

Breakpoint 2, gdk_x_error (display=0x1003bfc0, error=0x7f905e5c)
    at gdkmain-x11.c:607
607     in gdkmain-x11.c
(gdb) continue
Continuing.
[New Thread 815256752 (LWP 16845)]
[New Thread 823645360 (LWP 16850)]
[New Thread 832455856 (LWP 16870)]
[New Thread 855864496 (LWP 16892)]
[New Thread 864253104 (LWP 16893)]
[New Thread 873247920 (LWP 16894)]
[Thread 873247920 (LWP 16894) exited]
[New Thread 873247920 (LWP 16924)]
[New Thread 881636528 (LWP 16925)]
[New Thread 890025136 (LWP 16926)]
[New Thread 898413744 (LWP 16927)]
[Thread 890025136 (LWP 16926) exited]
[Thread 898413744 (LWP 16927) exited]
[New Thread 898413744 (LWP 16932)]
[New Thread 890025136 (LWP 16933)]
[Thread 898413744 (LWP 16932) exited]
[New Thread 898413744 (LWP 16940)]
[New Thread 906802352 (LWP 16941)]
[New Thread 915223728 (LWP 16948)]
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)

Breakpoint 2, gdk_x_error (display=0x1003bfc0, error=0x7f9057ac)
    at gdkmain-x11.c:607
607     in gdkmain-x11.c
(gdb) bt
#0  gdk_x_error (display=0x1003bfc0, error=0x7f9057ac) at gdkmain-x11.c:607
#1  0x0f7570a4 in _XError (dpy=0x1003bfc0, rep=0x7f905880)
    at ../../src/XlibInt.c:2890
#2  0x0f7595b8 in _XReply (dpy=0x1003bfc0, rep=0x7f905880, extra=0, discard=1)
    at ../../src/XlibInt.c:1819
#3  0x0f74e71c in XSync (dpy=0x1003bfc0, discard=0) at ../../src/Sync.c:48
#4  0x0f74e968 in _XSyncFunction (dpy=0x1003bfc0) at ../../src/Synchro.c:37
#5  0x0f7268f8 in XCreatePixmap (dpy=0x1003bfc0, d=<value optimized out>, 
    width=<value optimized out>, height=<value optimized out>, 
    depth=<value optimized out>) at ../../src/CrPixmap.c:58
#6  0x0f87fe10 in IA__gdk_pixmap_new (drawable=0x10048018, width=8190, 
    height=48, depth=24) at gdkpixmap-x11.c:175
#7  0x0d92bd14 in nsImageGTK::UpdateCachedImage (this=0x10b18bb8)
    at nsImageGTK.cpp:1614
#8  0x0d92bf64 in nsImageGTK::Optimize (this=0x1003bfc0, aContext=0x7f9057ac)
    at nsImageGTK.cpp:1932
#9  0x0d947ec8 in gfxImageFrame::SetMutable (this=<value optimized out>, 
    aMutable=<value optimized out>) at gfxImageFrame.cpp:168
#10 0x0d9f6024 in imgContainerGIF::DecodingComplete (
    this=<value optimized out>) at imgContainerGIF.cpp:216
#11 0x0d9f3cbc in nsGIFDecoder2::EndGIF (aClientData=0x10d340e0, 
    aAnimationLoopCount=0) at nsGIFDecoder2.cpp:316
#12 0x0d9f2bfc in gif_write (gs=0x109d4f54, buf=<value optimized out>, len=0)
---Type <return> to continue, or q <return> to quit---
    at GIF2.cpp:979
#13 0x0d9f4590 in nsGIFDecoder2::ProcessData (this=0x10d340e0, 
    data=0x7f9057ac "", count=0, _retval=0x7f905b64) at nsGIFDecoder2.cpp:230
#14 0x0d9f4628 in ReadDataOut (in=<value optimized out>, closure=0x1003bfc0, 
    fromRawSegment=0x7f9057ac "", toOffset=<value optimized out>, count=0, 
    writeCount=0xb) at nsGIFDecoder2.cpp:172
#15 0x0fe5e0fc in nsInputStreamTee::WriteSegmentFun (in=0x1003bfc0, 
    closure=0x10d33c30, fromSegment=0x0, offset=2140166220, count=0, 
    writeCount=0xb) at nsInputStreamTee.cpp:102
#16 0x0fe64aac in nsPipeInputStream::ReadSegments (this=0x10d35848, 
    writer=0xfe5e0c0 <nsInputStreamTee::WriteSegmentFun(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*)>, closure=0x10d33c30, 
    count=1750, readCount=0x7f905c78) at nsPipe3.cpp:763
#17 0x0fe5e278 in nsInputStreamTee::ReadSegments (this=0x0, 
    writer=<value optimized out>, closure=0x35, count=2140166220, 
    bytesRead=0x0) at nsInputStreamTee.cpp:156
#18 0x0d9f4ae0 in nsGIFDecoder2::WriteFrom (this=0x10d340e0, inStr=0x1003bfc0, 
    count=2140166220, _retval=0x0) at nsGIFDecoder2.cpp:250
#19 0x0d9ef2f0 in imgRequest::OnDataAvailable (this=0x10d35050, 
    aRequest=0x7f905c3c, ctxt=<value optimized out>, inStr=0x10d33c30, 
    sourceOffset=0, count=1750) at imgRequest.cpp:897
#20 0x0d9ea6e4 in ProxyListener::OnDataAvailable (this=<value optimized out>, 
    aRequest=0x7f9057ac, ctxt=0x0, inStr=0x7f90584c, sourceOffset=0, count=11)
---Type <return> to continue, or q <return> to quit---
    at imgLoader.cpp:890
#21 0x0ea37ba0 in nsStreamListenerTee::OnDataAvailable (this=0x10d33de8, 
    request=0x10d34aa4, context=0x0, input=<value optimized out>, offset=0, 
    count=1750) at nsStreamListenerTee.cpp:97
#22 0x0eaaaba4 in nsHttpChannel::OnDataAvailable (this=0x10d34a78, 
    request=<value optimized out>, ctxt=<value optimized out>, 
    input=0x10d35848, offset=<value optimized out>, count=1750)
    at nsHttpChannel.cpp:4213
#23 0x0ea14780 in nsInputStreamPump::OnStateTransfer (this=0x10d35998)
    at nsInputStreamPump.cpp:494
#24 0x0ea14924 in nsInputStreamPump::OnInputStreamReady (this=0x10d35998, 
    stream=0x7f9057ac) at nsInputStreamPump.cpp:397
#25 0x0fe6642c in nsInputStreamReadyEvent::EventHandler (
    plevent=<value optimized out>) at nsStreamUtils.cpp:120
#26 0x0fe8be0c in PL_HandleEvent (self=0x10d359f4) at plevent.c:688
#27 0x0fe8c244 in PL_ProcessPendingEvents (self=0x10096f68) at plevent.c:623
#28 0x0fe8ee8c in nsEventQueueImpl::ProcessPendingEvents (this=0x10095880)
    at nsEventQueue.cpp:417
#29 0x0e766438 in event_processor_callback (source=<value optimized out>, 
    condition=2140166060, data=0x0) at nsAppShell.cpp:67
#30 0x0f0e8650 in g_io_unix_dispatch (source=0x10606ba0, 
    callback=0xe766410 <event_processor_callback>, user_data=0x0)
    at giounix.c:162
---Type <return> to continue, or q <return> to quit---
#31 0x0f0b45d4 in IA__g_main_context_dispatch (context=0x1004ae50)
    at gmain.c:2045
#32 0x0f0b8278 in g_main_context_iterate (context=0x1004ae50, block=1, 
    dispatch=1, self=<value optimized out>) at gmain.c:2677
#33 0x0f0b86e4 in IA__g_main_loop_run (loop=0x10606a80) at gmain.c:2881
#34 0x0fa81f84 in IA__gtk_main () at gtkmain.c:1171
#35 0x0e7669a8 in nsAppShell::Run (this=0x1012efe0) at nsAppShell.cpp:139
#36 0x0e4cdc20 in nsAppStartup::Run (this=0x101333e8) at nsAppStartup.cpp:151
#37 0x10007ea8 in XRE_main (argc=<value optimized out>, 
    argv=<value optimized out>, aAppData=<value optimized out>)
    at nsAppRunner.cpp:2444
#38 0x10003e88 in main (argc=268681152, argv=0x7f9057ac) at nsBrowserApp.cpp:61
#39 0x0f447d40 in generic_start_main (main=0x10003e60 <main>, argc=6, 
    ubp_av=0x7f906724, auxvec=0x7f9067dc, init=<value optimized out>, 
    fini=<value optimized out>, rtld_fini=<value optimized out>, 
    stack_end=<value optimized out>) at ../csu/libc-start.c:231
#40 0x0f447f98 in __libc_start_main (argc=6, ubp_av=0x7f906724, 
    ubp_ev=<value optimized out>, auxvec=0x7f9067dc, 
    rtld_fini=0x3000ee70 <_dl_fini>, stinfo=0x10013208, 
    stack_on_entry=0x7f906710)
    at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:127
#41 0x00000000 in ?? ()
(gdb) continue
Continuing.
[Thread 832455856 (LWP 16870) exited]
[Thread 855864496 (LWP 16892) exited]
The program 'Gecko' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 44046 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Program exited with code 01.
(gdb)
Attachment #253116 - Attachment is obsolete: true
(Reporter)

Comment 5

11 years ago
I do not have flash installed, as it's a Linux/PPC system. I am using AdBlock, but the site crashes even after disabling it. I keep this site backed up in case it changes.
Please correct me if I'm doing something wrong. I'm not yet used to Bugzilla nor very familiar with gdb.

Comment 6

11 years ago
#6  0x0f87fe10 in IA__gdk_pixmap_new (drawable=0x10048018, width=8190, 
    height=48, depth=24) at gdkpixmap-x11.c:175

Indicates it dies trying to allocate memory for a 8190x48 image.  I wouldn't normally expect that to be enough to take it down, but that's what's happening.  And I don't see such an image on the site.  Just loading the image should be sufficient to crash and this would be bug 210931.

Comment 7

11 years ago
out of curiosity, what is your xserver?
(Reporter)

Comment 8

11 years ago
It's a standard X.org XServer. Ubuntu package version: 1:1.1.1-0ubuntu13

Comment 9

11 years ago
some of us don't speak ubuntu, nor should we have to. that version number is meaningless. what version is the xserver, what color depth is it running, and how big is its current memory footprint? heck, about how many windows do you have open? does it happen if you use a new user w/ nothing else running?

also, if you've saved a copy of the site, could you try finding all the .gif's in your saved copy and loading them one at a time in your firefox? hopefully one of them will cause it to quit. when you find the one, you could attach it here. if that doesn't happen but the locally saved copy does cause firefox to quit, you should try removing parts of the html file until you have a file with as little html as possible and as few external images as possible (should be one).

when you're done, attach the image to bugzilla, and change the web page to reference the attached image, verify it still crashes, and attach the web page.
(Reporter)

Comment 10

11 years ago
I can't reproduce this since the last update of XServer and Firefox. Should I try to downgrade any of these to try again, or is it not worth the effort?
(Assignee)

Updated

9 years ago
Product: Core → Core Graveyard

Comment 11

8 years ago
Not worth the effort unless you think a lot of people are (still) hitting this crash, IMO.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
Summary: reliable crash on http://www.gronet.pl/ → reliable crash on http://www.gronet.pl/ [@ nsImageGTK::UpdateCachedImage] [@ XCreatePixmap]
(Assignee)

Updated

7 years ago
Crash Signature: [@ nsImageGTK::UpdateCachedImage] [@ XCreatePixmap]

Updated

4 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.