Build ID: 2001103103 on Win2k. Fresh profile created with 'mozilla -profilemanager'. Steps to reproduce (warning: it can crash the whole OS, WD reported on #mozillazine WinME was taken down when Mozilla crashed): 1. Load http://www.palm.com/ , 2. Wait until loaded, 3. Wait 5 seconds (time for DHTML menus to get initialized), 4. Mozilla crashes. Expected behaviour: Mozilla should not crash. Talkback IDs on Win2k: TB37463352X TB37463307G Talkback IDs on Win98: TB37463419M TB37463390X This is a regression from today's build as build 2001103003 does not crash on any of these sites. Other sites showing the problem: http://www.zend.com/ http://www.espace-particuliers.creditlyonnais.com/

This took out X on Linux too: Keyboard and mouse frozen. Had to reset power. XFree86 4.0.1/RH7.1

might add: i crashed with an updated CVS build (including fixes for bug 107627 and bug 107421)

OS -> All Crashes build 2001103113 on Linux (kernel 2.4.13, XFree 4.1.99 CVS, 512MB RAM) within seconds after site loaded, X/keyboard/mouse were responsive. Talkback ID: TB37465184H.

Incident ID 37465184 Stack Signature Invalidate() d2422aa6 Bug ID Trigger Time 2001-10-31 14:49:30 Email Address cahagn_o@epita.fr URL visited http://www.palm.com/ User Comments bug 107850 Build ID 2001103113 Product ID MozillaTrunk Platform ID LinuxIntel Trigger Reason SIGSEGV: Segmentation Fault: (signal 11) Stack Trace Invalidate() nsImageFrame::OnDataAvailable() nsImageListener::OnDataAvailable() imgRequestProxy::OnDataAvailable() imgRequest::OnDataAvailable() nsGIFDecoder2::FlushImageData() EndImageFrame() gif_write() nsGIFDecoder2::ProcessData() ReadDataOut() nsInputStreamTee::WriteSegmentFun() ReadSegments() nsInputStreamTee::ReadSegments() nsGIFDecoder2::WriteFrom() imgRequest::OnDataAvailable() ProxyListener::OnDataAvailable() nsStreamListenerTee::OnDataAvailable() nsHttpChannel::OnDataAvailable() nsOnDataAvailableEvent::HandleEvent() nsARequestObserverEvent::HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xeafa (0x40352afa) libglib-1.2.so.0 + 0x101b6 (0x403541b6) libglib-1.2.so.0 + 0x10781 (0x40354781) libglib-1.2.so.0 + 0x10921 (0x40354921) libgtk-1.2.so.0 + 0x8c919 (0x40278919) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x189cb (0x404889cb)

libpr0n

Adding 'top100' keyword as http://www.victoriassecret.com/ also crashes (DHTML menus) and, with http://www.palm.com/ , that makes two (at least) big sites (not only for techies) crashing.

The HierMenus from webreference.com is the most widely used DHTML library for dynamic menus. A list of sites using the HierMenus is available at http://www.webreference.com/dhtml/hiermenus/sites/ Don't know yet which versions are affected. Have to further investigate, but this is causing major problems on some of the biggest websites our there!

Markus, I had checked every important site listed in this URL when initially submitting this bug report and none of them would crash. I guess it must be version-specific or only when associated to a doctype, something...

Sorry for the spam, forget previous post, I must had checked better, because one of the sites listed on http://www.webreference.com/dhtml/hiermenus/sites/ crashes: http://www.nortelnetworks.com/

Here's a brief status from sites using HM DHTML menus crashing/working (done with build 2001110103 on Win2k, the version number is for the Hiermenus): http://www.dellhost.co.uk/ : crashes, v.4.0.8 http://www.hrblock.com/ : crashes, v.4.0.7 http://www.zend.com/ : crashes, v.4.0.14 http://www.palm.com/ : crashes, v.4.0.8 http://www.victoriassecret.com/ and http://www.nortelnetworks.com/ : crashes, no version http://www.redhat.com/ : works, v.4.1.1 http://www.webtrends.com/ and http://www.vignette.com/ : work, no version http://www.unisys.com/ and http://www.ncr.com/ : no crash, menus not working, v.3.0.8 http://www.sap.com/ and http://www.lucent.com/ : no crash, menus not working, no version

-> layout this is (yet another) case where the frame is being deleted or overwritten in the arena and not being fully destroyed.

Crash on Mac OS X build at palm's site: Date/Time: 2001-11-01 20:29:21 -0800 OS Version: 10.1 (Build 5L14) Command: Mozilla PID: 321 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0: #0 0x00000000 in 0x0 #1 0x02d2b4f8 in nsFrame::Invalidate( const(nsIPresContext *, nsRect const &, int)) #2 0x02d95668 in OnDataAvailable__12nsImageFrameFP11imgIRequestP14nsIPresContex #3 0x02d9b2b4 in OnDataAvailable__15nsImageListenerFP11imgIRequestP11nsISupport #4 0x026c34cc in imgRequestProxy::OnDataAvailable(gfxIImageFrame *, nsRect const *) #5 0x026c0fc0 in OnDataAvailable__10imgRequestFP11imgIRequestP11nsISupportsP14g #6 0x01c38e84 in nsGIFDecoder2::FlushImageData(void) #7 0x01c393b4 in EndImageFrame(void *, unsigned int, unsigned int, unsigned int) #8 0x01c3b0c8 in gif_write(gif_struct *, unsigned char const *, unsigned int) #9 0x01c38fec in nsGIFDecoder2::ProcessData(unsigned char *, unsigned int) #10 0x01c38d70 in ReadDataOut(nsIInputStream *, void *, char const *, unsigned int, unsigned int, unsigned int *) #11 0x0063c248 in nsPipe::nsPipeInputStream::ReadSegments( ( (*)(nsIInputStream *))) #12 0x01c390a8 in nsGIFDecoder2::WriteFrom(nsIInputStream *, unsigned int, unsigned int *) #13 0x026c1d5c in OnDataAvailable__10imgRequestFP10nsIRequestP11nsISupportsP14ns #14 0x026bf4d8 in OnDataAvailable__13ProxyListenerFP10nsIRequestP11nsISupportsP1 #15 0x01fef6dc in OnDataAvailable__13nsHttpChannelFP10nsIRequestP11nsISupportsP1 #16 0x01fd2054 in nsOnDataAvailableEvent::HandleEvent(void) #17 0x01fe0a90 in nsARequestObserverEvent::HandlePLEvent(PLEvent *) #18 0x0065ab70 in PL_HandleEvent #19 0x0065a9ec in PL_ProcessPendingEvents #20 0x00601a3c in nsEventQueueImpl::ProcessPendingEvents(void) #21 0x02182178 in nsMacNSPREventQueueHandler::ProcessPLEventQueue(void) #22 0x02181f3c in nsMacNSPREventQueueHandler::RepeatAction(EventRecord const &) #23 0x021ab66c in Repeater::DoRepeaters(EventRecord const &) #24 0x021968c0 in nsMacMessagePump::DispatchEvent(int, EventRecord *) #25 0x0219648c in nsMacMessagePump::DoMessagePump(void) #26 0x02195de8 in nsAppShell::Run(void) #27 0x01cf3ccc in nsAppShellService::Run(void) #28 0x005363f4 in main1(int, char **, nsISupports *) #29 0x00536f9c in main Thread 1: #0 0x70001308 in mach_msg_overwrite_trap #1 0x70006394 in mach_msg #2 0x700273dc in _pthread_become_available #3 0x700270d4 in pthread_exit #4 0x70020f00 in _pthread_body #5 0x90010008 in 0x90010008 Thread 2: #0 0x7000530c in syscall #1 0x70557590 in BSD_waitevent #2 0x70554a30 in CarbonSelectThreadFunc #3 0x70020efc in _pthread_body Thread 3: #0 0x7003fe48 in semaphore_wait_signal_trap #1 0x7003fc48 in _pthread_cond_wait #2 0x705594ac in CarbonOperationThreadFunc #3 0x70020efc in _pthread_body Thread 4: #0 0x70043988 in semaphore_timedwait_signal_trap #1 0x70043968 in semaphore_timedwait_signal #2 0x7003fc38 in _pthread_cond_wait #3 0x7028366c in TSWaitOnConditionTimedRelative #4 0x7027cf10 in TSWaitOnSemaphoreCommon #5 0x702c14c8 in TimerThread #6 0x70020efc in _pthread_body Thread 5: #0 0x7003fe48 in semaphore_wait_signal_trap #1 0x7003fc48 in _pthread_cond_wait #2 0x702505cc in TSWaitOnCondition #3 0x7027cef8 in TSWaitOnSemaphoreCommon #4 0x7024386c in AsyncFileThread #5 0x70020efc in _pthread_body Thread 6: #0 0x7003fe48 in semaphore_wait_signal_trap #1 0x7003fc48 in _pthread_cond_wait #2 0x7055b9b4 in CarbonInetOperThreadFunc #3 0x70020efc in _pthread_body PPC Thread State: srr0: 0x00000000 srr1: 0x4000f030 vrsave: 0x00000000 xer: 0x20000018 lr: 0x02d2b4f8 ctr: 0x00000000 mq: 0x00000000 r0: 0x00000000 r1: 0xbfffea10 r2: 0x03f24360 r3: 0x03f3c5d0 r4: 0xbfffea94 r5: 0x00000000 r6: 0xbfffe9f0 r7: 0x00000080 r8: 0x000000e4 r9: 0x02f5a72c r10: 0x00000001 r11: 0x00000001 r12: 0x03f2ae00 r13: 0x00000000 r14: 0x00000036 r15: 0x00066670 r16: 0x00000001 r17: 0x80160e88 r18: 0x00064a28 r19: 0x00001907 r20: 0x00000000 r21: 0x0000001c r22: 0x70004bc4 r23: 0x70004c58 r24: 0x7016b214 r25: 0x006bac3c r26: 0x8081ab5c r27: 0xc0dc2000 r28: 0x00000000 r29: 0xbfffef00 r30: 0x00000000 r31: 0x00000001 **********

kmcclusk@netscape.com: I don't dare test mozilla builds with this bug around. I can't afford to trash my entire filesystem, which is what i risk. So untill it's fixed, i'm stuck with 2001102910. I look forward to testing Mozilla again in 0.9.7.

From the stack it looks like an imagelib issue, not layout. Reassigning to Pavlov.

kevin: please read my comment. this is layout not destroying the frame properly.

OK, I'll check it out. But, if this is a regression, what changed? Layout has not seen much changes lately... Any ideas?

As I mentioned in my bug report, "this is a regression from today's build as build 2001103003 does not crash on any of these sites." I checked bonsai between 10/29/2001 and 10/31/2001 but didn't see much. Perhaps bug 102088 ? bug 107453 ? bug 56117 ? bug 97630 ?

I have a fix that stops the crash for me on www.palm.com, but my stack is different than what is reported here (and it is the same for me on Win, Mac and Linux). What I see is a call to nsIContent->ChildAt returning null, then being dereferenced and crashing (in nsCSSFrameConstructor::ContentAppended). By adding a null check the crash goes away and the page seems to work properly. I'll attach the patch, but I suspect there is something interesting to learn about in the content node since it's behaviour has changed (apparently).

The attached patch stops the crash for me. However, I have not determined why the behaviour changed - my guess is it has something to do with recent content changes (cc'ing jst)

Comment on attachment 56824 [details] [diff] [review] Patch to stop the crash caused by a null ptr deref after ChildAt r=kmcclusk@netscape.com

This was a regression I caused last week. The fix is checked in (see bug 108651). Duping. *** This bug has been marked as a duplicate of 108651 ***

*** Bug 108648 has been marked as a duplicate of this bug. ***