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)

Product:
Firefox
Component:
General
Version:
2.0 Branch
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED FIXED
Milestone:
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
Summary: crash [@ ntdll.dll] → crash since 20060531 nighly [@ ntdll.dll]
Summary: crash since 20060531 nighly [@ ntdll.dll] → crash since 20060531 nightly [@ ntdll.dll]
Stack from Firefox shutdown crash
TB19349393Z
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
(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?
Flags: blocking-firefox2?
Target Milestone: --- → Firefox 2 beta1
(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.  
I see over 400 [@ ntdll.dll] talkback reports from the 20060531 and 20060601 win32 builds
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.
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
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.
Blocks: 335558
Summary: crash since 20060530 hourly [@ ntdll.dll] → crash since 20060530 hourly on the Firefox 2 branch [@ ntdll.dll]
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
Flags: blocking-firefox2? → blocking-firefox2+
This bug should have highest priority, because it prevents user from testing nightly builds!


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.
edit: of course i backed out that checkin in my build
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)

(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


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


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
No longer blocks: 335558
(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
Severity: critical → blocker
Discussed with brettw earlier, he's going to back out the change to use mork instead of sqlite later today.
Assignee: nobody → brettw
*** Bug 340759 has been marked as a duplicate of this bug. ***
Keywords: topcrash
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
Perhaps this is bug 340882 that this change tickled.
The patch for bug 340882 is in. Let's see if that fixes it.
nope, didn't fix it ... ntdll.dll crashes right aways, after doing one google search and closing firefox after it.
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?
(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.
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 ?
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 ~
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

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
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.
Status: NEW → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
(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
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
Crash Signature: [@ ntdll.dll]
You need to log in before you can comment on or make changes to this bug.