Closed Bug 238401 Opened 20 years ago Closed 19 years ago

crash view largish image

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Version:
1.7 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 295457

People

(Reporter: bobbell, Assigned: pavlov)

References

(
URL
)

Details

(Keywords: crash) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040220 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040220 Firefox/0.8

When I open up any of several largish JPGs (~2.5 MB), Firefox crashes.  I was
trying to open the images in firefox for its "resize-to-fit" functionality.

Reproducible: Always
Steps to Reproduce:
1. Open any of several largish images

Actual Results:  
Firefox crashes

Expected Results:  
Displayed the image

Output from running with -g:
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 10809 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) 


Also, this may be a duplicate of bug 40931.  I don't know, but I thought I'd let
someone more knowledge than me about X/Gdk make that call.
dupe of "Valid (but huge) images crash mozilla in nsImageGTK::Init"

*** This bug has been marked as a duplicate of 166862 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: crash
Resolution: --- → DUPLICATE
I don't think this is a duplicate of 166862.  The images aren't *that* big. 
They are all 3400x4680 and the JPGs range in size from 1.9mb to 3.9 mb.  Also,
the error looks different: I get some kind of X error followed by an exit, not
the stack trace in that bug.

$ identify Angle\ Ball\ * X-Games.jpg Exercise\ Incognito.JPG 
Angle Ball a.jpg JPEG 3400x4680+0+0 PseudoClass 256c 8-bit 2.3mb 0.000u 0:01
Angle Ball b.jpg[1] JPEG 3400x4680+0+0 PseudoClass 256c 8-bit 2.1mb 0.000u 0:01
X-Games.jpg[2] JPEG 3400x4680+0+0 PseudoClass 256c 8-bit 1.9mb 0.000u 0:01
Exercise Incognito.JPG[3] JPEG 3400x4680+0+0 DirectClass 8-bit 3.9mb 0.000u 0:01
Reopening bug based on previous comment, as I do not believe that this is a
duplicate of the indicated problem, and it appears that comments don't get sent
when a bug is the the RESOLVED state.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
> I don't think this is a duplicate of 166862.  The images aren't *that* big. 
> They are all 3400x4680 and the JPGs range in size from 1.9mb to 3.9 mb.  Also,
> the error looks different: I get some kind of X error followed by an exit, not
> the stack trace in that bug.

right.

if the image is not big enough to make |new| fail, you can still crash because
gtk/gdk is happy to try to allocate its own (possibly larger) buffers, fail and
then crash.  So this is not really a Mozilla bug -- unless you have a stacktrace
showing Mozilla crash (in Mozilla's code).
I got the same error (and the crash) on
  http://danpat.net/~danpat/svn-graph/graph2.png
(5547x10065, 4 bit, 300k).

greux:~> mozilla file:///home/lefevre/graph2.png
Finished ReadPrefs OK
Finished ReadPrefs OK
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 3942 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.)
zsh: exit 1     mozilla file:///home/lefevre/graph2.png

It no longer generates a core dump, but the first time Mozilla crashed on this
image, I got one. Though the backtrace is not very readable, perhaps you could
get some information from it:

