crash when opening a link in a new tab [@ 0x12eaa0c8]

VERIFIED WORKSFORME

Status

()

--
critical
VERIFIED WORKSFORME
13 years ago
7 years ago

People

(Reporter: tonymec, Unassigned)

Tracking

({crash, stackwanted})

1.5.0.x Branch
x86
Windows XP
crash, stackwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051029 Firefox/1.5
Build Identifier: "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051027 Firefox/1.5", build ID:2005102703

See Talkback event TB11217283Y

Sorry I can't tell you where in the code the violation happened: the Talkback query servers are down at the moment.

Reproducible: Didn't try

Actual Results:  
Program crashed

Expected Results:  
Program should have opened a new tab with the linked URL in it.

The link in question was both a link and an image; I don't know if this is relevant.

Talkback event ID: TB11217283Y
Update: I could query Talkback about this incident

Stack signature  0x12eaa0c8 37811a59

Source file and line: N/A

Updated

13 years ago
Keywords: crash, talkbackid

Comment 2

13 years ago
Incident ID: 11217283
Stack Signature	0x12eaa0c8 37811a59
Product ID	Firefox15
Build ID	2005102703
Trigger Time	2005-10-29 08:34:10.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	
URL visited	
User Comments	opening a link in a new tab. I can't copy the URL now that the browser has crashed.
Since Last Crash	78286 sec
Total Uptime	140829 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
0x12eaa0c8
0x778b0c24
0x00200064
0xa1b15808

i don't recognize this address as any particular windows system library ... it'd be nice to know if there's a library loaded there ...
Keywords: talkbackid → stackwanted
Summary: crash when opening a link in a new tab → crash when opening a link in a new tab [@ 0x12eaa0c8]
(In reply to comment #2)
[...]
> i don't recognize this address as any particular windows system library ...
> it'd be nice to know if there's a library loaded there ...
> 

How can I help debug this crash? I haven't rebooted since then but I have upgraded Firefox. Would it help if I posted the list of my extensions?

Comment 4

13 years ago
well, you could try bug 307577 comment 12
basically, install windbg, file>open executable>browse to firefox.exe
debug>go
follow steps from bug 307577 comment 12

if analyze -v actually mentions some interesting libraries in the stack trace, copy the analyze -v output here ...

otherwise you'll need to find someone who has a debug build with symbols (either as a package or configured using a symbol server), and you would repeat the process using their build.

if you can't find someone w/ such a build, you could build your own (using the free vc71 compiler, or using any non free msvc60/70/71/80 compiler you happen to own) and repeat the steps w/ that build.
(In reply to comment #4)
> well, you could try bug 307577 comment 12
[...]

I don't understand the procedure; could you explain it to me in more detail (either as a further bug comment, or by private email if you don't want to spam the bug)?

Please note that:
- I have a windbg.exe on my HDD (version 6.4.7.0 dated 10-JAN-2005) but I'm not familiar with how to use it
- my current Firefox build is not the one which crashed, but a later nightly, namely "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051030 Firefox/1.5", build ID:2005103002 (the crash happened with 2005102703 as noted above)
- I don't know how to reproduce the bug, nor has it happened again spontaneously
- I don't have MSVC; I have cygwin gcc and Borland BCC32 (5.5); I am not convinced of my ability to compile Firefox successfully; I'm not aware of anyone who would "give" me a copy of a Firefox executable with debugging symbols if Mozilla's nightlies don't have them.
- Where do I find the crash dump (if any)? A search of my hard drive for .dmp gives only the following results:
  * C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson\user.dmp (size 7K, dated 23-JAN-2005 06:12)
  * C:\cygwin\bin\xemacs-21.4.15-4035492d.dmp (size 2.8 M, dated 24-FEB-2004 16:49)
  * C:\WINDOWS\Minidump\Mini013005-01.dmp (size 88K, dated 30-JAN-2005 13:35)
- If I start Talkback (i.e., "C:\Program Files\Mozilla Firefox\extensions\talkback@mozilla.org\components\talkback.exe"), I see no backlog of incindents. I'm not sure if this results from reinstalling Talkback together with Firefox or from manually deleting incidents after reporting them to Bugzilla.


... and if the above shows that I goofed somehow, please tell, so I won't do it again in the future.



Best regards,
Tony.

Comment 6

13 years ago
i have 6.5.0003.7, in general you really want the latest version of windbg as they're constantly improving it (occasionally i run older versions and the ui depresses me), but the commands we need have been around since forever, so don't feel like i'm forcing you to upgrade :).

c:\windows\minidump contains dumps from when your system blue screens :). the user.dmp if it was recent would be the dump you'd want to open.

