345935 - crash in recent Bon Echo nightly [@ MSVCRT.DLL + 0xd77a] [@ nsXULElement::CloneNode]

mcdavis941 (sporadically reading bugmail)

Reporter

Description

•

18 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

My first time reporting from a talkback ID, hope I'm doing this right.

I've been seeing frequent crashes with Bon Echo since about two or three weeks ago.  Haven't been able to associate with a particular sequence.  Sometimes on restart, or when installing a new theme or extension, or using chatzilla, or when doing nothing at all because I've alt-tabbed away to another application.  I used to be able to run bonecho continuously, now it won't stay up for more than five or ten minutes.

These last two incident ID's (TB21427772Q and TB21428419H) are with a brand new software install and a brand new profile.

Stack Signature	 MSVCRT.DLL + 0xd77a (0x7800d77a) 60bb1744
Product ID	Firefox2
Build ID	2006072504
Trigger Time	2006-07-25 19:42:56.0
Platform	Win32
Operating System	Windows 98 4.10 build 67766446
Module	MSVCRT.DLL + (0000d77a)
URL visited	
User Comments	
Since Last Crash	707 sec
Total Uptime	707 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
MSVCRT.DLL + 0xd77a (0x7800d77a)
MSVCRT.DLL + 0xccf7 (0x7800ccf7)
MSVCRT.DLL + 0x1026 (0x78001026)
nsXULElement::CloneNode  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 477]
nsGenericElement::CopyInnerTo  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 3828]
nsXMLElement::CloneNode  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xml/content/src/nsXMLElement.cpp, line 402]
nsXBLBinding::GenerateAnonymousContent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp, line 512]
nsXBLService::LoadBindings  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLService.cpp, line 630]
nsCSSFrameConstructor::ConstructFrameInternal  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7758]
nsCSSFrameConstructor::ConstructFrame  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7715]
nsCSSFrameConstructor::ContentAppended  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 8832]
PresShell::ContentAppended  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 5472]
nsXULDocument::ContentAppended  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/document/src/nsXULDocument.cpp, line 1165]
nsXULElement::InsertChildAt  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 1119]
nsGenericElement::doReplaceOrInsertBefore  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 3609]
nsGenericElement::InsertBefore  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 3058]
XPCWrappedNative::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2160]
XPC_WN_CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1450]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1349]
js_Interpret  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 4086]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1368]
js_InvokeConstructor  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1893]
js_Interpret  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 5349]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1368]
js_InternalInvoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1447]
JS_CallFunctionValue  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 4377]
nsJSContext::CallEventHandler  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1474]
nsJSEventListener::HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/events/nsJSEventListener.cpp, line 195]
nsEventListenerManager::HandleEventSubType  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1655]
nsEventListenerManager::HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1762]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2219]
nsTreeSelection::FireOnSelectHandler  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp, line 789]
nsTreeSelection::Select  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/xul/base/src/tree/src/nsTreeSelection.cpp, line 378]
XPCWrappedNative::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2160]
XPC_WN_CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1450]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1349]
js_Interpret  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 4086]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1368]
js_InternalInvoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1447]
JS_CallFunctionValue  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 4377]
nsJSContext::CallEventHandler  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1474]
nsJSEventListener::HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/events/nsJSEventListener.cpp, line 195]
nsEventListenerManager::HandleEventSubType  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1655]
nsEventListenerManager::HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1762]
nsGlobalWindow::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp, line 1656]
DocumentViewerImpl::LoadComplete  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsDocumentViewer.cpp, line 1013]
nsDocShell::EndPageLoad  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp, line 4791]
nsWebShell::EndPageLoad  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/docshell/base/nsWebShell.cpp, line 665]
nsDocShell::OnStateChange  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp, line 4706]
nsDocLoader::FireOnStateChange  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/uriloader/base/nsDocLoader.cpp, line 1210]
nsDocLoader::doStopDocumentLoad  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/uriloader/base/nsDocLoader.cpp, line 844]
nsDocLoader::OnStopRequest  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/uriloader/base/nsDocLoader.cpp, line 665]
nsLoadGroup::RemoveRequest  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/netwerk/base/src/nsLoadGroup.cpp, line 732]
nsCachedChromeChannel::HandleLoadEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/chrome/src/nsChromeProtocolHandler.cpp, line 402]
0x778b0c24