(gdb) backtrace 
#0  0x400ef780 in raise () from /lib/tls/libpthread.so.0
#1  0x41e26344 in ?? ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libprofile.so
#2  0x00000006 in ?? ()
#3  0x41e246aa in NSGetModule ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libprofile.so
#4  <signal handler called>
#5  0x4074cee9 in raise () from /lib/tls/libc.so.6
#6  0x4085af2c in ?? () from /lib/tls/libc.so.6
#7  0x407014d0 in vtable for std::bad_alloc () from /usr/lib/libstdc++.so.5
#8  0x4074e781 in abort () from /lib/tls/libc.so.6
#9  0x00000000 in ?? ()
#10 0x00000020 in ?? ()
#11 0x00000000 in ?? ()
#12 0x00000000 in ?? ()
#13 0x00000000 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0x00000000 in ?? ()
#17 0x00000000 in ?? ()
#18 0x00000000 in ?? ()
#19 0x00000000 in ?? ()
#20 0x00000000 in ?? ()
#21 0x00000000 in ?? ()
#22 0x00000000 in ?? ()
#23 0x00000000 in ?? ()
#24 0x00000000 in ?? ()
#25 0x00000000 in ?? ()
#26 0x00000000 in ?? ()
#27 0x00000000 in ?? ()
#28 0x00000000 in ?? ()
#29 0x00000000 in ?? ()
#30 0x00000000 in ?? ()
#31 0x00000000 in ?? ()
#32 0x00000000 in ?? ()
#33 0x00000000 in ?? ()
#34 0x00000000 in ?? ()
#35 0x00000000 in ?? ()
#36 0x00000000 in ?? ()
#37 0x00000000 in ?? ()
#38 0x00000000 in ?? ()
#39 0x00000000 in ?? ()
#40 0x00000000 in ?? ()
#41 0x00000000 in ?? ()
#42 0x00000000 in ?? ()
#43 0x00000000 in ?? ()
#44 0x00000000 in ?? ()
#45 0x09844246 in ?? ()
#46 0xbfffdf00 in ?? ()
#47 0x404b7c80 in ?? ()
#48 0x4238058d in nsImageGTK::Init ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libgfx_gtk.so
#49 0x406f0f84 in std::terminate () from /usr/lib/libstdc++.so.5
#50 0x406f10f6 in __cxa_throw () from /usr/lib/libstdc++.so.5
#51 0x406f134f in operator new () from /usr/lib/libstdc++.so.5
#52 0x406f141f in operator new[] () from /usr/lib/libstdc++.so.5
#53 0x4238058d in nsImageGTK::Init ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libgfx_gtk.so
#54 0x423a7074 in gfxImageFrame::~gfxImageFrame ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libgfx_gtk.so
#55 0x41caab62 in NSGetModule ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libimglib2.so
#56 0x41cee553 in png_push_have_info () from /usr/lib/libpng12.so.0
#57 0x41cec998 in png_push_read_chunk () from /usr/lib/libpng12.so.0
#58 0x41cec6a6 in png_process_some_data () from /usr/lib/libpng12.so.0
#59 0x41cec62c in png_process_data () from /usr/lib/libpng12.so.0
#60 0x41caa7ab in NSGetModule ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libimglib2.so
#61 0x40c02c69 in nsInputStreamTee::WriteSegmentFun ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/libxpcom.so
#62 0x40c06852 in non-virtual thunk to nsPipeInputStream::QueryInterface(nsID
const&, void**) () from /home/lefevre/mozilla/lib/mozilla-1.8a4/libxpcom.so
#63 0x09d74800 in ?? ()
#64 0x0ae44508 in ?? ()
#65 0x0904ddd4 in ?? ()
#66 0x00000000 in ?? ()
#67 0x00000444 in ?? ()
#68 0xbfffe224 in ?? ()
#69 0x00000001 in ?? ()
#70 0x00000046 in ?? ()
#71 0x4079712d in malloc () from /lib/tls/libc.so.6
#72 0x4085b8a0 in __after_morecore_hook () from /lib/tls/libc.so.6
#73 0x00000046 in ?? ()
#74 0x41cf2460 in ?? () from /usr/lib/libpng12.so.0
#75 0xbfffe22c in ?? ()
#76 0xbfffe228 in ?? ()
#77 0xbfffe224 in ?? ()
#78 0x00000444 in ?? ()
#79 0x09d74800 in ?? ()
#80 0x00000000 in ?? ()
#81 0x0904ddd4 in ?? ()
#82 0x00000444 in ?? ()
#83 0x0aea5948 in ?? ()
#84 0x0aea5948 in ?? ()
#85 0xbfffe258 in ?? ()
#86 0x41cebf1d in png_malloc () from /usr/lib/libpng12.so.0
#87 0x40c02f56 in nsInputStreamTee::WriteSegmentFun ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/libxpcom.so
#88 0x41caa862 in NSGetModule ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libimglib2.so
#89 0x41ca90b7 in NSGetModule ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libimglib2.so
#90 0x41ca6d70 in NSGetModule ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libimglib2.so
#91 0x412090bd in nsMediaDocumentStreamListener::SetStreamListener ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libgklayout.so
#92 0x4203a4bd in nsDocumentOpenInfo::Open ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libdocshell.so
#93 0x40cf2dda in NSGetModule ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libnecko.so
#94 0x40d5b8fa in NSGetModule ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libnecko.so
#95 0x40cdb27e in NSGetModule ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libnecko.so
#96 0x40cdafef in NSGetModule ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libnecko.so
#97 0x40c087c1 in nsInputStreamReadyEvent::EventHandler ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/libxpcom.so
#98 0x40c1de97 in PL_HandleEvent ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/libxpcom.so
#99 0x40c1ddc4 in PL_ProcessPendingEvents ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/libxpcom.so
#100 0x40c1f9a9 in nsEventQueueImpl::NotifyObservers ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/libxpcom.so
#101 0x41ddbac5 in nsBaseWidget::FreeNativeData ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libwidget_gtk2.so
#102 0x405401df in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#103 0x4051ab92 in g_main_depth () from /usr/lib/libglib-2.0.so.0
#104 0x4051bc88 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#105 0x4051bfc0 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#106 0x4051c603 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#107 0x402105a3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#108 0x41ddbee6 in nsAppShell::ReleaseGlobals ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libwidget_gtk2.so
#109 0x41d33334 in ?? ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libnsappshell.so
#110 0x08132670 in ?? ()
#111 0xbfffe890 in ?? ()
#112 0xbfffea18 in ?? ()
#113 0x08054a03 in ?? ()
#114 0x08132358 in ?? ()
#115 0x08065629 in nsIAppShellService::GetIID()::iid ()
#116 0x080655ea in nsIAppShellService::GetIID()::iid ()
#117 0xbfffe8b8 in ?? ()
#118 0x0807638c in ?? ()
#119 0x40c562fc in ?? ()
   from /home/lefevre/mozilla/lib/mozilla-1.8a4/libxpcom.so