anyway:
steps:
1. run firefox
2. when it crashes, you should get a dialog from windows (this is a drwatson dialog) - don't dismis it!
3. run windbg
4. file>attach to process (or f6)
5. select the firefox process from the list
6. click ok
7. view>command (or alt-1)
8. .symfix+
9. .reload
10. !analyze -v

copy that output here.

for getting symbols and a build, you'd probably need to ask around in the firefox forums or on irc.mozilla.org

afaik gcc windbg don't talk wellenough for it to be worth trying, and bcc doesn't build mozilla (it was on my list of things to work on a while ago, but that list is huge and ever growing).

if you're not comfortable building, that's fine, we can start by not trying to do that :). i'm hoping the output from analyze will be good enough.
(In reply to comment #6)
> i have 6.5.0003.7, in general you really want the latest version of windbg as
> they're constantly improving it (occasionally i run older versions and the ui
> depresses me), but the commands we need have been around since forever, so
> don't feel like i'm forcing you to upgrade :).

I see.
> 
> c:\windows\minidump contains dumps from when your system blue screens :). the
> user.dmp if it was recent would be the dump you'd want to open.

It dates from January; this crash was in October, so it can't be that.
> 
> anyway:
> steps:
> 1. run firefox
> 2. when it crashes, you should get a dialog from windows (this is a drwatson
> dialog) - don't dismis it!

the dialog asking me if I want to send crash data to Microsoft, isn't it? -- until now, once the Talkback crash wizard had woken up I would answer "send nothing to Microsoft".

> 3. run windbg
> 4. file>attach to process (or f6)
> 5. select the firefox process from the list
> 6. click ok
> 7. view>command (or alt-1)
> 8. .symfix+
> 9. .reload
> 10. !analyze -v
> 
> copy that output here.

Well, I'll do that the next time I get a crash. I guess that for this crash the dump (if any) is lost. For now I'm voting for this bug, both because it hit me and so I'll be able to find it back when needed.
> 
> for getting symbols and a build, you'd probably need to ask around in the
> firefox forums or on irc.mozilla.org
> 
> afaik gcc windbg don't talk wellenough for it to be worth trying, and bcc
> doesn't build mozilla (it was on my list of things to work on a while ago, but
> that list is huge and ever growing).

If you say so... I build Vim with gcc, using Bram Moolenaar's sources, but it's much smaller than Firefox IIUC, and it has a good Make_cyg.mak to build a non-cygwin Windows executable using Cygwin (and MinGW for cygwin) gcc.
> 
> if you're not comfortable building, that's fine, we can start by not trying to
> do that :). i'm hoping the output from analyze will be good enough.

I guess I don't have the right tools (programs and HowTo files) to build Mozilla Firefox -- as for the output from analyze, IIUC the crash dump is lost and I don't know how to reproduce the crash. I suppose we will have to mark this bug RESOLVED WORKSFORME and try getting more crash info if and when the crash reoccurs, what do you think?

BTW, where does Talkback store its crash info? Is it possible to copy it elsewhere in order to avoid its being overwritten by a Firefox (and Talkback) upgrade?

Comment 8