Reproducible: Didn't try

Adam Guthrie

Updated

•

18 years ago

Assignee: nobody → general

Severity: normal → critical

Component: General → DOM

Keywords: crash

Product: Firefox → Core

QA Contact: general → ian

Summary: crash with talkback incident ID TB21427772Q → crash in recent Bon Echo nightly [@ MSVCRT.DLL + 0xd77a] [@ nsXULElement::CloneNode]

Version: unspecified → 1.8 Branch

Adam Guthrie

Comment 1

•

18 years ago

Kinda makes me wonder if something's wrong with msvcrt.dll since you're crashing in a clean profile.

Also, the stack seems slightly bogus to me; I don't see how nsXULElement::CloneNode is making win32 API calls...

timeless

Comment 2

•

18 years ago

ispiked: those aren't win32api, they're the c/c++ runtime library, usually heap functions i.e. malloc or new. i don't have the w98 msvcrt handy so I'm not in a position to figure out what those functions are, reporter: could you possibly temporarily provide me (@gmail.com) with a url for the msvcrt.dll you're using? (you can use dependency walker to figure out which one you're using.)

Assignee: general → nobody

Component: DOM → XP Toolkit/Widgets: XUL

QA Contact: ian → xptoolkit.xul

mcdavis941 (sporadically reading bugmail)

Reporter

Comment 3

•

18 years ago

@timeless: responding to your question about mscvrt.dll.  I found four on my system.

C:\WINDOWS\SYSTEM\MSCVRT.DLL\MSCVRT.DLL                 12/07/1999 12:00PM 289KB
C:\Program Files\Javasoft\JRE\1.3.0_01\bin\mscvrt.dll   10/17/2000  9:19PM 261KB
C:\Program Files\Javasoft\JRE\1.3.1\bin\mscvrt.dll      05/06/2001 11:14AM 261KB
C:\Program Files\Java\j2re1.4.0\bin\mscvrt.dll          06/06/2002  9:14AM 261KB
  
is it the one in c:\windows\system that you're interested in? (i'm a little surprised by the date on that one, I would have thought it would have been patched by windows update many times by now).

timeless, i'm sending email regarding your question right now to what i presume is your address.  if you don't get something from me, post a comment here and we can make other arrangements, like getting on irc if that would help.

mcdavis941 (sporadically reading bugmail)

Reporter

Comment 4

•

18 years ago

Dependency Walker confirms that this is the one we're interested in.

C:\WINDOWS\SYSTEM\MSCVRT.DLL\MSCVRT.DLL                 12/07/1999 12:00PM
289KB

mcdavis941 (sporadically reading bugmail)

Reporter

Comment 5

•

18 years ago

Another crash this morning. TB21445123Z:

left bonecho running all night (about 8 hours).  opened chatzilla.  opened chatzilla preferences.  alt-tabbed over to fx1.5.  copied and pasted some text from a web page.  alt-tabbed to chatzilla.  alt-tabbed to chatzilla preferences.  selected "appearance" tab, clicked "global preferences" in left column.  scrolled a little to put "current motif" field in window.  pasted into current motif field.  clicked "apply" then "ok".  crash.

