Closed
Bug 339861
Opened 18 years ago
Closed 18 years ago
crash since 20060530 hourly on the Firefox 2 branch [@ ntdll.dll]
Categories
(Firefox :: General, defect)
Tracking
()
VERIFIED
FIXED
Firefox 2 beta1
People
(Reporter: Peter6, Assigned: brettw)
References
Details
(Keywords: regression, topcrash, verified1.8.1)
Crash Data
Windows Branch testers reporting tons of crashes at ntdll.dll since the 20060531 nightly build TB19330736E TB19330362Q TB19330252Y TB19345098Y TB19342699W TB19341277H TB19339017W
Reporter | ||
Updated•18 years ago
|
Summary: crash [@ ntdll.dll] → crash since 20060531 nighly [@ ntdll.dll]
Reporter | ||
Updated•18 years ago
|
Summary: crash since 20060531 nighly [@ ntdll.dll] → crash since 20060531 nightly [@ ntdll.dll]
Comment 1•18 years ago
|
||
Stack from Firefox shutdown crash TB19349393Z
Crach on closing. Windows XP regression range [053003-053017] http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-30+03%3A00%3A00&maxdate=2006-05-30+17%3A00%3A00&cvsroot=%2Fcvsroot
Summary: crash since 20060531 nightly [@ ntdll.dll] → crash since 20060530 hourly [@ ntdll.dll]
Comment 3•18 years ago
|
||
Steps to reproduce: 1. go to http://www.overclock.net/amd-motherboards/ 2. click "search" 3. enter anything and press enter TB19366072X, TB19366004E, TB19365971G. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060531 BonEcho/2.0a3
Comment 4•18 years ago
|
||
(In reply to comment #3) > Steps to reproduce: > 1. go to http://www.overclock.net/amd-motherboards/ > 2. click "search" > 3. enter anything and press enter > > TB19366072X, TB19366004E, TB19365971G. > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060531 > BonEcho/2.0a3 > WFM. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060531 BonEcho/2.0a3 ID:2006053104 Can anyone reproduce it with javascript disabled?
Reporter | ||
Updated•18 years ago
|
Flags: blocking-firefox2?
Target Milestone: --- → Firefox 2 beta1
Reporter | ||
Comment 5•18 years ago
|
||
see also http://forums.mozillazine.org/viewtopic.php?t=422264
Comment 6•18 years ago
|
||
(In reply to comment #4) > > Can anyone reproduce it with javascript disabled? > Yes. Sorry no Talkback installed. With JavaScript disabled Windows complained... "FIREFOX caused an invalid page fault in module MSVCRT.DLL at 0157:7800d2fb." Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8.1a3) Gecko/20060601 BonEcho/2.0a3 ID:2006060106
I've spent most of today with javascript disabled - no problems in ntdll or msvcrt. If I enable it again, Bon Echo crashes, and today it's been bad enough that I can't even start up without safe mode (long enough to turn JS back off). Yesterday's talkbacks: TB19344374M TB19343637Q TB19331144W TB19330559W TB19330313Y TB19329493G Today's (only appear when JS is Enabled): TB19378453Q TB19378292X TB19378269Q TB19372643X Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060601 BonEcho/2.0a3 ID:2006060104
Wouldn't you know that as soon as I post that comment I start having problems? Crashes with javascript disabled: TB19384698X, TB19384686H, TB19384480E, TB19384478M, TB19384454Q Crashed a few times in Safe mode too, but TB didn't seem to catch 'em.
Reporter | ||
Comment 9•18 years ago
|
||
I see over 400 [@ ntdll.dll] talkback reports from the 20060531 and 20060601 win32 builds
Comment 10•18 years ago
|
||
There is a good chance this also affects Linux builds, only the final line of the stack is libc.so.6, eg TB19386313W. I can consistently reproduce with a clean profile: 1, Start Firefox 2, go to www.google.com and do a search. Old/new term doesn't seem to matter 3, after search results are in, close Firefox 4, crashes with talkback appearing and command line output ./firefox/run-mozilla.sh: line 131: 6894 Segmentation fault "$prog ${1+"$@"} That would appear to implicate bug 335558, which re-enabled Mork form history.
Comment 11•18 years ago
|
||
Following up comment #10, I tried the same steps on Windows (the 20060531 nightly again) and got TB19387949G. Disabling form history gave another crash on exit, but none since. CC'ing brettw
Comment 12•18 years ago
|
||
Gavin made a test build with the form history patch backed out: http://gavinsharp.com/ff/firefox-1.8-20060601-1300-no335558-win32.zip No crashes so far with form history enabled.
Updated•18 years ago
|
Blocks: 335558
Summary: crash since 20060530 hourly [@ ntdll.dll] → crash since 20060530 hourly on the Firefox 2 branch [@ ntdll.dll]
Comment 13•18 years ago
|
||
same here, just compiled a fresh optimized build with the formhistory patch reversed. what is for sure gone, are the crashes when doing searches on google.com etc. which took place immediately with official builds. plus no crashes so far on closing firefox. running it for about an hour now. will report back tomorrow morning. boba
Updated•18 years ago
|
Flags: blocking-firefox2? → blocking-firefox2+
Comment 14•18 years ago
|
||
This bug should have highest priority, because it prevents user from testing nightly builds!
Comment 15•18 years ago
|
||
true, and i am pretty sure all of this is cause by this formhistory checkin: #335558 [Toolkit:Satchel]-Make storage form history use Mork if available [All] i am running a self-built 20060602 build right now for about half a day, no crashes in sight ... so someone should be reviewing the above checking and see what causes the crashes.
Comment 16•18 years ago
|
||
edit: of course i backed out that checkin in my build
Comment 17•18 years ago
|
||
Thorsten (boba), there was a further change made in bug 335558 comment #10. Could you rebuild with the latest CVS code to see if that crashes for you ? From brief testing here it still does. Are you building on windows ? The backtrace from gdb is: (gdb) bt #0 0xb6985139 in vtable for nsFormHistory () from /home/vmware/build/mozilla1.8/fx-i686-pc-linux-gnu/dist/bin/components/libtoolkitcomps.so #1 0x00000158 in ?? () #2 0xb6a78403 in XPCJSRuntime::GCCallback () from /home/vmware/build/mozilla1.8/fx-i686-pc-linux-gnu/dist/bin/components/libxpconnect.so #3 0xb5a45c9c in DOMGCCallback () from /home/vmware/build/mozilla1.8/fx-i686-pc-linux-gnu/dist/bin/components/libgklayout.so #4 0xb7f8a1da in js_GC () from ../fx-i686-pc-linux-gnu/dist/bin/libmozjs.so #5 0xb7f895f1 in js_ForceGC () from ../fx-i686-pc-linux-gnu/dist/bin/libmozjs.so #6 0xb7f60c40 in JS_GC () from ../fx-i686-pc-linux-gnu/dist/bin/libmozjs.so #7 0x08053aa8 in nsXREDirProvider::DoShutdown () #8 0x0804c59f in ScopedXPCOMStartup::~ScopedXPCOMStartup () #9 0x080513d2 in XRE_main () #10 0x0804bed7 in main () (gdb)
Comment 18•18 years ago
|
||
(In reply to comment #17) > Thorsten (boba), there was a further change made in bug 335558 comment #10. > Could you rebuild with the latest CVS code to see if that crashes for you ? > From brief testing here it still does. Are you building on windows ? > > The backtrace from gdb is: > > (gdb) bt > #0 0xb6985139 in vtable for nsFormHistory () > from > /home/vmware/build/mozilla1.8/fx-i686-pc-linux-gnu/dist/bin/components/libtoolkitcomps.so > #1 0x00000158 in ?? () > #2 0xb6a78403 in XPCJSRuntime::GCCallback () > from > /home/vmware/build/mozilla1.8/fx-i686-pc-linux-gnu/dist/bin/components/libxpconnect.so > #3 0xb5a45c9c in DOMGCCallback () > from > /home/vmware/build/mozilla1.8/fx-i686-pc-linux-gnu/dist/bin/components/libgklayout.so > #4 0xb7f8a1da in js_GC () from ../fx-i686-pc-linux-gnu/dist/bin/libmozjs.so > #5 0xb7f895f1 in js_ForceGC () from > ../fx-i686-pc-linux-gnu/dist/bin/libmozjs.so > #6 0xb7f60c40 in JS_GC () from ../fx-i686-pc-linux-gnu/dist/bin/libmozjs.so > #7 0x08053aa8 in nsXREDirProvider::DoShutdown () > #8 0x0804c59f in ScopedXPCOMStartup::~ScopedXPCOMStartup () > #9 0x080513d2 in XRE_main () > #10 0x0804bed7 in main () > (gdb) > hey nick, yes i am building for/on windows under cygwin with VC7. what exactly do you want me to do? do a fresh build "including" that checkin which seems to cause the problems? what other changes regarding that checkin are you talking about in detail? i don't see a new patch for that checkin yet ... Thorsten
Comment 19•18 years ago
|
||
I'm asking you to build with * rev 1.51.4.5 of mozilla/toolkit/components/satchel/src/nsFormFillController.cpp * rev 1.8.8.2 of mozilla/toolkit/components/satchel/src/Makefile.in What happened was: 1, brettw's patch modifies both Makefile.in (to rev 1.8.8.1) & nsFormFillController.cpp (rev 1.51.4.5), causing the form history crashes 2, dougt modified Makefile.in to fix Minimo (bug 335558 comment #10, not an attached patch, gives rev 1.8.8.2) 3, Bug 339661 later modified nsFormFillController.cpp (rev 1.51.4.6), it would be good to avoid this change to avoid further confusion.
Comment 20•18 years ago
|
||
(In reply to comment #19) > I'm asking you to build with > * rev 1.51.4.5 of > mozilla/toolkit/components/satchel/src/nsFormFillController.cpp > * rev 1.8.8.2 of mozilla/toolkit/components/satchel/src/Makefile.in > > What happened was: > 1, brettw's patch modifies both Makefile.in (to rev 1.8.8.1) & > nsFormFillController.cpp (rev 1.51.4.5), causing the form history crashes > 2, dougt modified Makefile.in to fix Minimo (bug 335558 comment #10, not an > attached patch, gives rev 1.8.8.2) > 3, Bug 339661 later modified nsFormFillController.cpp (rev 1.51.4.6), it would > be good to avoid this change to avoid further confusion. > ok lemme do a real_fast-update and see that i get the makefile revision you asked for and then do a build with the checkin included
Comment 21•18 years ago
|
||
allright, the new build ... including the latest revision of the Makefile.in for the satchel formhistory thing, is not crashing anymore when doing google.com searches, like the previous builds did. though i always get crashes on closing firefox now. maybe this is still due to the other bug checkin you mentioned (Bug 339661). i'll try another one with these changes backed out later .... Thorsten
Comment 22•18 years ago
|
||
(In reply to comment #10) > There is a good chance this also affects Linux builds, only the final line of > the stack is libc.so.6, eg TB19386313W. Yeah I've gotten lots of such crashes for a week or so, either when closing or (more frequently) when starting after having had to kill both firefox and firefox-bin processes. TB19478893G TB19479184M
Updated•18 years ago
|
Severity: critical → blocker
Comment 23•18 years ago
|
||
Discussed with brettw earlier, he's going to back out the change to use mork instead of sqlite later today.
Assignee: nobody → brettw
Comment 24•18 years ago
|
||
*** Bug 340759 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 25•18 years ago
|
||
Since this regression started we have had 87 patches that landed and have been virtually untested for regressions on branch. I can't believe this is happening in the pre beta1 stage
Assignee | ||
Comment 26•18 years ago
|
||
Perhaps this is bug 340882 that this change tickled.
Assignee | ||
Comment 27•18 years ago
|
||
The patch for bug 340882 is in. Let's see if that fixes it.
Comment 28•18 years ago
|
||
nope, didn't fix it ... ntdll.dll crashes right aways, after doing one google search and closing firefox after it.
Assignee | ||
Comment 29•18 years ago
|
||
Can somebody who can reproduce this problem see if this problem is related to the contents of your form history? What if you rename formhistory.dat and run Firefox to get a new one?
Comment 30•18 years ago
|
||
(In reply to comment #29) > Can somebody who can reproduce this problem see if this problem is related to > the contents of your form history? What if you rename formhistory.dat and run > Firefox to get a new one? Not exactly answering your question: my steps-to-reproduce in comment 3 involved a website I've never been to, and corresponding form history was empty for that text box. In fact, entering stuff into boxes with empty form history seems more likely to reproduce the crash.
Comment 31•18 years ago
|
||
I cleared my form history either late yesterday or early today and haven't had a crash with today's build. Can people who can reproduce this with today's or tomorrow's builds please reference their talkback ids ?
Comment 32•18 years ago
|
||
I did some playing around searching for stuff in google. I find that entering a form term that *was* in the form history before does not crash, no matter how much I try. Actually using the history dropbox to select terms is safe too. However, if I add new history entry by googling for something new, it's quite likely to crash very soon (most often at submit or at browser close). Hopefully this helps ~
Comment 33•18 years ago
|
||
I've installed the new build with talkback, and removed my old formhistory.dat and formhistory.sqlite files. Haven't seen any crashes during normal browsing yet, but did crash twice at browser close. Also, if it helps, from 6/1 until this morning I've been using Gavin's build with the patch backed out - no crashes at all, ever. TB19681314G, TB19681080Y Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060609 BonEcho/2.0a3 ID:2006060903
Comment 34•18 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060609 BonEcho/2.0a3 ID:2006060903 Step to reproduce crash on exit: 1) Create new profile 2) Start Firefox 3) Click in searchbar 4) Press down arrow key once or twice 5) File -> Exit Talkback ID TB19688491E
Assignee | ||
Comment 35•18 years ago
|
||
Should be fixed by the patch in bug 335558. This bug was caused by me forgetting to update the module file with the changes to the compile flags, and the module file used the storage header file whenever storage was enabled. The result was that the new and delete in the module thought the object was the size of the storage, version, but the actual implementation was the mork version which was a little bigger. The result was heap corruption.
Comment 36•18 years ago
|
||
(In reply to comment #35) > Should be fixed by the patch in bug 335558. Seems to be stable for me... running build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060609 BonEcho/2.0a3 ID:2006061002
Comment 37•18 years ago
|
||
v. with ozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b1) Gecko/20060813 BonEcho/2.0b1
Status: RESOLVED → VERIFIED
Updated•18 years ago
|
Keywords: fixed1.8.1 → verified1.8.1
Updated•13 years ago
|
Crash Signature: [@ ntdll.dll]
You need to log in
before you can comment on or make changes to this bug.
Description
•