30477 - Crash Clicking on Sidebar Tabs after running -installer

Status: VERIFIED FIXED

(SeaMonkey :: Sidebar, defect, P3)

Description

[Alan S. Jones]

This is a very strange bug.  I am running Win95 Mozilla build 2000030409.
Using this build with the new sidebar tabs you reprodce the crash as if you were 
a new user...

1. Delete the Moz*.dat files in your windows directory
2. Delete the users50 directory
3. Run "mozilla -installer"
4. Accpet to convert the profile
5. As you see the browser load click on the tabs for Bookmarks (even though it 
is loaded), then Tinderbox, Search, then finally What's Related.
6. While the tab "What's Related" is loading I get a crash in NECKO.DLL

I have reproduced this crash almost everytime I tried (5 times now).  The one 
time it did not crash was when i delayed for a long time clicking on the tabs 
(step 5).  Right after it worked and I played a second, went back though the 
steps and ran it back through the crasher steps and it crashed.

It probably won't help, but here the DR Watson log....


MOZILLA caused an invalid page fault in
module NECKO.DLL at 014f:6057cf5b.
Registers:
EAX=00000000 CS=014f EIP=6057cf5b EFLGS=00010202
EBX=00000000 SS=0157 ESP=01a0fe30 EBP=01a0ff14
ECX=023f8fa4 DS=0157 ESI=023f7370 FS=550f
EDX=8165e8f0 ES=0157 EDI=023f73cc GS=0000
Bytes at CS:EIP:
8b 08 ff 51 0c 53 8b cf e8 ec 15 00 00 8b 46 68 
Stack dump:
00000000 023f7374 023f7374 60be6570 60c7bdb8 00000005 0000003f 0000002d bff79666 
bff74277 bffbf9e0 bff79682 bff713e2 0000014f bff96868 8165eb58

Comment 1

[Alan S. Jones]

Thinking about this bug I am requesting beta1 PDT+ evaluation.  This bug does 
not occure for people that just install new build on top of old one not removing 
prefs ect.  Thinking about this bug seems to be one that would affect peopole 
new to mozilla.  Not a good first impression a nice big crash.

Comment 2

[Paul MacQuiddy]

I can't reproduce this. What is your home page that you're loading? Do you have 
a large bookmarks file that is converted over? Does it always crash in 
necko.dll?

Can you give even more precise details on reproducing this? Can you reproduce 
*without* converting a profile over?

Comment 3

[Alan S. Jones]

I do have a large bookmarks file.  It does notseem to crash if I don't run 
-installer.  My home page itself is very simple so I don't think that is the 
problem http://users.ipa.net/~asj

I was worried about this from the standpoint of new users and first impressions. 
 If it is only me then this bug can wait.  As I write this I am at the office 
and away from the comptuer that has mozilla on it.

Comment 4

[leger]

Putting on PDT- radar for beta1.  Remove PDT- if reopens with 100% reproducible.

paulmac, can you find a Talkback stacktrace on this?

Comment 5

[Paul MacQuiddy]

asj, does this happen when you don't click on the tabs, and just run the 
installer? What if you rename your bookmarks in your 4.7 profile, then just 
create a small one, then run -installer? I'm trying to figure out if it's your 
bookmarks file or the sidebar or a combination of it that is the problem.

Comment 6

[Alan S. Jones]

Running -insaller without my existing bookmarks file still crahes when Mozilla 
walkingup the sidebar tabs.  (I actually renamed my bookmarks file so nothing 
was there except for some ie favorats that was very small.  

I had the crash not happen one time for me.  It was when I waited to click on 
the sidebar tabs.  If i click on the sidebar tabs fairly quickly it always 
happens.

Comment 7

[Alan S. Jones]

Ok, I have narrowed this bug down not to Netscape, but IE Favorites....
on Win95 C:\WINDOWS\Favorites\Imported Bookmarks

I don't even use IE and forgot there were 2 links there.

I had others in Mozillazine test some for me, but they did not want to trash 
their IE Fav stuff.

I am going to attach a ZIP file (full path, recursed directory, storing 
attributes) if anyone is brave enough to try my original bug steps.   Again the 
bug does not occure as often if you wait before clicking on the sidebar tabs.  
So click as soon as your see them and scroll through.

After running moziilla -installer no users50 or moz*.dat...

Comment 8

[Alan S. Jones]

Attachment: IE's C:\WINDOWS\Favorites\ for testing

Comment 9

[Alan S. Jones]

I took a wild guess and got M14 with talkback (should have gotten it eariler).  
Even though this build does not have the new fancy tabs it still was able to 
crash.  Although it did not crash as quickly as the more current builds.  I 
had to click through the tabs 3 or 4 times then crash.

I just sent in my talkback info under this e-mail and mentioned this bug number. 
If someone wants to follow up on that end.

Comment 10

[Paul MacQuiddy]

Here is all we get from the dump:


 Call Stack:    (Signature = nsFileTransport::Process 5b97409e) 
     
   nsFileTransport::Process 
                            
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsFileTransport.cpp, line 1090]

Comment 11