#120 0x00000032 in ?? ()
#121 0xbfffe9b0 in ?? ()
#122 0xbfffe970 in ?? ()
#123 0x080654c8 in _IO_stdin_used ()
#124 0x0806ec90 in vtable for nsGetServiceByCID ()
#125 0xbfffe990 in ?? ()
#126 0xbfffe9c0 in ?? ()
#127 0xbfffe9d8 in ?? ()
#128 0xbfffe9d0 in ?? ()
#129 0xbfffe88c in ?? ()
#130 0xbfffe9e0 in ?? ()
#131 0xbfffe9f0 in ?? ()
#132 0x00000001 in ?? ()
#133 0x00000000 in ?? ()
#134 0x082d8568 in ?? ()
#135 0x00000001 in ?? ()
#136 0x00000020 in ?? ()
#137 0x080701a0 in nsObsoleteACString::sCanonicalVTable ()
#138 0x0806eac8 in vtable for nsObsoleteAStringThunk ()
#139 0xbfffe8b8 in ?? ()
#140 0x00000018 in ?? ()
#141 0x00010011 in ?? ()
#142 0x0000003f in ?? ()
#143 0xbfffe8b8 in ?? ()
#144 0x00720043 in ?? ()
#145 0x00610065 in ?? ()
#146 0x00690074 in ?? ()
#147 0x0067006e in ?? ()
#148 0x00660020 in ?? ()
#149 0x00720069 in ?? ()
#150 0x00740073 in ?? ()
#151 0x00770020 in ?? ()
#152 0x006e0069 in ?? ()
#153 0x006f0064 in ?? ()
#154 0x002e0077 in ?? ()
#155 0x002e002e in ?? ()
#156 0x40010000 in realloc () from /lib/ld-linux.so.2
Previous frame inner to this frame (corrupt stack?)
Product: Browser → Seamonkey
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051113 SeaMonkey/1.5a

Works for me. Is the URL that Vincent mentioned still crashing for you guys?
URL: http://danpat.net/~danpat/svn-graph/g...
I no longer get a crash, but I'm now on a machine with plenty of memory. For this image, Firefox + Xorg take additional 400 MB RES memory (which can lead to a crash when there is not enough memory). With Opera 8.5, it only takes additional 220 MB RES memory, and it is faster.

Apart from the inefficiency, this is bug 228245 IMHO.
(In reply to comment #5)
> #48 0x4238058d in nsImageGTK::Init ()
>    from /home/lefevre/mozilla/lib/mozilla-1.8a4/components/libgfx_gtk.so
> #49 0x406f0f84 in std::terminate () from /usr/lib/libstdc++.so.5
> #50 0x406f10f6 in __cxa_throw () from /usr/lib/libstdc++.so.5
> #51 0x406f134f in operator new () from /usr/lib/libstdc++.so.5
> #52 0x406f141f in operator new[] () from /usr/lib/libstdc++.so.5

bug 295457 (fixed)
Status: REOPENED → NEW
Alright, so this is a dupe of bug 295457, as timeless mentioned. The stuff about memory going crazy is probably bug 210931.
Assignee: general → pavlov
Component: General → ImageLib
Product: Mozilla Application Suite → Core
QA Contact: general
Version: Trunk → 1.7 Branch

*** This bug has been marked as a duplicate of 295457 ***
Status: NEW → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.