552909 - 3 % of Thunderbird crashes contains [@ (null signature)]

Status: RESOLVED WORKSFORME

(Thunderbird :: General, defect)

Description

[Ludovic Hirlimann [:Usul]]

I believe that 3% is a lot of crashes that can't be investigated. I'm raising this bug to figure out where I should raise other bugs in order to have this number go down from reading one report it seems that /home/processor/stackwalk/bin/stackwalk.sh failed with return code 1. Ain't sure if the bug is the stackwalk, or in breakpad itself. Ted whats the best approcah we could have to have this % go lower (besides crashing elswhere ) ?

Comment 1

[(not currently active) Ted Mielczarek]

I've looked into this previously (Firefox has a lot of these crashes as well), and I didn't get anywhere. Generally this just means "the minidump was malformed". If you can find a reproducible testcase that gives you a crash of this type, I'd be very interested to see it, and we might have a chance of fixing some of them. Otherwise, the dumps alone don't tell us enough to get anywhere.

Comment 2

[Wayne Mery (:wsmwk)]

bug 552088 will help us be able to reach more of the reporters. (only 4 email addresses listed in v3.0.3 crashes [1], i.e. crashes that have comments - which isn't statistically enough people to count on getting responses.) 

from 2 weeks of 3.1b1, these 4 crashes are the same reporter:
bp-5360febc-b648-42a0-9aa5-0bc782100311
bp-011da5c0-99a2-4900-9eb0-d0a8b2100311
bp-b03dc1ae-927d-46a4-967d-149cd2100311
bp-0f7c0877-6682-4684-8afd-663722100311
sent private email to him at <user>@mozilla-russia.org. hopefully he speaks English :)

[1] https://crash-stats.mozilla.com/report/list?version=Thunderbird%3A3.0.3&build_id=&query_search=signature&query_type=exact&query=&date=&range_value=4&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=&signature=&missing_sig=NULL&page=1

Comment 3

[Wayne Mery (:wsmwk)]

from v3.0.3 I have emailed
bp-aa960ca5-5f03-413b-a55e-a12ed2100306
bp-da393052-c986-4bcc-9408-6a13f2100317
bp-902c88bb-048d-4930-acff-0bbf62100310
bp-87dc6e59-7bd6-4eba-a611-0ee1d2100312

the first two say in the comments that they are ubuntu. hmm...

Comment 4

[Umang]

I reported bp-aa960ca5-5f03-413b-a55e-a12ed2100306.

I like I said, I have not done much experimenting with this. I may not be able to experiment with this for a while now, but if tell me what I can do to provide more information, I'll certainly try (although I cannot say for sure when I'll be able to do it).

