Crash on DHTML library HierMenus




18 years ago
17 years ago


(Reporter: wolruf, Assigned: attinasi)


({crash, regression, top100})

crash, regression, top100

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [HIERMENU][TOOL][DHTML], URL)


(2 attachments)



18 years ago
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 ,
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:


18 years ago
Keywords: crash


18 years ago
Keywords: regression

Comment 1

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

Comment 2

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

Comment 3

18 years ago
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.
OS: Windows 2000 → All
Incident ID 37465184
Stack Signature Invalidate() d2422aa6
Bug ID
Trigger Time 2001-10-31 14:49:30
Email Address
URL visited
User Comments bug 107850
Build ID 2001103113
Product ID MozillaTrunk
Platform ID LinuxIntel
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
Stack Trace
our_gdk_io_invoke() + 0xeafa (0x40352afa) + 0x101b6 (0x403541b6) + 0x10781 (0x40354781) + 0x10921 (0x40354921) + 0x8c919 (0x40278919)
main() + 0x189cb (0x404889cb) 
Assignee: asa → pavlov
Component: Browser-General → ImageLib
QA Contact: doronr → tpreston

Comment 6

18 years ago
Adding 'top100' keyword as also crashes (DHTML
menus) and, with , that makes two (at least) big sites (not
only for techies) crashing.
Keywords: top100

Comment 7

18 years ago
The HierMenus from is the most widely
used DHTML library for dynamic menus.
A list of sites using the HierMenus is available at

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!
Summary: DHTML menus final initialization crashes Mozilla → Crash on DHTML library HierMenus

Comment 8

18 years ago
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

18 years ago
Sorry for the spam, forget previous post, I must had checked better, because one
of the sites listed on

Comment 10

18 years ago
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): : crashes, v.4.0.8 : crashes, v.4.0.7 : crashes, v.4.0.14 : crashes, v.4.0.8 and : crashes, no
version : works, v.4.1.1 and : work, no version and : no crash, menus not working,
v.3.0.8 and : no crash, menus not working, no

Comment 11

18 years ago
Created attachment 56088 [details]
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

18 years ago
-> layout

this is (yet another) case where the frame is being deleted or overwritten in
the arena and not being fully destroyed.
Assignee: pavlov → attinasi
Component: ImageLib → Layout
QA Contact: tpreston → petersen

Comment 13

18 years ago
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 &,
 #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

Target Milestone: --- → mozilla0.9.7

Comment 14

18 years ago

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.
Assignee: attinasi → pavlov
Component: Layout → ImageLib
Target Milestone: mozilla0.9.7 → ---


18 years ago
No longer blocks: 104864


18 years ago
Blocks: 104864

Comment 16

18 years ago
kevin: please read my comment.  this is layout not destroying the frame properly.
Assignee: pavlov → attinasi
Component: ImageLib → Layout

Comment 17

18 years ago
OK, I'll check it out. But, if this is a regression, what changed? Layout has
not seen much changes lately... Any ideas?
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6

Comment 18

18 years ago
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

17 years ago
I have a fix that stops the crash for me on, but my stack is
different than what is reported here (and it is the same for me on Win, Mac and

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

17 years ago
Created attachment 56824 [details] [diff] [review]
Patch to stop the crash caused by a null ptr deref after ChildAt

Comment 21

17 years ago
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
Attachment #56824 - Flags: review+
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 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 24

17 years ago
*** Bug 108648 has been marked as a duplicate of this bug. ***
No longer blocks: 104864
You need to log in before you can comment on or make changes to this bug.