453615 - GPGee explorer shell extension changes floating point precision (file open/save dialogs) causing Crash on opening mails containing http:// links after having opened a mail containing a file:// link before [@ JS_strtod]

Status: RESOLVED INVALID

(Thunderbird :: General, defect)

Description

[Patrick]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: version 2.0.0.16 (20080708)

First off: It took me a long time to narrow down what causes the crash and what doesn't, because it's really not that easy to reproduce. It seems just random at first. The crash doesn't happen with Thunderbird 3.0 alpha 2, but it happens 100% reproducibly in Thunderbird 2.0.0.16. I hope this can be fixed soon, because it causes great pain to users who actually make use of file:// links in mails.

The following pre-requisites must be met in order to be able to reproduce the crash:

* Thunderbird must be allowed to open file:// links in mails (see below)
* You must have an email with a file:// link in it (for example <file:///C:/WINDOWS>)
* You must have an emali with a http:// link in it (for example <http://www.mozilla.org>)

To allow Thunderbird to open file:// links, you need to put the following lines into the profile's user.js:
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "mailbox://");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");


Reproducible: Always

Steps to Reproduce:
1. Open the mail with the http:// link in it
2. Open the mail with the file:// link in it
3. Open the mail with the http:// link in it again
Actual Results:  
Crash

Expected Results:  
no crash, obviously

Talkback crash ID: TB49338988W

Comment 1

[Patrick]

Correction:

Steps to Reproduce:
1. Open the mail with the http:// link in it
2. Open the mail with the file:// link in it
3. Click the file:// link
4. Open the mail with the http:// link in it again

Comment 2

[Steve Simms]

I'm not able to reproduce on WinXP, 2.0.0.16.  Can you get this to happen with a fresh install of Thunderbird on a different computer?

Comment 3

[Patrick]

(In reply to comment #2)
> I'm not able to reproduce on WinXP, 2.0.0.16.  Can you get this to happen with
> a fresh install of Thunderbird on a different computer?

Bummer. I tried it on another computer, and can't reproduce it myself. But I have the described behaviour on multiple computers at my workplace, including the Thunderbird installation on my testing desktop (a VM with Windows XP in it). I of course tested with a new profile, without any extensions etc. (and the crash was always reproducible) - but never tried a completely new Thunderbird installation.

Now my question is, what makes Thunderbird behave differently in this case? Where else than in the profile folder does it store data that can influence its behaviour? All systems I was testing on were Windows XP, Thunderbird 2.0.0.16. The ones that crash have been updated from 2.0.0.14 IIRC, but that's about the only difference I can spot. Please tell me where to look so I can investigate this further.

Comment 4

[Steve Simms]

What happens if you copy a profile from a machine that currently exhibits the crash over to a machine that doesn't?

I'd expect Thunderbird to keep as much as possible in the profile rather than in something like the registry, since it's cross-platform, but I don't know for sure.

Are there any other lines in the user.js file that aren't in the profiles that are working?

Comment 5

[Patrick]

(In reply to comment #4)
> What happens if you copy a profile from a machine that currently exhibits the
> crash over to a machine that doesn't?

Forgot to mention that I did that exactly before writing comment #3. Even with the copied-over profile, with which I can produce the crash 100% reliably, I can't get Thunderbird to crash on the other machine. Both the same version, Windows XP (different language though, but no pattern here, when I think of the other computers where it crashes and where not), same (virtual) hardware.

> I'd expect Thunderbird to keep as much as possible in the profile rather than
> in something like the registry, since it's cross-platform, but I don't know for
> sure.

I thought so, too.

> Are there any other lines in the user.js file that aren't in the profiles that
> are working?

No, allowing to open file:// links is the only thing I changed. I diff'ed the prefs.js (which contain user.js entries after one start of Thunderbird) of one working and one crashing machine, and it only gave me the lines of different paths as well as some update check timestamps.

I'm really out of ideas here.

Comment 6

[Wayne Mery (:wsmwk)]

don't have any specific advice about diagnosis. perhaps this is CAPS related, but I'm not finding any open CAPS crashers or related bugs.

stack indicates possible dupe of bug 431250, which is still a thunderbird topcrash (but its frequency is really quite low - 6 in 10 days)

TB49338988W
JS_strtod  [mozilla/js/src/jsdtoa.c, line 1243]
js_strtod  [mozilla/js/src/jsnum.c, line 938]
js_ValueToNumber  [mozilla/js/src/jsnum.c, line 757]
num_isNaN  [mozilla/js/src/jsnum.c, line 73]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1386]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3957]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1405]
nsXPCWrappedJSClass::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
SharedStub  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsMsgStatusFeedback::OnStateChange  [mozilla/mailnews/base/src/nsMsgStatusFeedback.cpp, line 176]
nsDocLoader::FireOnStateChange  [mozilla/uriloader/base/nsDocLoader.cpp, line 1210]
nsDocLoader::doStopDocumentLoad  [mozilla/uriloader/base/nsDocLoader.cpp, line 844]
nsDocLoader::OnStopRequest  [mozilla/uriloader/base/nsDocLoader.cpp, line 665]
nsLoadGroup::RemoveRequest  [mozilla/netwerk/base/src/nsLoadGroup.cpp, line 732]
PresShell::RemoveDummyLayoutRequest  [mozilla/layout/base/nsPresShell.cpp, line 7342]
DummyLayoutRequestEvent::HandleEvent  [mozilla/layout/base/nsPresShell.cpp, line 7242]
0x778b0c24
nsRuleNode::ComputeTextResetData  [mozilla/layout/style/nsRuleNode.cpp, line 2321]
0x0674f685