Stack Signature	 MSVCRT.DLL + 0xd77a (0x7800d77a) 052a8570
Product ID	Firefox2
Build ID	2006072504
Trigger Time	2006-07-26 07:20:02.0
Platform	Win32
Operating System	Windows 98 4.10 build 67766446
Module	MSVCRT.DLL + (0000d77a)
URL visited	
User Comments	"appearance" tab, clicked "global preferences" in left column. scrolled a little to put "current motif" field in window. pasted into current motif field. clicked "apply" then "ok". crash.
Since Last Crash	31990 sec
Total Uptime	33886 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
MSVCRT.DLL + 0xd77a (0x7800d77a)
MSVCRT.DLL + 0xccf7 (0x7800ccf7)
MSVCRT.DLL + 0x1026 (0x78001026)
XPCConvert::NativeInterface2JSObject  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcconvert.cpp, line 1156]
XPCConvert::NativeData2JS  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcconvert.cpp, line 473]
XPCWrappedNative::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2250]
XPC_WN_GetterSetter  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1482]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1349]
js_InternalInvoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1447]
js_InternalGetOrSet  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1507]
js_GetProperty  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 3283]
js_Interpret  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3822]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1368]
js_InternalInvoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1447]
JS_CallFunctionValue  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 4377]
nsXBLProtoImplAnonymousMethod::Execute  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLProtoImplMethod.cpp, line 344]
nsXBLBinding::ExecuteDetachedHandler  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp, line 797]
nsGlobalWindow::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp, line 1625]
DocumentViewerImpl::PageHide  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsDocumentViewer.cpp, line 1209]
nsDocShell::FirePageHideNotification  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp, line 926]
nsDocShell::Destroy  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp, line 3504]
nsXULWindow::Destroy  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 514]
nsWebShellWindow::Destroy  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp, line 850]
nsChromeTreeOwner::Destroy  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpfe/appshell/src/nsChromeTreeOwner.cpp, line 363]
PL_HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpcom/threads/plevent.c, line 689]
0x778b0c24

Boris Zbarsky [:bzbarsky]

Comment 6

•

18 years ago

Do we know when this started?  The stacks don't tell me much, esp. since talkback is clearly lying about line numbers here.  :(

Flags: blocking1.8.1?

mcdavis941 (sporadically reading bugmail)

Reporter

Comment 7

•

18 years ago