Three hasty attempts to reproduce the crash today have been unsuccessful (i.e Thunderbird didn't crash).

Comment 5

[(not currently active) Ted Mielczarek]

See also bug 493108.

Comment 6

[(not currently active) Ted Mielczarek]

(In reply to comment #4)
> I reported bp-aa960ca5-5f03-413b-a55e-a12ed2100306.

Your comment notes that this is from Linux. I don't think it's worth exploring the Linux scenario much, as the Linux client code was completely rewritten in Breakpad (bug 514188), but we've only landed that on trunk currently (1.9.3 branch). That code might make it to the 1.9.2 branch as part of the "Lorentz" backport. It's likely to fix a large number of issues with the Linux client code.

Comment 7

[Wayne Mery (:wsmwk)]

Thanks Ted. So, we want to pursue only both Mac and windows in this bug? (unless a linux user on newest trunk)

Our difficulty is OS isn't reported in these null sig crashes. Thus it's hard to target which crashes to look at unless reporter's crash comment mentions the OS ... until and if bug 514188 appears in 1.9.2 with thunderbird v3.1 - what's the likelihood of that?

FWIW, based on ratio in comments perhaps roughly 1/2 of these crashes are linux.

Comment 8

[(not currently active) Ted Mielczarek]

Generally it depends on just how malformed the minidump is. In bug 493108, the minidump contains some information, including the system info, but not enough to produce a stack trace or even a module list. The Linux dumps reported here are probably even more malformed, which means we can't even get system info out of them. If these are mostly Linux crashes, then I have high hopes that the client rewrite there will fix them.

I don't know what the timeframe for that making it to the 1.9.2 branch is, it'd likely go to the Lorentz branch first.

Comment 9

[Wayne Mery (:wsmwk)]

Umang, do you still crash?

Comment 10

[Wayne Mery (:wsmwk)]

(In reply to comment #3)
> from v3.0.3 I have emailed
> bp-aa960ca5-5f03-413b-a55e-a12ed2100306
> bp-da393052-c986-4bcc-9408-6a13f2100317
> bp-902c88bb-048d-4930-acff-0bbf62100310
> bp-87dc6e59-7bd6-4eba-a611-0ee1d2100312

of the 4, Umang is the only respondent. And the only one of 30 people I emailed in the wider 3 month period of 2/21 thru 5/21

In the last few days I messaged 2 people and got 2 responses.

** (mdetiege) win7, firewall Comodo 4.1.150349.920, antivirus avast 5.0.54 
bp-9a1f5aa8-dab5-4c34-aa43-8a1272100708 socorro returns "report could not be located"
crash comment="Anytime you try to open an attachment it crashes, and this for several monthes." 
* 8 of his 10 other crashes are UserCallWinProcCheckWow and are not startup crashes, eg. bp-ced3b585-c9ca-4c26-8eee-9a9d92100721. except:
* bp-69e48940-d177-4e24-89f1-75d8a2100322 arena_dalloc_small | arena_dalloc | free | PL_DHashFreeTable
* bp-66fd49f8-d8cf-445b-9fd7-97f372100226 which stalls on "Please Wait..."


** (shuko)  win-xp
bp-732f0d9c-a91c-48d2-9b98-aaa772100716 
gave me 4 other crashids, all of which were nsHtml5NamedCharacters::initializeStatics(), 3 with zero uptime like  bp-6c6a07ba-9369-435c-8d17-92b5a2100709, 28sec uptime bp-3af4b5e2-b632-43f3-9c11-0c1532100719


Data point - after bug 493108, not crashes to expose null crashes on linux

Comment 11

[Wayne Mery (:wsmwk)]

Attachment: tiege crash stacks

tiege got us windbg stacks. one crash involves foxitreader. ludo writes ...

"one of them is a crash in FoxitReader_Lib_Public.exe so thats why we get
a null signature. so we would need symbols from adobe to get a proper
stack (if FoxitReader_Lib_Public.exe is an adobe thing, which I'm not
entirely sure I can figure out).

For the second one :
ChildEBP RetAddr00ead9d4 770f5e6c ntdll!KiFastSystemCallRet00ead9d8
753d6872 ntdll!NtWaitForMultipleObjects+0xc
00eada74 7666f14a KERNELBASE!WaitForMultipleObjectsEx+0x10000eadabc
763e90be kernel32!WaitForMultipleObjectsExImplementation+0xe000eadb10
763e59fe USER32!RealMsgWaitForMultipleObjectsEx+0x13c00eadb2c 756f71c6
USER32!MsgWaitForMultipleObjects+0x1f
00eadb7c 756e1e57 SHELL32!SHProcessMessagesUntilEventsEx+0x4a00eadbb0
756e1bb7 SHELL32!CShellExecute::_RunThread+0x7700eadbc4 756e1c7e
SHELL32!CShellExecute::ExecuteNormal+0x9200eadbd8 756e1c0e
SHELL32!ShellExecuteNormal+0x33
00eadbf0 62f3a48f SHELL32!ShellExecuteExW+0x6200eadcf8 005e2560
xpcom_core!nsLocalFile::Launch(void)+0x5b
[e:\buildbot\win32_build\build\mozilla\xpcom\io\nslocalfilewin.cpp @ 2806]

I'd say something like nsLocalFile::Launch(void)


and ted might be interested with IP_ON_HEAP:  026b4d30The fault address
in not in any loaded module, please check your build's rebase
log at <releasedir>\bin\build_logs\timebuild\ntrebase.log for module
which may contain the address if it were loaded."

and I wrote
"foxitreader is an alternative not from adobe. I've seen in other bug reports that it often works better than adobe so the reporter offered his results as an alternative [to crash results with adobe reader]. and as expected, he does get different results."

bp-26d0d812-3d6c-4939-9b88-62e032100519 v3.0.4 Open Suse 11.2 32bit Hartmut wrote me he thinks Pulse Audio was related to his issue.


( pretty amazing that (null signature) is also ~3% of crashes for Firefox. )

Comment 12

[timeless]

http://www.foxitsoftware.com/pdf/reader/ is a competitor to adobe reader....

it has its own component in Plugins....

Comment 13

[Wayne Mery (:wsmwk)]

null signature is no longer appearing in topcrash reports.

However, Bug 610551 - 1% of Thunderbird crashes contains [@ (empty signature) - has increased to 4%. #1 crash in v6.