Comment 7

[Patrick]

(In reply to comment #6)
> don't have any specific advice about diagnosis. perhaps this is CAPS related,
> but I'm not finding any open CAPS crashers or related bugs.
> 
> stack indicates possible dupe of bug 431250, which is still a thunderbird
> topcrash (but its frequency is really quite low - 6 in 10 days)

Thanks for this additional bit of information.

Could you tell me what you mean by "CAPS"? I only find information about spare parts for a certain Ford car model when I search for "Thunderbird CAPS".

I can of course increase this frequency (of reports), by switching on the auto-report feature on our user's Thunderbirds - you'll get a couple of reports per day then. Would that be helpful?

Comment 8

[Wayne Mery (:wsmwk)]

you mention CAPS in comment 0 :) 
http://www.mozilla.org/projects/security/components/ConfigPolicy.html
http://kb.mozillazine.org/Security_Policies

just a possibility though - I don't have any strong reason to believe it's related.

Comment 9

[timeless]

there are some third party apps which cause us to crash in JS_strtod (search bugzilla for them). could you try running windows in safe mode and not running *anything* other than thunderbird? (you can use process explorer from sysinternals.com [microsoft] to verify that all running apps come from microsoft/mozilla)

Comment 10

[Patrick]

Attachment: Before the crash (Windows Safe Mode)

Comment 11

[Patrick]

Attachment: After the crash (Windows Safe Mode)

Comment 12

[Patrick]

