107850 - Crash on DHTML library HierMenus

Status: RESOLVED DUPLICATE of bug 108651

(Core :: Layout, defect, P1)

Description

[Olivier Cahagne]

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/

Comment 1

[R.K.Aa.]

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

Comment 2

[R.K.Aa.]

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

Comment 3

[Olivier Cahagne]

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.

Comment 4

[[e-mail] (gone - use [e-mail] instead)]

Incident ID 37465184
Stack Signature Invalidate() d2422aa6
Bug ID
Trigger Time 2001-10-31 14:49:30
Email Address [e-mail]
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) 

Comment 5

[Boris Zbarsky [:bzbarsky]]

libpr0n

Comment 6

[Olivier Cahagne]

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.

Comment 7

[Markus Hübner]

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!

Comment 8

[Olivier Cahagne]

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...

Comment 9

[Olivier Cahagne]

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/

Comment 10

[Olivier Cahagne]

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

Comment 11

[Olivier Cahagne]

Attachment: Initial testcase (unzip archive and launch LoadMe.htm), based on latest version crashing (4.0.14, next version 4.1 does not crash), note that it won't crash if you delete the image and reload.

Comment 12

[Stuart Parmenter]

-> layout

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

Comment 13

[Chris Petersen]

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

**********

Comment 14

[R.K.Aa.]

[e-mail]:

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.

Comment 15

[Kevin McCluskey (gone)]

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

Comment 16

[Stuart Parmenter]

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

Comment 17

[Marc Attinasi]

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

Comment 18

[Olivier Cahagne]

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 ?

Comment 19

[Marc Attinasi]

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).

Comment 20

[Marc Attinasi]

Attachment: Patch to stop the crash caused by a null ptr deref after ChildAt

Comment 21

[Marc Attinasi]

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 22

[Kevin McCluskey (gone)]

Comment on attachment 56824 [details] [diff] [review]
Patch to stop the crash caused by a null ptr deref after ChildAt

r=[e-mail]

Comment 23

[Johnny Stenback (:jst)]

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 ***

Comment 24

[R.K.Aa.]

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