Bug 570655
| Summary: | [abrt] crash in thunderbird-3.0.3-1.fc12: Process /usr/lib64/thunderbird-3.0/thunderbird-bin was killed by signal 11 (SIGSEGV) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dave Allan <dallan> | ||||
| Component: | thunderbird | Assignee: | Jan Horak <jhorak> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 12 | CC: | campbecg, gecko-bugs-nobody, mcepl, stransky, vseerror | ||||
| Target Milestone: | --- | Keywords: | Reopened, Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | abrt_hash:25eaf0bbbccc45b476f9aa494c931ffdc4c5d8ca | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-03-26 15:19:49 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Dave Allan
2010-03-04 22:47:50 UTC
Well, without a back-trace there is simply no way for us to determine the actual cause of the crash. You can actually open the back-trace and read through it. They usually don't show anything which might be considered private, but it should be easy enough to read it. Closing this report as is. If you decide to attach the back-trace, you can reopen it at that time. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers As I said before, I cannot validate that the backtrace does not contain confidential information. Let me restate the problem: This crash occurred while using my corporate email account. I work for a corporation that has a strict policy about revealing confidential information. The backtrace is 1444 lines long, and it is filled with all kinds of values, some human readable strings, some not. Suggesting that it's feasible to review it is unrealistic. I'm a C programmer; I read backtraces all day long; there's no way that such a data set can be vetted in a reasonable amount of time, even by someone familiar with the code. As I said in the original BZ, Thunderbird segfaulted twice in one day without any unusual input. That's fairly concerning to me at least. I offered to provide the backtrace privately, but you ignored that offer and closed the bug. Typically, that's what the NEEDINFO flag is used for. Since Thunderbird just crashed again, I'm reopening and taking the bug. I will find someone to whom I can provide the backtrace. Please do not close it again. I will update it as I have further information. (In reply to comment #2) > This crash occurred while using my corporate email account. I work for a > corporation that has a strict policy about revealing confidential information. ??? Aren't we working for the same corporation? If you mark the attachment as private, no-one outside of private_comment group (and volunteer bugzappers are not included) can see it. > As I said in the original BZ, Thunderbird segfaulted twice in one day without > any unusual input. That's fairly concerning to me at least. I offered to > provide the backtrace privately, but you ignored that offer and closed the bug. > Typically, that's what the NEEDINFO flag is used for. That must be some kind of misunderstanding. Sorry for that. > Since Thunderbird just crashed again, I'm reopening and taking the bug. I will > find someone to whom I can provide the backtrace. Please do not close it > again. I will update it as I have further information. As I said, mark it as private and I will take a look. (In reply to comment #3) Hi Matej, thanks for the info. We do indeed work for the same company--I just wasn't aware that everybody who could see private attachments on Fedora bugs was at RH. I have two separate backtraces; I'll attach both. I thought this segfault might be related to a folder I had with >27k messages in it, so I deleted all the messages in that folder. The most recent segfault happened after deleting those messages. Created attachment 398617 [details]
log of updates and crashes
Statistically speaking, it looks like this crash is new with 3.0.3-1
Matej or Jan, do any of those traces shed any light on what's going on? This must be some corner case that my particular setup is triggering, or the world would be screaming as it's fairly painful--I'm seeing several crashes a day. I found this on the upstream bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=411147 but it is marked as "Windows only". All backtraces are identical in ending in nsQueryInterface::operator() (with slightly different paths leading to the same point), except for the attachment 398605 [details], which is in nsSSLThread::requestRecvMsgPeek *** This bug has been marked as a duplicate of bug 570391 *** (In reply to comment #13) > I found this on the upstream bugzilla > https://bugzilla.mozilla.org/show_bug.cgi?id=411147 but it is marked as > "Windows only". > > All backtraces are identical in ending in nsQueryInterface::operator() (with > slightly different paths leading to the same point), except for the attachment > 398605, which is in nsSSLThread::requestRecvMsgPeek Note: bug 411147 might not be "windows-only" - my comment "windows only per crash-stats" only means I didn't see any linux crashes, which isn't unusual because we tend to not get many linux crashes feeding to crash-stats |