(In reply to comment #6)
> Do we know when this started?  The stacks don't tell me much, esp. since
> talkback is clearly lying about line numbers here.  :(
> 

Not for certain.  It was "around" the time of the release of 2.0b1, but I've been getting nightlies so it could have been any release in that time period.  None the less, there was a pretty clear shift (on my system) from bon echo working consistently and reliably to crashing all the time.

Boris Zbarsky [:bzbarsky]

Comment 8

•

18 years ago

Can someone who can reproduce this try downloading some nightlies and seeing which ones have the problem and which ones don't?  If about 5-10 minutes of browsing indicate one way or another, a binary search shouldn't take all that long...

mcdavis941 (sporadically reading bugmail)

Reporter

Comment 9

•

18 years ago

(In reply to comment #8)
> Can someone who can reproduce this try downloading some nightlies and seeing
> which ones have the problem and which ones don't?  If about 5-10 minutes of
> browsing indicate one way or another, a binary search shouldn't take all that
> long...
> 

LOL OK I knew that was next.

Yes.

Signed,
"someone who can reproduce this"

timeless

Comment 10

•

18 years ago

(dummy+0xd77a)==(dummy!__sbh_alloc_block+0x269)
(dummy+0xccf7)==(dummy!_heap_alloc+0xbcc7)
(dummy+0x1026)==(dummy!malloc+0x26)

So this is definitely memory allocation that's failing. in case people are curious, this is what i did:
1. grabbed the msvcrt.dll michael provided.
2. 
"c:\Program Files\Debugging Tools for Windows\symchk.exe" /v .\msvcrt.dll /s SRV*..\symbols\*http://msdl.microsoft.com/download/symbols

this got me the msvcrt.pdb i needed
I now had ..\symbols\msvcrt.pdb\37F2C2272\msvcrt.pdb
3. I renamed that to:
..\symbols\dummy.pdb\37F2C2272\dummy.pdb
4. I renamed michael's msvcrt.dll dummy.dll
(i'm in the components directory)
5. i deleted compreg.dat
6. i ran windbg ..\xpcshell.exe
7. debug>go (since we want modules like dummy to load)
8. I used .sympath (or the equivalent) to give windbg access to the symbols directory (something like: SRV*..\symbols\*http://msdl.microsoft.com/download/symbols, but you browse to the symbols directory)
9. .reload /f (pulls in everyone else's symbols)
10. .symopt +0x40 (says that we're really not picky)
11. !sym noisy (let me watch everything)
12. .reload /unl /f dummy.dll (load dummy)
13. lm v (see all the symbols)

at this point i just used the disassembly view as I normally do to calculate math. it's slightly sucky because the library isn't actually loaded atm, so I had to use numbers less than addresses and browse forward until i found a symbol name. If i had asked windbg to force the dll to load, I could have pulled out the code and the function guessing would have been easier.

note that these symbols are just the public symbols, it's possible that we're in some other function, but it's fairly likely that it's a related function.

Mike Connor [:mconnor]

Comment 11

•

18 years ago

not going to block on a non-topcrash that's UNCO and has no traction yet.

Flags: blocking1.8.1?

mcdavis941 (sporadically reading bugmail)

Reporter

Comment 12

•

18 years ago

(In reply to comment #8)
> Can someone who can reproduce this try downloading some nightlies and seeing
> which ones have the problem and which ones don't?  If about 5-10 minutes of
> browsing indicate one way or another, a binary search shouldn't take all that
> long...
> 

The short version: 

The earliest version I've seen the behavior with so far is 2006-07-09-06 (my name, which is probably labeled 2006-07-09-06 on the ftp site).  Continuing to test earlier versions than that.

The long version:

Trying http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-07-04-04-mozilla1.8/
    saving firefox-2.0a3.en-US.win32.2006-07-04-04.installer.exe
    
    No crashes so far.
    Tried once with default theme, once with NN theme.
    
Tying firefox-2.0b1.en-US.win32.installer.2006072406.exe (from hard drive)

    start
    open addons mgr
    drag and drop chatzilla
    drag and drop mtli
    drag and drop NN theme
    exit bonecho
    crash
    
    incident ID: TB21451970M
    
    FIREFOX caused an invalid page fault in
    module MSVCRT.DLL at 0187:7800d77a.
    Registers:
    EAX=01bc3a80 CS=0187 EIP=7800d77a EFLGS=00010206
    EBX=00e90084 SS=018f ESP=00d7c704 EBP=00d7c724
    ECX=036b5e90 DS=018f ESI=0000003f FS=6a57
    EDX=036b5ea0 ES=018f EDI=036b600c GS=0000
    Bytes at CS:EIP:
    89 4c 11 fc 8b 75 f0 03 d1 8d 4e 01 89 0a 89 4c 
    Stack dump:
    01a8cfe8 00000004 00000000 81b5b0b8 00000010 01bc7434 036b5e90 0000001c 00d7c75c 7800ccf7 00e90084 01a8cfe8 02e6a2d0 00000000 00000000 00d7c7a8
    
Trying firefox-2.0b1.en-US.win32.installer.2006071806.exe (from hard drive)

    start
    open addons mgr
    drag and drop chatzilla, mtli nn_theme
    restart
    open chatzilla, cz prefs, restart a few times, surf around (all with default theme)
    crash when click on link on some BBC page 
    
    incident id: TB21452815E
    
    FIREFOX caused an invalid page fault in
    module MSVCRT.DLL at 0187:7800d77a.
    Registers:
    EAX=030e0cc8 CS=0187 EIP=7800d77a EFLGS=00210206
    EBX=00e900d4 SS=018f ESP=00d7f6c4 EBP=00d7f6e4
    ECX=030e369c DS=018f ESI=00000001 FS=64ef
    EDX=036f0590 ES=018f EDI=030e0ddc GS=0000
    Bytes at CS:EIP:
    89 4c 11 fc 8b 75 f0 03 d1 8d 4e 01 89 0a 89 4c 
    Stack dump:
    0386bc28 0000001c 00000000 81bb98a0 00000030 030e365c 030e369c 00000014 00d7f71c 7800ccf7 00e900d4 0386bc28 00d7f778 00000000 00504e32 0000000a 
    
Trying firefox-2.0b1.en-US.win32.installer.2006-07-09-06.exe (from hard drive)

    start
    open addons mgr
    drag and drop chatzilla, mtli
    crashes while installing mtli
    
    incident id: TB21453629M

    FIREFOX caused an invalid page fault in
    module MSVCRT.DLL at 0187:7800d77a.
    Registers:
    EAX=01b355d8 CS=0187 EIP=7800d77a EFLGS=00010206
    EBX=00e90084 SS=018f ESP=00d7f4a0 EBP=00d7f4c0
    ECX=01b38124 DS=018f ESI=0000003f FS=48e7
    EDX=03317700 ES=018f EDI=03311abc GS=0000
    Bytes at CS:EIP:
    89 4c 11 fc 8b 75 f0 03 d1 8d 4e 01 89 0a 89 4c 
    Stack dump:
    00000038 00000038 00f28050 81bba5cc 00000040 01b37f6c 01b38124 00000014 00d7f4f8 7800ccf7 00e90084 00000038 01b398a0 00f28050 00d7f594 600f0ae1 
    
Trying firefox-2.0a3.en-US.win32.2006-07-05-04.installer.exe (from hard drive)

    start
    open addons mgr
    drag and drop chatzilla, mtli, nn_theme
    surf around a few different sites for a while
    open a couple prefwindow
    restart
    open chatzilla
    open chatzilla pref, close
    use chatzilla for a while

    has not crashed yet.

mcdavis941 (sporadically reading bugmail)

Reporter

Comment 13

•

18 years ago

(In reply to comment #12)
> The short version: 
> 
> The earliest version I've seen the behavior with so far is 2006-07-09-06 (my
> name, which is probably labeled 2006-07-09-06 on the ftp site).  Continuing to
> test earlier versions than that.

Meant to say "which is probably 2006-07-09-04 labeled on the ftp site"

mcdavis941 (sporadically reading bugmail)

Reporter

Comment 14

•

18 years ago

In summary:

2006-07-05-04   OK
2006-07-06-03   OK
2006-07-07-04   CRASH
2006-07-09-06   CRASH
2006-07-18-06   CRASH
2006-07-24-06   CRASH

Details of final trials:

Trying firefox-2.0a3.en-US.win32.2006-07-05-04.installer.exe (from hard drive)

    start
    open addons mgr
    drag and drop chatzilla, mtli, nn_theme
    surf around a few different sites for a while
    open a couple prefwindow
    restart
    open chatzilla
    open chatzilla pref, close
    use chatzilla for a while
    after about an hour of surfing various pages, restart
    do some chatzilla stuff, surf some pages
    seems like it won't crash
    
If true, that means the crash was introduced on 2006-07-06, 2006-07-07, 2006-07-08, or 2006-07-09.
    
Trying firefox-2.0a3.en-US.win32.2006-07-07-04.installer.exe (from ftp)

    start
    open addons mgr
    drag and drop chatzilla, mtli, nn_theme
    surf around for about 10 minutes
    open and close some windows/sidebars
    restart
    open mtli options, chatzilla, cz prefs
    change a cz pref (display user list on left) and click apply or OK
    crash
    
    Incident ID: TB21459925E
    
    FIREFOX caused an invalid page fault in
    module MSVCRT.DLL at 0187:7800d77a.
    Registers:
    EAX=0322d674 CS=0187 EIP=7800d77a EFLGS=00010202
    EBX=00e900e8 SS=018f ESP=00d7ec5c EBP=00d7ec7c
    ECX=03230fdc DS=018f ESI=0000003f FS=58ff
    EDX=0396d390 ES=018f EDI=0396d38c GS=0000
    Bytes at CS:EIP:
    89 4c 11 fc 8b 75 f0 03 d1 8d 4e 01 89 0a 89 4c 
    Stack dump:
    00000038 00000038 033389e8 81b9db28 00000040 03230e24 03230fdc 0000001b 00d7ecb4 7800ccf7 00e900e8 00000038 03def540 033389e8 601a87d5 00d7ec5c
    
Trying firefox-2.0a3.en-US.win32.installer.2006-07-06-03.exe (from ftp)    
    
    start
    open addons mgr
    drag and drop chatzilla, mtli, nn_theme
    surf around for about 10 minutes
    tab through the options window
    restart
    open about ten blank tabs
    drag and drop a bunch of pages from fx1.5
    surf around for about ten minutes
    open cz, cz prefs, change a pref, apply, ok
    open moznet, join some channels
    surf around a while
    close cz
    surf around
    open cz, open prefs, change prefs, close prefs
    a mix of surf around and leave it alone for about an hour
    restart 
    surf around
    
    seems like it won't crash

Adam Guthrie

Comment 15

•

18 years ago

Check-ins for regression range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-07-06+02&maxdate=2006-07-07+05&cvsroot=%2Fcvsroot

Nothing obvious is sticking out at me here. Maybe Boris or someone else will know.

Keywords: regression

mcdavis941 (sporadically reading bugmail)

Reporter

Comment 16

•

18 years ago

timeless said he thought this was related.

http://support.microsoft.com/kb/q225099/

i don't know if that was still his leading theory when he knocked off for the day.

Martijn Wargers (dead)

Comment 17

•

18 years ago

> 2006-07-06-03   OK
> 2006-07-07-04   CRASH
With that regression window, I'm thinking of somehow a regression from the JS1.7 landing. Bug 336373 keeps track of all the regressions from that landing.
Not sure about the stacks though, they don't seem to have anything to do with javascript.

Boris Zbarsky [:bzbarsky]

Comment 18

•

18 years ago

If the issue is really that realloc stomps on memory, then pretty much anything, including the JS 1.7 landing, could be the cause...

Boris Zbarsky [:bzbarsky]

Comment 19

•

18 years ago

Confirming to make sure people actually get mail about this....

We really need to get traction here somehow.  :(

Status: UNCONFIRMED → NEW

Ever confirmed: true

Mike Shaver (:shaver -- probably not reading bugmail closely)

Comment 20

•

18 years ago

Nominating to see how drivers feel about this.  Unattributed memory corruption allegations are a spooky thing!

Flags: blocking1.8.1?

David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)

Comment 21

•

18 years ago

Plussing for blocking1.8.1.  Worth retesting once the patch for bug 335018 lands.

Flags: blocking1.8.1? → blocking1.8.1+

mcdavis941 (sporadically reading bugmail)

Reporter

Comment 22

•

18 years ago

ispiked asked me to take a look at the latest nightly.  using firefox-2.0b1.en-US.win32.2006-07-29-06.installer.exe, i've had uptime of several (four to six) hours.  it's been a couple weeks since i've seen that.

mcdavis941 (sporadically reading bugmail)

Reporter

Comment 23

•

18 years ago

Still using the 2006-07-29 nightly, chatzilla locked up once, but it was a different kind of crash from those reported previously above.  Instead of a crash with talkback and stack trace, it just hung until killed with task manager.

Martijn Wargers (dead)

Comment 24

•

18 years ago

Michael, so it sounds like you don't get the bug anymore (you have been able to test now for a few days)? If that's true, maybe this bug can then become resolved->worksforme?

mcdavis941 (sporadically reading bugmail)

Reporter

Comment 25

•

18 years ago

(In reply to comment #24)
> Michael, so it sounds like you don't get the bug anymore (you have been able to
> test now for a few days)? If that's true, maybe this bug can then become
> resolved->worksforme?
> 
I'm no longer seeing the problems that led me to report this bug.  I don't know enough to say whether it's been fixed or not, but as far as I can tell it's working fine.

Adam Guthrie

Comment 26

•

18 years ago

Thanks for the help, Michael. Marking as WORKSFORME.

Status: NEW → RESOLVED

Closed: 18 years ago

Resolution: --- → WORKSFORME

Mike Schroepfer

Updated

•

18 years ago

Target Milestone: --- → mozilla1.8.1

Mike Schroepfer

Comment 27

•

18 years ago

Marking fixed1.8.1 per comment 25 and comment 26.  If this is incorrect please clear the flag.

Keywords: fixed1.8.1

Tracy Walker [:tracy]

Comment 28

•

18 years ago

verified  per reporters comments

Status: RESOLVED → VERIFIED

Keywords: fixed1.8.1 → verified1.8.1

timeless

Updated

•

16 years ago

Component: XP Toolkit/Widgets: XUL → XUL

QA Contact: xptoolkit.xul → xptoolkit.widgets

Nobody; OK to take it and work on it

Assignee

Updated

•

13 years ago

Crash Signature: [@ MSVCRT.DLL + 0xd77a] [@ nsXULElement::CloneNode]