453952 - firefox doesn't behave the way the reporter wants with a file-open-dialog

Status: RESOLVED INCOMPLETE

(Core :: Widget: Cocoa, defect)

Description

[Albert Zeyer]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

file-open-dialog came up after I clicked on a file-selection-upload-button. When I tried to select a file, Firefox freezed (did not respond anymore). After killing, I get the attached backtrace.

Reproducible: Didn't try

Comment 1

[Albert Zeyer]

Attachment: useless (no symbols)

backtrace generated by Apple debugger, not breakpad because breakpad did not cover this freeze

Comment 2

[Arthur Wiebe]

Albert, can you reproduce this at all?

Please provide the web page you were at when this crashed as well.

It seems you uploaded the crash log fine so it must be something specific to the web page.

Comment 3

[Albert Zeyer]

It was on an Ilias-site:

http://www.matha.rwth-aachen.de/ilias3/login.php?target=&soap_pw=&ext_uid=&cookies=nocookies&client_id=matha.rwth-aachen.de&lang=de

Though I am not sure if the bug occured in Firefox itself or in the file-open-dialog (should be independend from the site).

Another thing which happend at the same time when the dialog was already open was a popped up question-dialog by the Firefox Add-on "ReloadEvery 3.0.0" (which asked if the data should also be reloaded when there was some POST-data). I tried to click immediatly on "yes" there but I am not sure if I hit it in time (because the file-open-dialog popped up). Put perhaps, could it be possible that a reloaded page with a file-selection-element could make trouble in an already opened file-open-diaog?

Comment 4

[Albert Zeyer]

Yes, I can reproduce it. I activated the ReloadEvery function for all 10 seconds on the file-selection-site and then tried to select the file (therefore it openes the file-open-dialog). I waited there until the question by ReloadEvery popped up about if it should also resend the POST-data. I tried to click on "yes" but it seemed already crashed. At least it did not respond anymore then.

Comment 5

[timeless]

what the user is reporting is at most a hang, but probably just a restriction such that only certain windows can respond until after he's dismissed the dialog which he probably can't dismiss until he dismisses some other dialog, this is part of the wonders of window stacking.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

This sounds a lot like bug 436473 (and bug 442442).

As timeless noticed, the trace posted here (in comment #1) is
basically useless, because the build from which it was made contains
no debug symbols.

Comment 7

[Albert Zeyer]

(In reply to comment #6)
> As timeless noticed, the trace posted here (in comment #1) is
> basically useless, because the build from which it was made contains
> no debug symbols.

There are debug symbols, at least in XUL, firefox-bin, AppKit and all other stuff which belongs to Firefox. The parts with "???" seem to me like messed up stack data (the adress seems to be wrong, 0xffff026d or 0x5e4b5), perhaps a stack overflow. It seems also that _XRE_GetFileFromPath is calling itself recursivly very open (not sure if that is correct).

I have just the original Firefox binary from here: http://www.mozilla-europe.org/de/firefox/

Comment 8

[Steven Michaud [:smichaud] (Retired)]

Yes, your backtrace (attachment 337188 [details]) does give you the illusion
that it's reporting debug symbols.  But it's only an illusion -- all
(or almost all) the Firefox-specific symbols are spurious/incorrect.
So, for example, none of the references to _XRE_GetFileFromPath are
accurate.

The reason is that all downloadable distros of Mozilla.org browsers
(releases, betas and nightlies) have most of their debug symbols
stripped out.  When Apple's crashreporterd generates a stack, it
starts with numeric addresses, and tries to translate them into
human-readable symbols.  But if it can't find a symbol at a particular
address, it usually tries to pick one nearby -- which is usually
incorrect.

I've never understood why the build process for "installers" strips
out debug symbols (maybe it's to save room).  And (somehow) this
doesn't prevent Breakpad from reporting symbols accurately.  But it
makes using other tools (like crashreporterd and gdb) much more
difficult, and for that reason is really a pain.

Outside of using Breakpad (which only reports crashes), the only way
to get accurate symbols is to build the program yourself (a debug
build or an opt build with debug symbols) and run that.

Comment 9

[timeless]

> I've never understood why the build process for "installers" strips
> out debug symbols (maybe it's to save room).

it is, specifically there was (and presumably still is) a download time/size requirement for firefox (<5mb) and debug symbols are huge.

> And (somehow) this doesn't prevent Breakpad from reporting symbols accurately.

they're only stripped, not deleted. breakpad is like any other debugger
1. get the raw stack
2. look for symbols
3. build a proper stack trace if symbols are available

the difference is that 2+3 are done server side and they *are* available there.

> But it makes using other tools (like crashreporterd and gdb) much more
> difficult, and for that reason is really a pain.

you can try to convince the vendor not to do stripping, however the download size/speed win/loss will almost certainly result in the vendor ignoring your plea.

Comment 10

[Albert Zeyer]

Isn't it possible to attach with breakpad to the process when it hangs? Or to create a dump somehow with breakpad when it hangs?

Comment 11

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #10)

That's actually not a bad idea.

Breakpad doesn't currently do this, but it might be feasible.  Someone
else has already made the suggestion at bug 429592.

Comment 12

[Wayne Mery (:wsmwk)]

Albert, please retest with newer version and update or close bug. Thanks.

Comment 13

[Wayne Mery (:wsmwk)]

(In reply to comment #12)
> Albert, please retest with newer version and update or close bug. Thanks.

http://www.mozilla.com/firefox/beta/

Comment 14

[Ed Morley [:emorley]]

Closing since now after whiteboard closeme date and no reply to last comment.

Please reopen/comment with further info, if you still see this issue with Firefox 3.6.13 or later in safe mode:
http://support.mozilla.com/kb/Safe+Mode

If you wish, you can also try to reproduce in Firefox 4 Beta 8 or later:
http://www.mozilla.com/en-US/firefox/all-beta.html