[Alan S. Jones]

[e-mail], were you brave enough to try my Favorites folder?  That 
seems to be the problem.

If you want to type direct on this I should be in #mozillazine and #mozilla 
Tuesday from 7pm central till...  I know some QA people don't have an IRC client 
so there is also this http://www.mozillazine.org/chat/

Comment 12

[Paul MacQuiddy]

Amazingly enough, I'm able to reproduce this almost every time by:
1. Creating a profile in 4.7
2. Running mozilla.exe -installer and choosing to migrate the profile over
3. Running that profile and as soon as the sidebar tabs show up, start click 
fairly quickly, but not too quickly on the tabs, starting at the bottom and 
working your way up. I usually crash right when I clicking on what's related, 
always in necko.dll, always the same stack.

Comment 13

[Paul MacQuiddy]

removing the PDT- since leger said to if I could reproduce it reliably. I'm 
going to guess and assign this to warren. 

Note: I'm able to reproduce this without asj's favorites folder. But I wonder if 
this has something to do with the importing of IE favorites that is done on 
profile migration, since I can only reproduce on the first launch of a migrated 
profile.

Comment 14

[Alan S. Jones]

YA!!! Thatt is bascily my steps to crash

Note: I don't crash if I rename that Favorites folder to something else so it is 
not migrated.

Comment 15

[Paul MacQuiddy]

it seems perhaps easier to reproduce it with your files, but I was able to 
reproduce it without any favorite directory at all.

note: I'm on win98 using 0031613 build

Comment 16

[selmer (gone)]

Chris, does this look like a corrupted RDF file symptom to you?

Comment 17

[Chris Waterson]

I'm dubious. I'd need to see a stack trace.

Comment 18

[Paul MacQuiddy]

All I get out of talkback is the one line posted above.

Comment 19

[selmer (gone)]

Paul, can you reproduce on a debug build?

Comment 20

[Paul MacQuiddy]

I could try - I don't have one - any volunteers to let me borrow there windows box?

Comment 21

[Phil Peterson]

[PDT+] w/b minus on 3/10

cc chofmann to explore frequency of stack trace in Talkback.

Comment 22

[Paul MacQuiddy]

I can get this to happen on start-up almost every time, whether or not I am 
migrating a profile. However, I can't reproduce it once start-up (whatever that 
is) has completed.

In other words, if I just start a normal page load and then run thru the series 
of steps noted above, I can't reproduce the crash. 

However, see bug 29882 for the same one line stack trace, though I don't 
know if that's relevant. Here are the steps for it:


1. open Preferences.
2. click on any of the categories to highlight it.
3. hold down either the down or up arrow keys to navigate through the category
tree.

Comment 23

[Chris Waterson]

Hey warren, I can crash pretty much all the time changing between sidebar tabs. 
It looks like we're cancelling an about:blank load (the mSpec == "<unknown>") 
while changing between panels. mSource == 0 at line 1068 of nsFileTransport.cpp 
when we crash.

Comment 24

[Chris Waterson]

Attachment: one way to fix the problem

Comment 25

[Chris Waterson]

So one way to fix it is just to check mSource before dereferencing. Although I 
don't know if this is just indicative of some deeper problem.

We know that the transport has somehow gotten into the END_WRITE state, 
which is a bit weird if we're actually cancelling an about:blank load (how else 
would we get an mSpec of "<unknown>"?)

Feh. I don't know what's going on here.

Comment 26

[chris hofmann]

good one to fix if we can find a low risk fix.
this stack signature is showing up in a goodly amount
of recent crashes. 131 instances of this crash in the 
last starting back in Feb., but a big uptick in
the recent builds.

Comment 27

[chris hofmann]

Attachment: user comments and blackbox id's on recent crashes

Comment 28

[chris hofmann]

Attachment: More user comments/testcases and blackbox id's on recent crashes

Comment 29

[chris hofmann]

Attachment: And even more user comments and blackbox id's on recent crashes

Comment 30

[chris hofmann]

looks like some folks generate this same stack signature when playing
around with/interupting/finishing ftp downloads.

Comment 31

[Warren Harris]

Ok, let's just go with the fix Chris submitted. I don't know why mSource is 
getting set to null, but the fix looks harmless. Chris: Can you check it in?

Comment 32

[Warren Harris]

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

Comment 33

[Simon Fraser [no longer active]]

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

Comment 34

[Simon Fraser [no longer active]]

Waterson's fix works for me on mac, fixing the crash switching between sidebar 

panels.

Comment 35

[Warren Harris]

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

Comment 36

[Simon Fraser [no longer active]]

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

Comment 37

[Warren Harris]

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

Comment 38

[Daniel (Leaf) Nunes]

updating keywords, severity.

Comment 39

[Chris Waterson]

ok, i checked in the patch. a=gramps, leaf

Comment 40

[J.J. Enser]

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

Comment 41

[Asa Dotzler [:asa]]

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

Comment 42

[Asa Dotzler [:asa]]

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

Comment 43

[Paul MacQuiddy]

verified with all the duplicates and the original test case, rock on, smelling
donuts