13 years ago
yes the send data to microsoft dialog. basically while that dialog is open, your crashed app isn't quite dead. it's just crashed. while it's in this state, we can debug it. :)

if you click on "my bugs" (and it doesn't list this bug...), "edit search" and control-click "unconfirmed", you can then search and save your search as "really my bugs"...

the problem is that gcc symbols are elf and windbg wants coff/pdb. it's not that the binaries don't run, but the symbols aren't compatible which makes the binaries about as unhelpful as the talkback binaries. (you could use gdb, but i'm not going to try to talk you through that, and you might as well just setup vc71, which has the advantages of being a decent optimizer among other things).

if you want to resolve the bug as worksforme, that's fine, i don't really care about bug status, i care about eventually finding causes of bugs (if no one touches the bug for a long enough time, someone will probably automatically resolve the bug).

talkback stores its data temporarily in application data, but its data really isn't veruy helpful, the data it has is sent to the talkback server which returns the incident id you provided at the beginning. the talkback server has more info than the talkback client collected (because it has symbols). but afaik the client didn't record what modules were loaded where which is the first detail we'd need. - in short, just copy your incident ids into bugs asap and don't worry about upgrades :).

thanks for your prompt replies. note that i'm also very patient, i'll work on bugs even if they take years to get from state to state, and as long as the bug has certain magic words in it, i'll see it whenever it gets updated.
Well, thanks for your patience and for your explanations. Too often, alas, non-Mozilla-savvy guys like me get rebuffed with statements like "fix the bug yourself or stop the bugspam" which are not very helpful -- and I confess that recently I said something like that myself (a little more politely and with a link to the Bugzilla etiquette page) to someone who was being repeatedly obnoxious. Ah la la, nobody's perfect.

Me, I'm ready to do whatever I can to have a fix brought to the bugs that hit me; but in this case I feel at a loss: the bug happened to me only once AFAICT (unless it is another manifestation of some other bug for which Talkback found symbols), and I don't feel like I can help fixing this bug unless it manifests again. If you think you can "make the Talkback report talk", then of course I wouldn't stop you from doing so; or if you can find another bug which exhibits the same symptoms, we can decide one of them is a dupe of the other. Otherwise the notion of WORKSFORME was to table the matter "until another crash comes along" without labeling it INVALID (I did get a crash after all, it's just that I can't put the finger on what was the cause of the crash -- AFAIK it could even be a Microsoft bug) or as WONTFIX (I hope it will get fixed if the right kind of info comes around).

OK, so I'm marking this bug WORKSFORME for the reasons noted above. I'm also adding you to the CC, but feel free to remove yourself if you don't want to see every future change on this bug. :-)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
Version: unspecified → 1.5 Branch

Comment 10

13 years ago
i actually watch nobody, so i don't need to be on cc lists :) you'll probably see me listed as getting mail for almost any change you make to just about any bug in bugzilla.

in some ways i hope you don't encounter the problem again (i.e. that you enjoy the product), but if you do, you'll have more things that you can do to try to get information to help us track it down.
Status: RESOLVED → VERIFIED

Comment 11

13 years ago
I've been running across similar instances of this bug report. This problem has been occurring off and on for several months (with and before Firefox 1.5; current build is 20060111). Most often it will crash on any instance of opening a new tab (Ctrl+T, Right mouse click context menu on page or bookmark, link in a TBird email, etc.) but not always. Very difficult to reproduce and none of the instances seem to have something in common.

Here are some Talkback Incident IDs along with the comments:
TB16397809G - Opening a new tab
TB16494674G - Pressed Ctrl+T
TB17004279E - Clicking on link that opened up pop-up window
TB17004506W - Clicked on link to open a Word doc

If this is not similar, please let me know and I'll go hunting for another bug report and log a bug if I can't find any. I love Firefox and TBird and hope that I can help as I am able.
(Assignee)

Updated

7 years ago
Crash Signature: [@ 0x12eaa0c8]
You need to log in before you can comment on or make changes to this bug.