(In reply to comment #9)
> there are some third party apps which cause us to crash in JS_strtod (search
> bugzilla for them). could you try running windows in safe mode and not running
> *anything* other than thunderbird? (you can use process explorer from
> sysinternals.com [microsoft] to verify that all running apps come from
> microsoft/mozilla)

I attached two screenshots, one before and one after the crash under Windows Safe Mode. I think we can rule out other applications.

Comment 13

[Patrick]

(In reply to comment #6)
> don't have any specific advice about diagnosis. perhaps this is CAPS related,
> but I'm not finding any open CAPS crashers or related bugs.

(In reply to comment #8)
> you mention CAPS in comment 0 :) 
> http://www.mozilla.org/projects/security/components/ConfigPolicy.html
> http://kb.mozillazine.org/Security_Policies
> 
> just a possibility though - I don't have any strong reason to believe it's
> related.

Ok, thanks for clarification. If it was a general (and pure) CAPS issue, it would happen on the other test machine, too - but it doesn't.

Comment 14

[timeless]

i checked the line, it's the right problem for my memory, so we just need to find a reasonable explanation.

http://www-archive.mozilla.org/quality/help/dependency-walker.html

has steps for getting a dwi file (you'll need to zip it and host it somewhere). from there i can see your cpu details (which for some flash bugs is actually relevant [mmx]) and your loaded libraries (which is the other likely way this could go bad).

if that fails, the next step is using windbg
http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg
except we'd need to do something more interesting, like setting a hardware breakpoint on a register or something. i have no idea how to do it, it'll require a lot of reading.

if thunderbird has a safe mode, you should use it, and if it's possible to disable all plugins, you should do that too. - the fewer variables the better.

Comment 15

[Patrick]

(In reply to comment #14)
> i checked the line, it's the right problem for my memory, so we just need to
> find a reasonable explanation.
> 
> http://www-archive.mozilla.org/quality/help/dependency-walker.html
> 
> has steps for getting a dwi file (you'll need to zip it and host it somewhere).
> from there i can see your cpu details (which for some flash bugs is actually
> relevant [mmx]) and your loaded libraries (which is the other likely way this
> could go bad).

I'm not 100% sure what you're talking about here, I'll read the article later. Hosting a big file is no problem.

The CPU is a Intel(R) Core(TM)2 CPU 6320 @ 1.86GHz here. I'm running Windows in a VM (Sun VirtualBox) though. The other machines have similar CPUs (all Core 2 Duo, varying speeds). We don't use 64 bit software anywhere (yet).
 
> if that fails, the next step is using windbg
> http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg
> except we'd need to do something more interesting, like setting a hardware
> breakpoint on a register or something. i have no idea how to do it, it'll
> require a lot of reading.
> 
> if thunderbird has a safe mode, you should use it, and if it's possible to
> disable all plugins, you should do that too. - the fewer variables the better.

I just tried running Thunderbird in Safe Mode - still crashes. No Extensions (except Talkback) are installed.

Comment 16

[Wayne Mery (:wsmwk)]

(In reply to comment #9)
> there are some third party apps which cause us to crash in JS_strtod (search
> bugzilla for them).

Patrick - http://tinyurl.com/5cu67l

Comment 17

[Patrick]

(In reply to comment #16)
> > there are some third party apps which cause us to crash in JS_strtod (search
> > bugzilla for them).
> 
> Patrick - http://tinyurl.com/5cu67l

Thanks. I read through bugs 431250, 358569, 328624, 395659, 334263 and 356985 without having any more clue than before :( As you can see on <https://bugzilla.mozilla.org/attachment.cgi?id=338832>, I didn't have any third party apps running and still could reproduce the crash.

(In reply to comment #14)
> http://www-archive.mozilla.org/quality/help/dependency-walker.html
> 
> has steps for getting a dwi file (you'll need to zip it and host it somewhere).

This will be my next step today.

I'm not an experienced debugger (and especially not on Windows, as I rarely use it myself), so please tell me what to do. I certainly would like to get this bug fixed, and I'm willing to put time into gathering more information.

Comment 18

[Patrick]

This is the DWI file:
http://temp.patrick-nagel.net/thunderbird.dwi.gz (gzipped, 874 kiB)

And here is a small screen video of how I made the DWI file:
http://temp.patrick-nagel.net/screenvideo.ogv.gz (OGG Theora, gzipped, 5.6 MiB)

Comment 19

[Patrick]

It's been a while now...
@timeless (or other experts): Did you have a look at the DWI file?

This bug causes a few users here a great headache, because they encounter the crash multiple times per day. If there is anything I can do to help resolve this, please tell me.

Comment 20

[timeless]

well, there are a couple of things that i'm not used to seeing and it might be nice to know if disabling them changes things.

gpgee\GPGEE.DLL

something in your registry seems to have registered c:\w\comm\eudora\EUSHLEXT.DLL which i assume you've uninstalled (or perhaps simply deleted) - you should look into a registry cleaner (microsoft released the source code to a basic one, although you should be careful about using any of them).

you have avg7 which i believe is no longer supported (but which was too commonly used to be the culprit)

offhand, i'd prefer to blame gpg as it's the only really available culprit and seems to have been one of the last actors in the log.

sorry about the delay.

Comment 21

[Patrick]

(In reply to comment #20)

That was it! GPGee was present on all computers that had these crashes, uninstalling it made them crash-free.

Now I guess the problem is actually in GPGee - but isn't it also a bug in Thunderbird? Couldn't it be made more robust, so it doesn't choke on a problem like that? We don't see any other file handling programs crashing because of GPGee.
I'll get in contact with the GPGee developer as soon as possible (once the website is up again, currently I get a connection refused error from the server).

Thanks a lot for helping solving this mystery! You're the man! :)

Comment 22

[timeless]

GPGee: GNU Privacy Guard Explorer Extension
GPGee is a shell extension for Windows explorer that acts as an assistant for using GNU Privacy Guard (GnuPG/GPG). It integrates itself into the context ...
gpgee.excelcia.org/ 

As far as we are concerned, this is their bug. they're making a shell extension and it's breaking system state, a shell extension shouldn't significantly change system state.

_control87 is the name of the general method. Having to call it each time we get an event in the event loop and each time we return from a plugin or other system like cool would be prohibitively invasive and expensive.

Comment 23

[Kurt Fitzner]

I'm the developer of GPGee.  Indeed this is a problem on GPGee's end.  GPGee doesn't touch floating point at all itself - at least none of my code does.  I'm fairly certain this is an issue with the compiler I'm using.  Borland's stuff was notorious for this sort of thing.

I'll do what I can to clean this up.  Thanks for the work you folks did tracking this down.

Comment 24

[Patrick]

Great, thanks Kurt!

Comment 25

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #23)
> I'm the developer of GPGee.  Indeed this is a problem on GPGee's end.  GPGee
> doesn't touch floating point at all itself - at least none of my code does. 
> I'm fairly certain this is an issue with the compiler I'm using.  Borland's
> stuff was notorious for this sort of thing.
> 
> I'll do what I can to clean this up.  Thanks for the work you folks did
> tracking this down.

Not a mail bug then - resolving Invalid.