Thunderbird crashes due to use-after-free or pointer corruption (Linux,Mac)

RESOLVED FIXED in Thunderbird 46.0

Status

defect
--
critical
RESOLVED FIXED
4 years ago
Last year

People

(Reporter: olaf, Unassigned)

Tracking

({crash})

Thunderbird 46.0
x86_64
Linux

Thunderbird Tracking Flags

(thunderbird43 affected, thunderbird44 fixed, thunderbird45 fixed, thunderbird46 affected, thunderbird_esr38 wontfix)

Details

(Whiteboard: [revisit 2018-04-01], crash signature)

Attachments

(29 attachments, 1 obsolete attachment)

115.06 KB, text/plain
Details
122.53 KB, text/plain
Details
7.13 KB, text/plain
Details
29.91 KB, text/plain
Details
8.67 KB, text/plain
Details
14.74 KB, text/plain
Details
117.06 KB, text/plain
Details
132.08 KB, text/plain
Details
142.15 KB, text/plain
Details
173.18 KB, text/plain
Details
165.81 KB, text/plain
Details
132.25 KB, text/plain
Details
132.83 KB, text/plain
Details
141.44 KB, text/plain
Details
1.02 KB, patch
rkent
: review+
Details | Diff | Splinter Review
137.22 KB, text/plain
Details
160.90 KB, text/plain
Details
147.40 KB, text/plain
Details
85.69 KB, application/x-gzip
Details
169.40 KB, text/plain
Details
80.41 KB, application/x-gzip
Details
681.14 KB, text/plain
Details
293.07 KB, text/plain
Details
1.10 MB, text/plain
Details
212.37 KB, text/plain
Details
180.13 KB, text/plain
Details
193.35 KB, text/plain
Details
141.13 KB, text/plain
Details
194.94 KB, text/plain
Details
Posted file tb-201509111515.txt
openSUSE Tumbleweed 38.2.0, happend also with 38.1.0.

report:
bp-1f676712-8f36-4bfd-8be2-b18be2150911

Four IMAP accounts.

TB crashes often at different places in the code. Often I do not interact with TB at the time it crashes.

The used pointers or ints are often the remainders of a string of one of the IMAP servers.

I forced a different DNS name for the SMTP server via /etc/hosts of the affected IMAP account to see if the used string refers to either the IMAP or SMTP service on that host. The attached crash indicates it refers to the IMAP server name.

I think it starts to happen when I reply to emails in that account. To prove that I will now stop using TB to reply and use mutt instead to see if it makes any difference.
This time a stack corruption with 38.2.

bp-67f699ab-ee3a-4fd8-a945-4fb042150915
Posted file tb-38.1-crash1.txt
First captured crash. no crash id.
Posted file tb-38.1-crash2.txt
second captured crash. no crash id.
Posted file tb-38.1-crash3.txt
third captured crash. no crash id.
Posted file tb-38.1-crash4.txt
fourth crash. no crash id.
(In reply to olaf from comment #2)
> Created attachment 8661090 [details]
> tb-38.1-crash1.txt
> 
> First captured crash. no crash id.

(gdb) p/x *mHdr
$6 = {static sEmptyHdr = {static sEmptyHdr = <same as static member of an already seen type>, mLength = 0x0, mCapacity = 0x0, mIsAutoArray = 0x0}, mLength = 0x6c69616d, mCapacity = 0x656d652e, mIsAutoArray = 0x0}
(gdb) x/s &mHdr->mLength
0x7f9d0eeff100: "mail.emea.novell.com\235\177"
bp-01bea7ee-ca85-4a2f-9519-435752150915

Program received signal SIGSEGV, Segmentation fault.
0x00007fb8a91b462d in CallQueryInterface<nsISupports, nsWrapperCache> (aSource=0x7fb874588ce0, aDestination=0x7ffdff887338) at ../../../dist/include/nsISupportsUtils.h:141
141                                      reinterpret_cast<void**>(aDestination));

this time the real DNS name is still referenced, even though variants of it are configured and resolved via /etc/hosts:

(gdb) x/s $rdi
0x7fb874588ce0: "mail.emea.novell.com\270\177"
While poking around in ~/.thunderbird I found many places where "gwmail.emea.novell.com" is used. Will try to adjust them all to see which one is referenced.
bp-ac95034d-1db6-4db0-8763-ff2ec2150916

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f28563e1700 (LWP 14519)]
arena_dalloc (ptr=0x7f286d6f632e, offset=<optimized out>) at /usr/src/debug/thunderbird/mozilla/memory/mozjemalloc/jemalloc.c:4709
4709            arena = chunk->arena;
bp-27e97064-7682-498b-8213-5408e2150917

Program received signal SIGSEGV, Segmentation fault.
nsTreeRange::Contains (this=<optimized out>, aIndex=33) at /usr/src/debug/thunderbird/mozilla/layout/xul/tree/nsTreeSelection.cpp:164
164         if (aIndex >= mMin && aIndex <= mMax)

The string from "mail.server.server3.hostname" was written into this object, or this object uses stale memory?
Unfortunately the crash reports do not seem to contain symbols/pointers to TB source.

Is Tumbleweed a SUSE branded/modified Thundebird? Do you know if they change any code, or just branding?
Would you be able to try an official TB from mozilla.org and produce a crash report from that?
(In reply to :aceman from comment #11)
> Unfortunately the crash reports do not seem to contain symbols/pointers to
> TB source.

Thats why I post the gdb info here.

> Is Tumbleweed a SUSE branded/modified Thundebird? Do you know if they change
> any code, or just branding?

Its a code name. Looks like its only branding with no relevant patches.

https://en.opensuse.org/Portal:Tumbleweed
https://build.opensuse.org/package/show/home:olh/MozillaThunderbird

> Would you be able to try an official TB from mozilla.org and produce a crash
> report from that?

Unlikely, but perhaps next week.
Yes, unfortunately the gdb info shows too generic code places. nsTreeRange::Contains(), arena_dalloc(), CallQueryInterface<nsISupports, nsWrapperCache> are low level functions deep in the rendering/support code. We need to see some of the higher levels in the stack, which TB function invoked these generics in the end.

So tumbleweed seems to be a codename for a Suse release. At the second link they seem to list some patches. Even if those do not modify Tb source directly, it probably implies they build TB themselves and that is why the crash log shows no symbols.
(In reply to :aceman from comment #13)
> Yes, unfortunately the gdb info shows too generic code places.
> nsTreeRange::Contains(), arena_dalloc(), CallQueryInterface<nsISupports,
> nsWrapperCache> are low level functions deep in the rendering/support code.
> We need to see some of the higher levels in the stack, which TB function
> invoked these generics in the end.

Is the attachment in comment #9 (for example) not detailed enough?

> So tumbleweed seems to be a codename for a Suse release. At the second link
> they seem to list some patches. Even if those do not modify Tb source
> directly, it probably implies they build TB themselves and that is why the
> crash log shows no symbols.

Of course we do not ship binaries, but rebuild from source. Do the binaries provided by mozilla.org include symbols in the crash report? If so, we have to hurry and adjust the way we build our own packages.
Sorry, I overlooked the attachments. Those look better.
The official builds do have proper symbols then the crash report looks like this on the crash server: https://crash-stats.mozilla.com/report/index/e1f092a3-9f8e-4808-89f3-067302150914. Maybe it is that the server has the list of addresses and symbols uploaded so it knows how to decode the addresses in the crash stack).

I remember we had a similar problem with Ubuntu whose crash reports were unusable.

Of course you can build TB in any way you need. Just maybe disable the crash reporter so that the builds do not upload unusable reports. But I'll ask our QA expert Wayne for the advice here.
Flags: needinfo?(vseerror)
But if you have crashes all over the place (the crash stacks are very different), there must be something bad with your TB installation. Have you tried creating a new profile in Thunderbird? Or your HW is unstable?

We prefer to open a new bug for each single problem/crash report (but it should be reproducible).
(In reply to :aceman from comment #16)
> But if you have crashes all over the place (the crash stacks are very
> different), there must be something bad with your TB installation. Have you
> tried creating a new profile in Thunderbird? Or your HW is unstable?
> 
> We prefer to open a new bug for each single problem/crash report (but it
> should be reproducible).

What I see is the the remainder of user_pref("mail.server.server3.hostname", "STRING") in the referenced memory, as it just happend again in the last attachment. STRING above is supposed to be gwmail.emea.novell.com, in memory I see the first two bytes already overwritten. This is the overall pattern of now more than 5 crashes.

To debug it further I adjusted prefs.js and /etc/hosts to make it easy to identify strings. Now I know its the .hostname setting. I'm sure its used all over the place to construct URLs and whatnot.

Not sure how to go from here. I will continue with gdb attached. Not sure if there is a way to use plain glibc malloc instead of the built-in allocator, perhaps valgrind might help in such setup.
One thing which may matter is that this IMAP server is incredible slow to respond. Are there debug knobs to log access to a certain server? Perhaps this server triggers rarely used error paths.
Yes, see https://wiki.mozilla.org/MailNews:Logging . Set the logging module to imap:5 .
I have added this to the startup script:
env \
NSPR_LOG_MODULES="imap:5,smtp:5,msgdb:5,gssapi:5,negotiateauth:5,msgpurge:5,,timestamp,sync" \
NSPR_LOG_FILE="${tb_log}" \

Seems to hide the bug, no crashes since then....
bp-c050093f-622b-472a-9c22-2c50d2151007

Program received signal SIGSEGV, Segmentation fault.
0x00007f6f512dd58a in nsINode::GetParent (this=0x656d652e6c69616d) at /usr/src/debug/thunderbird/mozilla/dom/base/nsINode.h:805
805           reinterpret_cast<nsIContent*>(mParent) : nullptr;
#1  0x00007f6f51d06447 in mozilla::ElementRestyler::RestyleUndisplayedNodes(nsRestyleHint, mozilla::UndisplayedNode*, nsIContent*, nsStyleContext*, unsigned char) (this=this@entry=0x7ffecc3dc160, aChildRestyleHint=aChildRestyleHint@entry=0, aUndisplayed=<optimized out>, aUndisplayedParent=aUndisplayedParent@entry=0x7f6f29005820, aParentContext=aParentContext@entry=0x7f6f294a1530, aDisplay=aDisplay@entry=0 '\000') at /usr/src/debug/thunderbird/mozilla/layout/base/RestyleManager.cpp:3728


I removed the debug variables, and now I got my crash again.
another one, without debug env:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f59020fd700 (LWP 17525)]
arena_dalloc (ptr=0x656d652e6c69616d, offset=<optimized out>) at /usr/src/debug/thunderbird/mozilla/memory/mozjemalloc/jemalloc.c:4709
4709            arena = chunk->arena;

Thread 14 (Thread 0x7f59020fd700 (LWP 17525)):
#0  0x0000000000411051 in arena_dalloc (ptr=0x656d652e6c69616d, offset=<optimized out>) at /usr/src/debug/thunderbird/mozilla/memory/mozjemalloc/jemalloc.c:4709
#1  0x00000000004112e0 in free (ptr=<optimized out>) at /usr/src/debug/thunderbird/mozilla/memory/mozjemalloc/jemalloc.c:6459
#2  0x00007f5912d659b8 in FinalizeTypedArenas<js::Shape>(js::FreeOp*, js::gc::ArenaHeader**, js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) (p=<optimized out>) at ../../dist/include/js/Utility.h:129


Will see how to enable the debug envs one by one.
Looks like TB 38 runs stable even without debug env variables since mozilla-nss was upgraded from 3.19.2 to 3.20 this Thuesday.
bp-4a6b5b2c-c64a-4525-b09f-ebb8c2151022

Another one, no debug env
Program received signal SIGSEGV, Segmentation fault.
0x00007f8561e7325b in nsThread::ProcessNextEvent (this=0x7f8555d1ae20, aMayWait=<optimized out>, aResult=0x7ffc6597809f) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/nsThread.cpp:855
855           event->Run();

Thread 1 (Thread 0x7f85682ad740 (LWP 3595)):
#0  0x00007f8561e7325b in nsThread::ProcessNextEvent(bool, bool*) (this=0x7f8555d1ae20, aMayWait=<optimized out>, aResult=0x7ffc6597809f) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/nsThread.cpp:855
#1  0x00007f8561e84a36 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aMayWait=aMayWait@entry=true) at /usr/src/debug/thunderbird/mozilla/xpcom/glue/nsThreadUtils.cpp:265
#2  0x00007f8561e7531c in nsThread::Shutdown() (this=0x7f85297f5320) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/nsThread.cpp:662
#3  0x00007f8561d70613 in nsImapThreadShutdownEvent::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mailnews/imap/src/nsImapProtocol.cpp:1041
Another crash without debug env variables. Its stable with just NSPR_LOG_MODULES=",,timestamp", but I will run with just this variable variant for the rest of this year to confirm.

Is anyone familiar with the code to explain why this variable makes a difference?


Program received signal SIGSEGV, Segmentation fault.
js::UncheckedUnwrap (wrapped=<optimized out>, wrapped@entry=0x7f6b11bd01c0, stopAtOuter=stopAtOuter@entry=true, flagsp=flagsp@entry=0x0) at /usr/src/debug/thunderbird/mozilla/js/src/proxy/Wrapper.cpp:91
91                  wrapped = MaybeForwarded(wrapped);

Thread 1 (Thread 0x7f6b3e94f740 (LWP 27441)):
#0  0x00007f6b3a0ead32 in js::UncheckedUnwrap(JSObject*, bool, unsigned int*) (wrapped=<optimized out>, wrapped@entry=0x7f6b11bd01c0, stopAtOuter=stopAtOuter@entry=true, flagsp=flagsp@entry=0x0) at /usr/src/debug/thunderbird/mozilla/js/src/proxy/Wrapper.cpp:91
#1  0x00007f6b3a0f27ba in js::NukeCrossCompartmentWrappers(JSContext*, js::CompartmentFilter const&, js::CompartmentFilter const&, js::NukeReferencesToWindow) (cx=<optimized out>, sourceFilter=..., targetFilter=..., nukeReferencesToWindow=nukeReferencesToWindow@9
#2  0x00007f6b38afaa4a in WindowDestroyedEvent::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/dom/base/nsGlobalWindow.cpp:8914
#3  0x00007f6b3857325e in nsThread::ProcessNextEvent(bool, bool*) (this=0x7f6b2c41ae20, aMayWait=<optimized out>, aResult=0x7fffc1e7e9cf) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/nsThread.cpp:855
#4  0x00007f6b38584a36 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aMayWait=aMayWait@entry=false) at /usr/src/debug/thunderbird/mozilla/xpcom/glue/nsThreadUtils.cpp:265
#5  0x00007f6b3872acd0 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7f6b2c4864c0, aDelegate=0x7f6b3d5e7330) at /usr/src/debug/thunderbird/mozilla/ipc/glue/MessagePump.cpp:99
NSPR_LOG_MODULES=,,timestamp does not help, but imap:N (which I used earlier for many days) does.

Program received signal SIGSEGV, Segmentation fault.
0x00007fcfd0c5e8b0 in nsImapMailFolder::ParseMsgHdrs (this=0x7fcfbcea8c00, aProtocol=0x7fcf81a99800, aHdrXferInfo=0x7fcf818f2740) at /usr/src/debug/thunderbird/mailnews/imap/src/nsImapMailFolder.cpp:2922
2922      nsresult rv = aHdrXferInfo->GetNumHeaders(&numHdrs);

Thread 1 (Thread 0x7fcfd7164740 (LWP 9925)):
#0  0x00007fcfd0c5e8b0 in nsImapMailFolder::ParseMsgHdrs(nsIImapProtocol*, nsIImapHeaderXferInfo*) (this=0x7fcfbcea8c00, aProtocol=0x7fcf81a99800, aHdrXferInfo=0x7fcf818f2740) at /usr/src/debug/thunderbird/mailnews/imap/src/nsImapMailFolder.cpp:2922
#1  0x00007fcfd0c9ec22 in (anonymous namespace)::SyncRunnable2<nsIImapMailFolderSink, nsIImapProtocol*, nsIImapHeaderXferInfo*>::Run() (this=0x7fcf8f8f3b20) at /usr/src/debug/thunderbird/mailnews/imap/src/nsSyncRunnableHelpers.cpp:146
#2  0x00007fcfd0d7325e in nsThread::ProcessNextEvent(bool, bool*) (this=0x7fcfc5a1fe20, aMayWait=<optimized out>, aResult=0x7ffdd9009f5f) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/nsThread.cpp:855
#3  0x00007fcfd0d84a36 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aMayWait=aMayWait@entry=true) at /usr/src/debug/thunderbird/mozilla/xpcom/glue/nsThreadUtils.cpp:265
#4  0x00007fcfd0f2ad1f in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7fcfc5a8a4c0, aDelegate=0x7fcfd5deb330) at /usr/src/debug/thunderbird/mozilla/ipc/glue/MessagePump.cpp:140
#5  0x00007fcfd0f200fa in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:226
#6  0x00007fcfd0f200fa in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:200
#7  0x00007fcfd1bc8ae7 in nsBaseAppShell::Run() (this=0x7fcfbfbaa8d0) at /usr/src/debug/thunderbird/mozilla/widget/nsBaseAppShell.cpp:164
Similar crash stacks are available, such as:

https://crash-stats.mozilla.com/report/index/bdbec2be-4015-46a7-ab1c-9c3062151213

This is a fairly rare crash, but it could possibly be prevented with a simple null check of the value prior to the call:

nsresult rv = aHdrXferInfo->GetNumHeaders(&numHdrs);
Crash Signature: [@ nsImapMailFolder::ParseMsgHdrs ]
Severity: normal → critical
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: IMAP
Ever confirmed: true
Product: Thunderbird → MailNews Core
(In reply to Kent James (:rkent) from comment #28)
> This is a fairly rare crash, but it could possibly be prevented with a
> simple null check of the value prior to the call:

Comment #27 and many other attached crashes here are due to bogus memory, used as a pointer.

It would be nice if TB could use the standard malloc/free functions all over the place to let valgrind do its job...
TB continues to run stable with this cmdline:

+ env NSPR_LOG_MODULES=imap:1,,timestamp NSPR_LOG_FILE=/dev/shm/thunderbird_debug.txt TMPDIR=/dev/shm valgrind -v --malloc-fill=0x42 --free-fill=0x24 thunderbird
Add NS_ENSURE_ARG_POINTER check.
Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED
Attachment #8701589 - Flags: review?(rkent)
Comment on attachment 8701589 [details] [diff] [review]
bug1203977_use_after_free_crash.patch [checked in, comment #33]

Review of attachment 8701589 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM!
Attachment #8701589 - Flags: review?(rkent) → review+
https://hg.mozilla.org/comm-central/rev/7748cfb2e1be -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Summary: Thunderbird crashes due to use-after-free or pointer corruption → Thunderbird crashes in nsImapMailFolder::ParseMsgHdrs
Target Milestone: --- → Thunderbird 46.0
Attachment #8701589 - Flags: approval-comm-beta?
Attachment #8701589 - Flags: approval-comm-aurora?
Kent, can you please set the request flags to "+".
Flags: needinfo?(rkent)
This is not fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to olaf from comment #36)
> This is not fixed.

please cite your crash ID
Flags: needinfo?(vseerror) → needinfo?(olaf)
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #37)
> (In reply to olaf from comment #36)
> > This is not fixed.
> 
> please cite your crash ID

See each comment above. The current crash with the wellknown "mail.emea.povell.com" will be attached tomorrow.
Flags: needinfo?(olaf)
Program received signal SIGSEGV, Segmentation fault.
0x00007f500f4ae8f9 in CallQueryInterface<nsISupports, nsWrapperCache> (aSource=0x7f4fd58b2980, aDestination=0x7ffc5bc1cc08) at ../../../dist/include/nsISupportsUtils.h:141
141                                      reinterpret_cast<void**>(aDestination));

Thread 1 (Thread 0x7f50155e5740 (LWP 4498)):
#0  0x00007f500f4ae8f9 in CallQueryInterface<nsISupports, nsWrapperCache>(nsISupports*, nsWrapperCache**) (aSource=0x7f4fd58b2980, aDestination=0x7ffc5bc1cc08) at ../../../dist/include/nsISupportsUtils.h:141
#1  0x00007f500f4af6c7 in XPCWrappedNative::FlatJSObjectFinalized() (aDestPtr=0x7ffc5bc1cc08, aSourcePtr=...) at ../../../dist/include/nsCOMPtr.h:1369
#2  0x00007f500f4af6c7 in XPCWrappedNative::FlatJSObjectFinalized() (this=0x7f4fc6d5dd60) at /usr/src/debug/thunderbird/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:925
#3  0x00007f5010c7636f in FinalizeTypedArenas<JSObject>(js::FreeOp*, js::gc::ArenaHeader**, js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) (fop=0x7ffc5bc1e000, this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/js/src/jsobjinlines.h:42
#4  0x00007f5010c7636f in FinalizeTypedArenas<JSObject>(js::FreeOp*, js::gc::ArenaHeader**, js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) (thingSize=48, thingKind=js::gc::FINALIZE_OBJECT2, fop=0x7ffc5bc1e000, this=0x7f4fdd7f4000) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:497
#5  0x00007f5010c7636f in FinalizeTypedArenas<JSObject>(js::FreeOp*, js::gc::ArenaHeader**, js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) (fop=0x7ffc5bc1e000, fop@entry=0x7f50024939c8, src=src@entry=0x7ffc5bc1cd28, dest=..., thingKind=thingKind@entry=js::gc::FINALIZE_OBJECT2, budget=..., keepArenas=keepArenas@entry=js::gc::ArenaLists::KEEP_ARENAS) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:557
#6  0x00007f5010c76cab in js::gc::ArenaLists::forceFinalizeNow(js::FreeOp*, js::gc::AllocKind, js::gc::ArenaLists::KeepArenasEnum, js::gc::ArenaHeader**) (thingKind=js::gc::FINALIZE_OBJECT2, keepArenas=js::gc::ArenaLists::KEEP_ARENAS, budget=..., dest=..., src=0x7ffc5bc1cd28, fop=0x7f50024939c8) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:600
#7  0x00007f5010c76cab in js::gc::ArenaLists::forceFinalizeNow(js::FreeOp*, js::gc::AllocKind, js::gc::ArenaLists::KeepArenasEnum, js::gc::ArenaHeader**) (this=this@entry=0x7f5002493830, fop=fop@entry=0x7ffc5bc1e000, empty=empty@entry=0x7f5002493d28, keepArenas=js::gc::ArenaLists::KEEP_ARENAS, thingKind=js::gc::FINALIZE_OBJECT2) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:2758
#8  0x00007f5010c76f80 in js::gc::ArenaLists::queueForegroundObjectsForSweep(js::FreeOp*) (empty=0x7f5002493d28, keepArenas=js::gc::ArenaLists::KEEP_ARENAS, thingKind=js::gc::FINALIZE_OBJECT2, fop=0x7ffc5bc1e000, this=0x7f5002493830) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:2741
Now since my crash was "hijacked" for some nullptr crash in comment #28, how should we proceed?
Flags: needinfo?(rkent)
Attachment #8701589 - Flags: approval-comm-beta?
Attachment #8701589 - Flags: approval-comm-beta+
Attachment #8701589 - Flags: approval-comm-aurora?
Attachment #8701589 - Flags: approval-comm-aurora+
bp-492fb0e2-d7e7-43db-9b7d-7fc662160113

another wild string pointer

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7efce577c700 (LWP 4443)]
arena_dalloc (ptr=0x7efc6d6f632e, offset=<optimized out>) at /usr/src/debug/thunderbird/mozilla/memory/mozjemalloc/jemalloc.c:4709
4709            arena = chunk->arena;
Wed Jan 13 06:01:17 UTC 2016
4704            assert(ptr != NULL);
4705            assert(offset != 0);
4706            assert(CHUNK_ADDR2OFFSET(ptr) == offset);
4707
4708            chunk = (arena_chunk_t *) ((uintptr_t)ptr - offset);
4709            arena = chunk->arena;
4710            assert(arena != NULL);
4711            RELEASE_ASSERT(arena->magic == ARENA_MAGIC);
4712
4713            pageind = offset >> pagesize_2pow;

Thread 18 (Thread 0x7efce577c700 (LWP 4443)):
#0  0x0000000000411051 in arena_dalloc (ptr=0x7efc6d6f632e, offset=<optimized out>) at /usr/src/debug/thunderbird/mozilla/memory/mozjemalloc/jemalloc.c:4709
#1  0x00000000004112e0 in free (ptr=<optimized out>) at /usr/src/debug/thunderbird/mozilla/memory/mozjemalloc/jemalloc.c:6459
#2  0x00007efcf71b266b in js::BaseShape::finalize(js::FreeOp*) (p=<optimized out>) at ../../dist/include/js/Utility.h:129
#3  0x00007efcf71b266b in js::BaseShape::finalize(js::FreeOp*) (this=0x7efcb284e0a0, __in_chrg=<optimized out>) at /usr/src/debug/thunderbird/mozilla/js/src/vm/Shape.h:205
#4  0x00007efcf71b266b in js::BaseShape::finalize(js::FreeOp*) (this=0x7efcfaa000c8, p=0x7efcb284e0a0) at /usr/src/debug/thunderbird/mozilla/js/src/vm/Runtime.h:390
#5  0x00007efcf71b266b in js::BaseShape::finalize(js::FreeOp*) (this=this@entry=0x7efcde4047e8, fop=fop@entry=0x7efce577bd40) at /usr/src/debug/thunderbird/mozilla/js/src/vm/Shape.cpp:1474
#6  0x00007efcf745f315 in FinalizeTypedArenas<js::BaseShape>(js::FreeOp*, js::gc::ArenaHeader**, js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) (thingSize=56, thingKind=js::gc::FINALIZE_BASE_SHAPE, fop=0x7efce577bd40, this=0x7efcde404000) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:497
#7  0x00007efcf745f315 in FinalizeTypedArenas<js::BaseShape>(js::FreeOp*, js::gc::ArenaHeader**, js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) (fop=0x7efce577bd40, src=0x7efce577ac98, dest=..., thingKind=js::gc::FINALIZE_BASE_SHAPE, budget=..., keepArenas=js::gc::ArenaLists::KEEP_ARENAS) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:557
#8  0x00007efcf748e558 in js::gc::ArenaLists::backgroundFinalize(js::FreeOp*, js::gc::ArenaHeader*, js::gc::ArenaHeader**) (keepArenas=js::gc::ArenaLists::KEEP_ARENAS, budget=..., thingKind=js::gc::FINALIZE_BASE_SHAPE, dest=..., src=0x7efce577ac98, fop=0x7efce577bd40) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:610
#9  0x00007efcf748e558 in js::gc::ArenaLists::backgroundFinalize(js::FreeOp*, js::gc::ArenaHeader*, js::gc::ArenaHeader**) (fop=fop@entry=0x7efce577bd40, listHead=0x7efcdd9ba000, empty=empty@entry=0x7efce577bd28) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:2827
#10 0x00007efcf748e664 in js::gc::GCRuntime::sweepBackgroundThings(js::gc::ZoneList&, js::LifoAlloc&, js::ThreadType) (this=this@entry=0x7efce7040318, zones=..., threadType=threadType@entry=js::BackgroundThread, freeBlocks=...) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:3350
#11 0x00007efcf748e914 in js::GCHelperState::doSweep(js::AutoLockGC&) (threadType=js::BackgroundThread, freeBlocks=..., zones=..., this=0x7efce7040318) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:3594
Does anyone happen to know if this applies to Thunderbird as well?

https://developer.mozilla.org/en-US/docs/Mozilla/Testing/Valgrind
Well, I have rebuilt with valgrind and started it like this. Lets see if anything useful happens:

env TMPDIR=/dev/shm G_SLICE=always-malloc valgrind --smc-check=all-non-file --vex-iropt-register-updates=allregs-at-mem-access --show-mismatched-frees=no --read-inline-info=yes -v --malloc-fill=0x42 --free-fill=0x24 thunderbird
This time I ran the valgrind-enabled binary without valgrind and with G_SLICE=always-malloc. free() complained about corruption. See thread 28 in the attachment.

*** Error in `/usr/lib64/thunderbird/thunderbird-bin': free(): invalid next size (fast): 0x0000000003db0f90 ***

Thread 28 (Thread 0x7fd081ff9700 (LWP 27646)):
#0  0x00007fd10ef1fd38 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007fd10ef2118a in __GI_abort () at abort.c:78
#2  0x00007fd10ef5e75a in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7fd10f055c70 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007fd10ef64096 in malloc_printerr (action=3, str=0x7fd10f055d80 "free(): invalid next size (fast)", ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5000
#4  0x00007fd10ef6487e in _int_free (av=0x7fd10f28ab40 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:3861
#5  0x00007fd109e665ae in nsImapProtocol::~nsImapProtocol() (this=0x34e1a00, __in_chrg=<optimized out>) at ../../../dist/include/nsTSubstring.h:95
#6  0x00007fd109e665ae in nsImapProtocol::~nsImapProtocol() (this=0x34e1a00, __in_chrg=<optimized out>) at ../../../dist/include/nsTString.h:20
#7  0x00007fd109e665ae in nsImapProtocol::~nsImapProtocol() (this=0x34e18d0, __in_chrg=<optimized out>) at /usr/src/debug/thunderbird/mailnews/imap/src/nsImapProtocol.cpp:570
#8  0x00007fd109e665eb in nsImapProtocol::~nsImapProtocol() (this=0x34e18d0, __in_chrg=<optimized out>) at /usr/src/debug/thunderbird/mailnews/imap/src/nsImapProtocol.cpp:581
#9  0x00007fd109daf3ad in nsMsgProtocol::Release() (this=<optimized out>) at /usr/src/debug/thunderbird/mailnews/base/util/nsMsgProtocol.cpp:46
#10 0x00007fd109f58158 in nsThread::ProcessNextEvent(bool, bool*) (this=0x7fd081ff8da8, __in_chrg=<optimized out>) at ../../dist/include/nsCOMPtr.h:344
#11 0x00007fd109f58158 in nsThread::ProcessNextEvent(bool, bool*) (this=0x17c98080, aMayWait=<optimized out>, aResult=0x7fd081ff8e0f) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/nsThread.cpp:845
#12 0x00007fd109f69930 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aMayWait=aMayWait@entry=false) at /usr/src/debug/thunderbird/mozilla/xpcom/glue/nsThreadUtils.cpp:265
#13 0x00007fd10a10fc89 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) (this=0x7fd09829a320, aDelegate=0x7fd0985124f0) at /usr/src/debug/thunderbird/mozilla/ipc/glue/MessagePump.cpp:339
#14 0x00007fd10a1052a4 in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:226

Will run again with valgrind to see if it catches anything.
Is there a slim chance that error paths in the IMAP or network code cause this trouble, since the used IMAP server is slow or behaves unexpected?
olaf, the patch hasn't been applied to version 38, but all your crashes since the patch landed in comment 34 are against version 38.*.  You should be testing against a version 44 or newer branch. For example from http://www.mozilla.org/en-US/thunderbird/channel/
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #46)
> olaf, the patch hasn't been applied to version 38, but all your crashes
> since the patch landed in comment 34 are against version 38.*.  You should
> be testing against a version 44 or newer branch. For example from
> http://www.mozilla.org/en-US/thunderbird/channel/

I have applied that patch, and I dont see how it would help with my case. Not sure why we still have 38.5.1, looks like everything else is beta according to wikipedia.

Will check if I can build a newer version.
Posted file thunderbird_valdgrind.txt (obsolete) —
Here is my current stdout/stderr from this cmd.

env TMPDIR=/dev/shm G_SLICE=always-malloc valgrind --smc-check=all-non-file --vex-iropt-register-updates=allregs-at-mem-access --show-mismatched-frees=no --read-inline-info=yes --leak-check=full --show-possibly-lost=no --track-origins=yes --trace-children=yes -v --malloc-fill=0x42 --free-fill=0x24 thunderbird

I would appreciate a review of the warnings of process 21656 because I'm not familiar with valgrind.

Somewhere in the middle I made the mistake to open an url from within TB. This caused valgrind to trace also this FF process (my Qt FF wrapper) until the url was handed to the already running FF. Hopefully this will not cause to much trouble/confusion. I will avoid this in the future.
Forget about wikipedia - your authoritative sources are speaking here in this bug. You want to be testing with the source code of version 44 or newer.

questions regarding valgrind are probably best asked in mozilla.dev.apps.thunderbird newsgroup.
(In reply to olaf from comment #48)
> I would appreciate a review of the warnings of process 21656 because I'm not
> familiar with valgrind.

It was suggested to strdup the setlocale() returned string. I will try that.
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #49)
> questions regarding valgrind are probably best asked in
> mozilla.dev.apps.thunderbird newsgroup.

I tried that earlier already and was redirected to bugzilla. The result is that the traces will never appear in a google search.
The full log, please have a look at the warnings regarding nsTreeBodyFrame.cpp:nsTreeBodyFrame::GetItemWithinCellAt

I will now restart TB with corrected usage of setlocale() and see what shows up after that change.
Attachment #8712707 - Attachment is obsolete: true
Have you applied any of the princples/tools of https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Refcount_tracing_and_balancing ?

(In reply to olaf from comment #51)
> (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment
> #49)
> > questions regarding valgrind are probably best asked in
> > mozilla.dev.apps.thunderbird newsgroup.
> 
> I tried that earlier already and was redirected to bugzilla. The result is
> that the traces will never appear in a google search.

I misunderstood your comment. I thought in comment 34 you were asking a general question about valgrind.  Ishikawa can perhaps offer you advice aboug valgrind.
Flags: needinfo?(ishikawa)
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #53)
> Have you applied any of the princples/tools of
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/
> Refcount_tracing_and_balancing ?
> 
> (In reply to olaf from comment #51)
> > (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment
> > #49)
> > > questions regarding valgrind are probably best asked in
> > > mozilla.dev.apps.thunderbird newsgroup.
> > 
> > I tried that earlier already and was redirected to bugzilla. The result is
> > that the traces will never appear in a google search.
> 
> I misunderstood your comment. I thought in comment 34 you were asking a
> general question about valgrind.  Ishikawa can perhaps offer you advice
> aboug valgrind.

I have been running |make mozmill| test by hacking a binary that invokes thunderbird-bin under valgrind for a few years now. (Not that I found serious memory errors in the last couple of years. Before that, I did!)


(In reply to olaf from comment #48)
> Created attachment 8712707 [details]
> thunderbird_valdgrind.txt
> 
> Here is my current stdout/stderr from this cmd.
> 
> env TMPDIR=/dev/shm G_SLICE=always-malloc valgrind --smc-check=all-non-file
> --vex-iropt-register-updates=allregs-at-mem-access
> --show-mismatched-frees=no --read-inline-info=yes --leak-check=full
> --show-possibly-lost=no --track-origins=yes --trace-children=yes -v
> --malloc-fill=0x42 --free-fill=0x24 thunderbird
> 
> I would appreciate a review of the warnings of process 21656 because I'm not
> familiar with valgrind.
> 
> Somewhere in the middle I made the mistake to open an url from within TB.
> This caused valgrind to trace also this FF process (my Qt FF wrapper) until
> the url was handed to the already running FF. Hopefully this will not cause
> to much trouble/confusion. I will avoid this in the future.

Looks to me that you have a usage after a free issue  near the end.

For example:
the following shows that a strcmp accessed an invalid region of heap (strcmp trying to compare an octet in a free'ed area. The reason I know it is a free'ed area is
the 
>==21656==  Address 0x22115240 is 0 bytes inside a block of size 6 free'd
>==21656==    at 0x4C2A7FB: free (vg_replace_malloc.c:474)

0 bytes inside a bloc of size 6 free'ed means the FIRST byte (0 bytes inside)
of a previously allocated 6 octets area, which was subsequently freed.

I wonder what is the locale you use. This is because I see locale-related functions
near the stack of failed task.
I usually run TB for testing using en_ES.utf8 (or C.UTF8 which is not grokked by TB code right now. TB and FF complains that C is not two octets character path.

If you are lucky, you should be able to let valgrind tell exactly when free is done and then the next access to this free'ed area is attempted.

==21656== Invalid read of size 1
==21656==    at 0x4C2BFC0: strcmp (vg_replace_strmem.c:760)
==21656==    by 0x5B16121: setlocale (setlocale.c:238)
==21656==    by 0x817FC2F: nsDateTimeFormatUnix::FormatTMTime(nsILocale*, int, int, tm const*, nsAString_internal&) (nsDateTimeFormatUnix.cpp:223)
==21656==    by 0x817FD74: nsDateTimeFormatUnix::FormatPRExplodedTime(nsILocale*, int, int, PRExplodedTime const*, nsAString_internal&) (nsDateTimeFormatUnix.cpp:282)
==21656==    by 0x817FCF7: nsDateTimeFormatUnix::FormatPRTime(nsILocale*, int, int, long, nsAString_internal&) (nsDateTimeFormatUnix.cpp:248)
==21656==    by 0x7F5F1BA: nsMsgDBView::FetchDate(nsIMsgDBHdr*, nsAString_internal&, bool) (nsMsgDBView.cpp:624)
==21656==    by 0x7F6AC95: nsMsgDBView::CellTextForColumn(int, char16_t const*, nsAString_internal&) (nsMsgDBView.cpp:1965)
==21656==    by 0x7F7AB6C: nsMsgGroupView::CellTextForColumn(int, char16_t const*, nsAString_internal&) (nsMsgGroupView.cpp:882)
==21656==    by 0x7F606B0: nsMsgDBView::GetCellText(int, nsITreeColumn*, nsAString_internal&) (nsMsgDBView.cpp:1924)
==21656==    by 0x923DC31: nsTreeBodyFrame::PaintText(int, nsTreeColumn*, nsRect const&, nsPresContext*, nsRenderingContext&, nsRect const&, int&) (nsTreeBodyFrame.cpp:3602)
==21656==    by 0x9242A1D: nsTreeBodyFrame::PaintCell(int, nsTreeColumn*, nsRect const&, nsPresContext*, nsRenderingContext&, nsRect const&, int&, nsPoint) (nsTreeBodyFrame.cpp:3333)
==21656==    by 0x924336F: nsTreeBodyFrame::PaintRow(int, nsRect const&, nsPresContext*, nsRenderingContext&, nsRect const&, nsPoint) (nsTreeBodyFrame.cpp:3089)
==21656==  Address 0x22115240 is 0 bytes inside a block of size 6 free'd
==21656==    at 0x4C2A7FB: free (vg_replace_malloc.c:474)
==21656==    by 0x5B16254: setname (setlocale.c:201)
==21656==    by 0x5B16254: setlocale (setlocale.c:455)
==21656==    by 0x817FBAA: nsDateTimeFormatUnix::FormatTMTime(nsILocale*, int, int, tm const*, nsAString_internal&) (nsDateTimeFormatUnix.cpp:208)
==21656==    by 0x817FD74: nsDateTimeFormatUnix::FormatPRExplodedTime(nsILocale*, int, int, PRExplodedTime const*, nsAString_internal&) (nsDateTimeFormatUnix.cpp:282)
==21656==    by 0x817FCF7: nsDateTimeFormatUnix::FormatPRTime(nsILocale*, int, int, long, nsAString_internal&) (nsDateTimeFormatUnix.cpp:248)


I have meaning to test the memory system error of TB when we have multiple accounts.
I read crash bugzilla somewhere else too and that user had several account.
It seems easy to re-create the situation by creating a few accounts.
(I suspect some kind of interlock issues. Exclusion of tasks are not done very well, perhaps?(

TIA
Flags: needinfo?(ishikawa)
Following is how valgrind is invoked during my local testing of
|make mozmill| test suite.

valgrind --trace-children=yes --fair-sched=yes --smc-check=all-non-file --gen-suppressions=all --vex-iropt-register-updates=allregs-at-mem-access --track-origins=yes --child-silent-after-fork=yes --trace-children-skip=/usr/bin/hg,/bin/rm,*/bin/certutil,*/bin/pk12util,*/bin/ssltunnel,*/bin/uname,*/bin/which,*/bin/ps,*/bin/grep,*/bin/java --num-transtab-sectors=24 --tool=memcheck --freelist-vol=500000000 --redzone-size=128 --px-default=allregs-at-mem-access --px-file-backed=unwindregs-at-mem-access --malloc-fill=0xA5 --free-fill=0xC3 --num-callers=50 --suppressions=$HOME/Dropbox/myown.sup --show-possibly-lost=no --read-inline-info=yes --show-mismatched-frees=no --vgdb=yes	/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/thunderbird-bin -jsbridge 24242 -foreground -profile /NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile

I am afraid that I had turned off mismatched-frees somehow :-(

--suppressions=filepath is to tell valgrind that certain memory issues are not reported, i.e. whitelisting some bugs.
  
The memory error noticed in the following short excerpt is
an access of  memory area during compression of data using libzip.
I think what happens here is that zipping routine is very memory-concious and
only touch the absolutely necessary area in the output buffer.

On the other hand, decompression routine tries to access the input buffer by
a long word access to read data into register by the size of natural int or natural long
integer and only tries to extract the valid data area by proper shifting and masking at 8 bit boundary of the said data.

Depending on the number of octets that were compressed and how well the compression was done, there are cases where, say, only 3bytes of 32bit integer data is written by the writer and when the program tries to access this
24bits of 32bits data by reading the whole 32-bit data using a load-an-integer instruction, then valgrind certain understands that
it has accessed an integer data with one octet inside which is not properly initialized at all.
(But valgrind only complains about uninitialized variable when such a value is output or is used if-expression, etc. I.e., leaving a trace as side-effect.)

==10823== Memcheck, a memory error detector
==10823== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==10823== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==10823== Command: /NREF-COMM-CENTRAL/objdir-tb3/dist/bin/thunderbird-bin -jsbridge 24242 -foreground -profile /NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile
==10823==
--10823-- WARNING: unhandled amd64-linux syscall: 317
--10823-- You may be able to write your own handler.
--10823-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--10823-- Nevertheless we consider this a bug.	Please report
--10823-- it at http://valgrind.org/support/bug_reports.html.
[10823] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file /NREF-COMM-CENTRAL/comm-central/mozilla/extensions/cookie/nsPermissionManager.cpp, line 2609
++DOCSHELL 0x2c5a8570 == 1 [pid = 10823] [id = 1]
++DOMWINDOW == 1 (0x2c5cbf00) [pid = 10823] [serial = 1] [outer = (nil)]
[10823] WARNING: Hardware Vsync support not yet implemented. Falling back to software timers: file /NREF-COMM-CENTRAL/comm-central/mozilla/gfx/thebes/gfxPlatform.cpp, line 2106
++DOMWINDOW == 2 (0x2c6c6df0) [pid = 10823] [serial = 2] [outer = 0x2c5cbf00]
[10823] ###!!! ASSERTION: language code too short: '(len == 2) || (len == 3)', file /NREF-COMM-CENTRAL/comm-central/mozilla/intl/locale/unix/nsPosixLocale.cpp, line 130
Warning: unrecognized command line flag -foreground
++DOCSHELL 0x30f2a430 == 2 [pid = 10823] [id = 2]
++DOMWINDOW == 3 (0x30f31140) [pid = 10823] [serial = 3] [outer = (nil)]
++DOMWINDOW == 4 (0x30f37e10) [pid = 10823] [serial = 4] [outer = 0x30f31140]
LoadPlugin() /NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile/plugins/libnptest.so returned 312d75b0
LoadPlugin() /NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile/plugins/libnpswftest.so returned 31342910
LoadPlugin() /NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile/plugins/libnpthirdtest.so returned 3135a390
LoadPlugin() /NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile/plugins/libnpctrltest.so returned 3136c600
LoadPlugin() /NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile/plugins/libnpsecondtest.so returned 31381d50
LoadPlugin() /NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile/plugins/libnptestjava.so returned 31393d00
++DOMWINDOW == 5 (0x31e58420) [pid = 10823] [serial = 5] [outer = 0x2c5cbf00]
TEST-START | /NREF-COMM-CENTRAL/comm-central/mail/test/mozmill/account/test-ab-whitelist.js | setupModule
==10823== Thread 33 StartupCache:
==10823== Conditional jump or move depends on uninitialised value(s)
==10823==    at 0x12E44CD4: fill_window (deflate.c:1444)
==10823==    by 0x12E4567A: deflate_fast (deflate.c:1642)
==10823==    by 0x12E466FC: MOZ_Z_deflate (deflate.c:903)
==10823==    by 0xF977625: nsDeflateConverter::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long, unsigned int) (nsDeflateConverter.cpp:122)
==10823==    by 0xF9779AC: nsZipDataStream::ProcessData(nsIRequest*, nsISupports*, char*, unsigned long, unsigned int) (nsZipDataStream.cpp:143)
==10823==    by 0xF97C83D: nsZipDataStream::ReadStream(nsIInputStream*) (nsZipDataStream.cpp:171)
==10823==    by 0xF97CE5C: nsZipWriter::AddEntryStream(nsACString_internal const&, long, int, nsIInputStream*, bool, unsigned int) (nsZipWriter.cpp:497)
==10823==    by 0xF97E0DD: nsZipWriter::AddEntryStream(nsACString_internal const&, long, int, nsIInputStream*, bool) (nsZipWriter.cpp:444)
==10823==    by 0x12613B59: mozilla::scache::CacheCloseHelper(nsACString_internal const&, mozilla::scache::CacheEntry const*, mozilla::scache::CacheWriteHolder const*) (StartupCache.cpp:422)
==10823==    by 0x1261578B: mozilla::scache::StartupCache::WriteToDisk() (StartupCache.cpp:477)
==10823==    by 0x12615AB5: mozilla::scache::StartupCache::ThreadedWrite(void*) (StartupCache.cpp:550)
==10823==    by 0x40C265C: _pt_root (ptthread.c:212)
==10823==    by 0x4A2B0A3: start_thread (pthread_create.c:309)
==10823==    by 0x574C06C: clone (clone.S:111)
==10823==  Uninitialised value was created by a heap allocation
==10823==    at 0x4028CE5: malloc (vg_replace_malloc.c:299)
==10823==    by 0x12E4F805: MOZ_Z_zcalloc (zutil.c:310)
==10823==    by 0x12E4763C: MOZ_Z_deflateInit2_ (deflate.c:294)
==10823==    by 0xF976097: nsDeflateConverter::Init() (nsDeflateConverter.cpp:52)
==10823==    by 0xF977211: nsDeflateConverter::AsyncConvertData(char const*, char const*, nsIStreamListener*, nsISupports*) (nsDeflateConverter.cpp:92)
==10823==    by 0xF97B8E9: nsZipDataStream::Init(nsZipWriter*, nsIOutputStream*, nsZipHeader*, int) (nsZipDataStream.cpp:51)
==10823==    by 0xF97CE3C: nsZipWriter::AddEntryStream(nsACString_internal const&, long, int, nsIInputStream*, bool, unsigned int) (nsZipWriter.cpp:491)
==10823==    by 0xF97E0DD: nsZipWriter::AddEntryStream(nsACString_internal const&, long, int, nsIInputStream*, bool) (nsZipWriter.cpp:444)
==10823==    by 0x12613B59: mozilla::scache::CacheCloseHelper(nsACString_internal const&, mozilla::scache::CacheEntry const*, mozilla::scache::CacheWriteHolder const*) (StartupCache.cpp:422)
==10823==    by 0x1261578B: mozilla::scache::StartupCache::WriteToDisk() (StartupCache.cpp:477)
==10823==    by 0x12615AB5: mozilla::scache::StartupCache::ThreadedWrite(void*) (StartupCache.cpp:550)
==10823==    by 0x40C265C: _pt_root (ptthread.c:212)
==10823==    by 0x4A2B0A3: start_thread (pthread_create.c:309)
==10823==    by 0x574C06C: clone (clone.S:111)
==10823==
{
   <insert_a_suppression_name_here>
   Memcheck:Cond
   fun:fill_window
   fun:deflate_fast
   fun:MOZ_Z_deflate
   fun:_ZN18nsDeflateConverter15OnDataAvailableEP10nsIRequestP11nsISupportsP14nsIInputStreammj
   fun:_ZN15nsZipDataStream11ProcessDataEP10nsIRequestP11nsISupportsPcmj
   fun:_ZN15nsZipDataStream10ReadStreamEP14nsIInputStream
   fun:_ZN11nsZipWriter14AddEntryStreamERK19nsACString_internalliP14nsIInputStreambj
   fun:_ZN11nsZipWriter14AddEntryStreamERK19nsACString_internalliP14nsIInputStreamb
   fun:_ZN7mozilla6scacheL16CacheCloseHelperERK19nsACString_internalPKNS0_10CacheEntryEPKNS0_16CacheWriteHolderE
   fun:_ZN7mozilla6scache12StartupCache11WriteToDiskEv
   fun:_ZN7mozilla6scache12StartupCache13ThreadedWriteEPv
   fun:_pt_root
   fun:start_thread
   fun:clone
}
1451586319560	addons.update-checker	WARN	Update manifest for thunderbird-hotfix@mozilla.org did not contain an updates property
1451586324881	addons.xpi	ERROR	Failed to clean updated system add-ons directories.: Unix error 2 during operation DirectoryIterator.prototype.next on file /NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile/features (No such file or directory) ((unknown module)) No traceback available
++DOCSHELL 0x4cf9d8b0 == 3 [pid = 10823] [id = 3]
++DOMWINDOW == 6 (0x4cf9e9d0) [pid = 10823] [serial = 6] [outer = (nil)]




The next construct after the error info is something you didn't see.
{
   <insert_a_suppression_name_here>
   Memcheck:Cond
   fun:fill_window
   fun:deflate_fast
   fun:MOZ_Z_deflate
   fun:_ZN18nsDeflateConverter15OnDataAvailableEP10nsIRequestP11nsISupportsP14nsIInputStreammj
   ....[omission]
   fun:_pt_root
   fun:start_thread
   fun:clone
}

I see it because I specified --gen-suppressions=all
valgrind generates a pattern like the above with which we can tell
valgrind, shut up about a particular memory issue that matches this data (!).
Such a data is compiled into one's white-list patterns in a file and is specified, in my case,
by --suppressions=$HOME/Dropbox/myown.sup
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #53)
> Have you applied any of the princples/tools of
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/
> Refcount_tracing_and_balancing ?

Also, Do you still crash if you have started thunderbird in safe mode or a new Thunderbird profile?

You have a ton of extensions installed[1] including over a dozen language packages. And, I note that all nsImapMailFolder::ParseMsgHdrs crashes in 2016 [2] (which are rare indeed as kent points out) a) none are MS Windows  b) all of them have addons installed, and in many cases lang packs.  I find this highly suspicious.

[1] olaf addons
{847b3a00-7ab1-11d4-8f02-006008948af5}
{e2fda1a4-762b-4020-b5ad-a41df1933103}
{972ce4c6-7e08-4474-a285-3208198ce6fd}
langpack-da@thunderbird.mozilla.org
langpack-ja@thunderbird.mozilla.org
langpack-ca@thunderbird.mozilla.org
langpack-nb-NO@thunderbird.mozilla.org
langpack-fi@thunderbird.mozilla.org
langpack-zh-CN@thunderbird.mozilla.org
langpack-zh-TW@thunderbird.mozilla.org
langpack-ru@thunderbird.mozilla.org
langpack-it@thunderbird.mozilla.org
langpack-ko@thunderbird.mozilla.org
langpack-es-AR@thunderbird.mozilla.org
langpack-sv-SE@thunderbird.mozilla.org
langpack-pt-PT@thunderbird.mozilla.org
langpack-ar@thunderbird.mozilla.org
langpack-pl@thunderbird.mozilla.org
langpack-hu@thunderbird.mozilla.org
langpack-de@thunderbird.mozilla.org
langpack-pt-BR@thunderbird.mozilla.org
langpack-en-GB@thunderbird.mozilla.org
langpack-fr@thunderbird.mozilla.org
langpack-el@thunderbird.mozilla.org
langpack-nl@thunderbird.mozilla.org
langpack-es-ES@thunderbird.mozilla.org
langpack-cs@thunderbird.mozilla.org

[2] nsImapMailFolder::ParseMsgHdrs crashes in 2016
bp-4b18be9d-0929-40ca-950d-0a5822160103
bp-95b8156c-38f0-410e-8037-f2db52160107
bp-035cc4f1-124d-4a4e-bed5-2dbdc2160104
bp-a73be755-7b26-41d8-a398-f2a442160126
bp-6553cbc6-cb28-4548-b4dc-c83bd2160115
bp-23413d19-f263-47f4-beca-96f232160121
bp-d10e18a0-32c8-4154-8bdc-c94fc2160123
bp-1e00c7c8-5522-4f89-bd01-9bd272160125
bp-8c233a21-e47d-49b8-902b-cccd42160109
bp-978809b6-214a-401a-aaa0-04bf02160120
bp-9fa07043-9a73-4b43-b07a-f89672160122
bp-15fb49ef-0c2c-4117-a2ae-0f9a32160118
bp-85c0ea1b-07be-4e58-bec4-46eb12160122
bp-ca393945-049e-434b-bc68-1b7482160109
bp-97ebf375-7907-4832-a013-b67242160114
Flags: needinfo?(olaf)
Lastly, this may conflate an unrelated issue but I researched it and may as well document it - I sampled crashes for others who experienced nsImapMailFolder::ParseMsgHdrs crashes and who supplied email addresses. Notable is 1. very few crashed more than once with nsImapMailFolder::ParseMsgHdrs, 2. most have multiple crashes of various signatures [3]. Which, for that set of users, suggests our old friend imap off main thread releases http://mzl.la/1nR2Pnn 

[3] 
alex
6d965d83-8900-4343-a22d-75bad2151104	2015-11-04 15:32:46 	nsCOMPtr_base::~nsCOMPtr_base | nsThread::ProcessNextEvent | NS_ProcessNextEvent | mozilla::ipc::MessagePump::Run   Add term
e9349671-bad4-4fc0-b156-001b22151029	2015-10-29 12:42:47 	dosprintf   Add term
d0dd4b73-d484-4692-b51d-b45672151015	2015-10-15 08:16:44 	dosprintf   Add term
5908f4fd-4959-41d3-9e25-802c42151013	2015-10-13 14:31:27 	nsStringBuffer::Release   Add term
5ada7d2a-9b54-4f8a-a70d-2c48a2151006	2015-10-06 12:01:51 	dosprintf   Add term 
f87d7f2e-8c64-40fa-8acb-648e72150908    2015-09-08              nsImapMailFolder::ParseMsgHdrs

mp
b73d27b0-c049-4cd2-b63d-51efb2150807	2015-08-07 16:39:56 	nsFactoryEntry::GetFactory   Add term
460e3244-d19b-43ca-bef1-87cef2150824	2015-08-24 21:01:29 	nsImapMailFolder::ParseMsgHdrs   Add term 

pupu
aa4b531d-215b-49ca-b7b2-447482160114	2016-01-14 08:20:34 	CanonicalizeXPCOMParticipant   Add term
ef6c0f60-a61b-4736-8220-f0d8a2151221	2015-12-21 08:20:46 	nsCharTraits<T>::compare   Add term
89fc1cff-f818-4015-bb38-f7ff32151216	2015-12-16 12:02:48 	@0x0 | CanonicalizeXPCOMParticipant   Add term
c8c42073-3ada-45a0-be16-e72c82151207	2015-12-07 08:50:00 	nsThread::ProcessNextEvent | NS_ProcessNextEvent | mozilla::ipc::MessagePump::Run   Add term
2bf74490-194a-429a-9d56-40f902151125	2015-11-25 10:11:30 	CanonicalizeXPCOMParticipant   Add term
cdfcfd70-2d04-482e-9475-836282151102	2015-11-02 18:25:40 	nsImapMailFolder::ParseMsgHdrs   Add term
f283c454-4aa9-4d47-82e4-3531e2151102	2015-11-02 10:49:37 	nsCSSValueList::~nsCSSValueList   Add term
c40d368a-f919-415a-ba1e-fa7ad2151024	2015-10-24 19:50:50 	CallQueryInterface<T>   Add term
2fe1daab-d364-4af0-ac2f-b2ee32151016	2015-10-16 13:15:06 	js::UncheckedUnwrap   Add term
2fda0095-e00f-4014-9457-28e402151015	2015-10-15 07:18:58 	nsCOMPtr_base::assign_assuming_AddRef | nsImapMockChannel::SetImapProtocol   Add term
(In reply to ISHIKAWA, Chiaki from comment #54)
> I wonder what is the locale you use. This is because I see locale-related
> functions near the stack of failed task.

I think the exact locale does not matter. IMO its the usage of setlocale itself. The strings passed to it might be freed if they are not coming from the static strings from within glibc. But I did no deep analysis of that function. My understanding of the logs is that the third setlocale call referenced memory freed by the second setlocale call. My change which I'm running now uses strdup'ed values to see if that gets me further.
Starting from the top of the log in comment 48,
I see the following finally.

Somehow memset is called write something into an area of 16 octets already free'ed.
Something is wrong here.
What system (OS) do you use?
Are you up to date with the libraries?

==29117== Invalid write of size 8
==29117==    at 0x4C2C7DF: memset (vg_replace_strmem.c:1094)
==29117==    by 0xE463672: memset (string3.h:90)
==29117==    by 0xE463672: g_slice_alloc0 (gslice.c:1034)
==29117==    by 0xE1DC20D: g_type_create_instance (gtype.c:1847)
==29117==    by 0xE1BE87A: g_object_new_internal (gobject.c:1779)
==29117==    by 0xE1C0090: g_object_newv (gobject.c:1926)
==29117==    by 0xE1C09AB: g_object_new (gobject.c:1619)
==29117==    by 0xE8893C2: IA__gtk_rc_style_new (gtkrc.c:1260)
==29117==    by 0xE8893C2: gtk_rc_parse_style (gtkrc.c:3041)
==29117==    by 0xE8893C2: gtk_rc_parse_statement (gtkrc.c:2926)
==29117==    by 0xE8893C2: gtk_rc_parse_any (gtkrc.c:2275)
==29117==    by 0xE88A674: gtk_rc_context_parse_one_file (gtkrc.c:1033)
==29117==    by 0xE88A833: gtk_rc_context_parse_file (gtkrc.c:1099)
==29117==    by 0xE88AA52: gtk_rc_parse_named (gtkrc.c:847)
==29117==    by 0xE88B1F9: gtk_rc_reparse_all_for_settings (gtkrc.c:1833)
==29117==    by 0xE8A6CBD: gtk_settings_get_for_screen (gtksettings.c:1254)
==29117==  Address 0x60def10 is 0 bytes inside a block of size 16 free'd
==29117==    at 0xE1DC4F8: g_type_free_instance (gtype.c:1947)
==29117==    by 0xE88A0F7: gtk_rc_parse_engine (gtkrc.c:3761)
==29117==    by 0xE88A0F7: gtk_rc_parse_style (gtkrc.c:3167)
==29117==    by 0xE88A0F7: gtk_rc_parse_statement (gtkrc.c:2926)
==29117==    by 0xE88A0F7: gtk_rc_parse_any (gtkrc.c:2275)
==29117==    by 0xE88A674: gtk_rc_context_parse_one_file (gtkrc.c:1033)
==29117==    by 0xE88A833: gtk_rc_context_parse_file (gtkrc.c:1099)
==29117==    by 0xE88AA52: gtk_rc_parse_named (gtkrc.c:847)
==29117==    by 0xE88B1F9: gtk_rc_reparse_all_for_settings (gtkrc.c:1833)
==29117==    by 0xE8A6CBD: gtk_settings_get_for_screen (gtksettings.c:1254)
==29117==    by 0xE858140: display_opened_cb (gtkmodules.c:506)
==29117==    by 0xE1BC752: g_cclosure_marshal_VOID__OBJECTv (gmarshal.c:2102)
==29117==    by 0xE1B9A43: _g_closure_invoke_va (gclosure.c:864)
==29117==    by 0xE1D3A47: g_signal_emit_valist (gsignal.c:3292)
==29117==    by 0xE1D45D4: g_signal_emit_by_name (gsignal.c:3479)
==29117== 


BTW, there are many invalid read related to qstrlen, this doesn't count 
as a real error.
I think qstrlen is a version of strlen that reads four octets at a time using load-integer instruction and check if there is NUL in the four octets. Memory access is faster this way.

Problem with such "efficent" string manipulation function, in this case, a strlen version is that suppose a 4-octet word contains a valid octet, 0 terminator for the string, and then two undefined memory area:
    | V 0 ? ? |
Then the access to this word to recognize the end of the string is basically the access to an uninitialized memory area (!)

Also, another issue is related to the access to malloced area (such as dynamic string).
The error reported below is this.
malloc() allocated 14 octets of area (presumably 13 octets of data and one octet to store 0 at the end.)
"|" in the next line stands for the four-octet word boundary.
Sorry for somewhat warped, not-to-scale ASCII diagram.
each horizontal line (made up of "-"s is a single word (4 octet) access
to memory. (malloc() returns word-aligned memory. 

  |1 2 3 4| 5 6 7 8| 9 10 11 12 | 13 14 ?  ? |
  +---1---+
          +----2---+
                   +-----3------+
                                +-----4------+

The first three word accesses are OK. They are within the
malloc 'ed area.

Problem is the fourth word access. Half of it is OUTSIDE the malloc'ed area (!)
So valgrind complains that the fourth word access is invalid.
"ddress 0x15191cec is 12 bytes inside a block of size 14 alloc'd"
12 bytes inside a block of size 14 alloced means that "12" counted from "0" at the starting position is the position of the first "?" in the fourth word position.
That is no man's land as far as malloc() is concerned.

Thus the error warning.
But once you understand the background, it is not a serious issue UNLESS
the malloc() area is AT THE END of the sbrk() area, i.e., the properly page-mapped area of user space. Your word access may be OK, but there are implementations that
use 8-octet word (long long) access to read string data at once.
In this case, the latter half of the long long access may fall of the mapped page and thus causes an invalid memory access (if the starting address is multiple of 4, but not of 8.) 
Something like this can happen with too-eagerly-optimized instruction combination.

In any case, we should investigate why the usage after free occurs  in your code: what OS, what library, what compiler, etc.


Starting from the beginning of the 
==29117== Invalid read of size 4
==29117==    at 0x538F55F: qstrlen (qbytearray.h:80)
==29117==    by 0x538F55F: fromData (qgtkstyle_p.h:114)
==29117==    by 0x538F55F: classPath (qgtkstyle_p.cpp:254)
==29117==    by 0x538F55F: QGtkStylePrivate::addWidgetToMap(_GtkWidget*) (qgtkstyle_p.cpp:787)
==29117==    by 0x538F6B8: QGtkStylePrivate::addAllSubWidgets(_GtkWidget*, void*) (qgtkstyle_p.cpp:800)
==29117==    by 0x53927FF: QGtkStylePrivate::initGtkWidgets() const (qgtkstyle_p.cpp:568)
==29117==    by 0x5375A20: QGtkStyle::QGtkStyle() (qgtkstyle.cpp:193)
==29117==    by 0x52FDE7C: QStyleFactory::create(QString const&) (qstylefactory.cpp:177)
==29117==    by 0x500C9B5: QApplication::style() (qapplication.cpp:1465)
==29117==    by 0x500CD6C: QApplicationPrivate::initialize() (qapplication.cpp:991)
==29117==    by 0x500CE79: QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) (qapplication.cpp:843)
==29117==    by 0x500D0FE: QApplication::QApplication(int&, char**, int) (qapplication.cpp:741)
==29117==    by 0x404132: main (in /olh/privat/olaf-probook/olaf-tw/bin/firefox)
==29117==  Address 0x15191cec is 12 bytes inside a block of size 14 alloc'd
==29117==    at 0x4C2A00F: malloc (vg_replace_malloc.c:297)
==29117==    by 0x6B214F9: strdup (strdup.c:42)
==29117==    by 0x538F547: classPath (qgtkstyle_p.cpp:250)
==29117==    by 0x538F547: QGtkStylePrivate::addWidgetToMap(_GtkWidget*) (qgtkstyle_p.cpp:787)
==29117==    by 0x538F6B8: QGtkStylePrivate::addAllSubWidgets(_GtkWidget*, void*) (qgtkstyle_p.cpp:800)
==29117==    by 0x53927FF: QGtkStylePrivate::initGtkWidgets() const (qgtkstyle_p.cpp:568)
==29117==    by 0x5375A20: QGtkStyle::QGtkStyle() (qgtkstyle.cpp:193)
==29117==    by 0x52FDE7C: QStyleFactory::create(QString const&) (qstylefactory.cpp:177)
==29117==    by 0x500C9B5: QApplication::style() (qapplication.cpp:1465)
==29117==    by 0x500CD6C: QApplicationPrivate::initialize() (qapplication.cpp:991)
==29117==    by 0x500CE79: QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) (qapplication.cpp:843)
==29117==    by 0x500D0FE: QApplication::QApplication(int&, char**, int) (qapplication.cpp:741)
==29117==    by 0x404132: main (in /olh/privat/olaf-probook/olaf-tw/bin/firefox)
See Also: → 1243895
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #56)
> [1] olaf addons

Every openSUSE user has them.

> [2] nsImapMailFolder::ParseMsgHdrs crashes in 2016

This does not matter, because my mem corruption has hijacked for some NULL ptr patch.
(In reply to ISHIKAWA, Chiaki from comment #59)
> Starting from the top of the log in comment 48,
> I see the following finally.
> 
> Somehow memset is called write something into an area of 16 octets already
> free'ed.
> Something is wrong here.

Process != 21656, as said earlier TB forked FireFox via my Qt wrapper.
The gobject warnings are bogus. gobject has some valgrind support bug valgrind itself does not seem to handle it well. As you said, the Qt warnings are bogus as well. And even if both were bugs, they are in another process.

> What system (OS) do you use?

openSUSE Tumbleweed.

> Are you up to date with the libraries?

Yes, but depending on what your context of "up to date" is.
The setlocale change did not help. I will take the pain and run TB in valgrind for the rest of the week. Next I will try comment #53

This time I dumped the memory around the wellknown crash string of the IMAP server. These 0xe5e5 look like poison values, and some of them end in 0xe4 for some reason.

Program received signal SIGSEGV, Segmentation fault.
0x00007f2c3a824bc9 in JS_SetPrivate (obj=0x6d6f6328, data=data@entry=0x0) at /usr/src/debug/thunderbird/mozilla/js/src/jsapi.cpp:1669
1669    {
Sat Jan 30 06:35:43 UTC 2016
1664        return obj->as<NativeObject>().getPrivate();
1665    }
1666
1667    JS_PUBLIC_API(void)
1668    JS_SetPrivate(JSObject* obj, void* data)
1669    {
1670        /* This function can be called by a finalizer. */
1671        obj->as<NativeObject>().setPrivate(data);
1672    }
1673

Thread 1 (Thread 0x7f2c3f246740 (LWP 5926)):
#0  0x00007f2c3a824bc9 in JS_SetPrivate(JSObject*, void*) (obj=0x6d6f6328, data=data@entry=0x0) at /usr/src/debug/thunderbird/mozilla/js/src/jsapi.cpp:1669
#1  0x00007f2c390ae6a4 in XPCWrappedNative::FlatJSObjectFinalized() (this=0x7f2c1066dd00) at /usr/src/debug/thunderbird/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:895
#2  0x00007f2c3a8753af in FinalizeTypedArenas<JSObject>(js::FreeOp*, js::gc::ArenaHeader**, js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) (fop=0x7ffc6ffedff0, this=<optimized out>) at /usr/src/debug/thunderbird
/mozilla/js/src/jsobjinlines.h:42
#3  0x00007f2c3a8753af in FinalizeTypedArenas<JSObject>(js::FreeOp*, js::gc::ArenaHeader**, js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) (thingSize=48, thingKind=js::gc::FINALIZE_OBJECT2, fop=0x7ffc6ffedff0, this=0x7f2c24575000) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:497
#4  0x00007f2c3a8753af in FinalizeTypedArenas<JSObject>(js::FreeOp*, js::gc::ArenaHeader**, js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) (fop=0x7ffc6ffedff0, fop@entry=0x7f2c2a49e1c8, src=src@entry=0x7ffc6ffecd18, dest=..., thingKind=thingKind@entry=js::gc::FINALIZE_OBJECT2, budget=..., keepArenas=keepArenas@entry=js::gc::ArenaLists::KEEP_ARENAS) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:557
#5  0x00007f2c3a875ceb in js::gc::ArenaLists::forceFinalizeNow(js::FreeOp*, js::gc::AllocKind, js::gc::ArenaLists::KeepArenasEnum, js::gc::ArenaHeader**) (thingKind=js::gc::FINALIZE_OBJECT2, keepArenas=js::gc::ArenaLists::KEEP_ARENAS, budget=..., dest=..., src=0x7ffc6ffecd18, fop=0x7f2c2a49e1c8) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:600
#6  0x00007f2c3a875ceb in js::gc::ArenaLists::forceFinalizeNow(js::FreeOp*, js::gc::AllocKind, js::gc::ArenaLists::KeepArenasEnum, js::gc::ArenaHeader**) (this=this@entry=0x7f2c2a49e030, fop=fop@entry=0x7ffc6ffedff0, empty=empty@entry=0x7f2c2a49e528, keepArenas=js::gc::ArenaLists::KEEP_ARENAS, thingKind=js::gc::FINALIZE_OBJECT2) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:2758
#7  0x00007f2c3a875fc0 in js::gc::ArenaLists::queueForegroundObjectsForSweep(js::FreeOp*) (empty=0x7f2c2a49e528, keepArenas=js::gc::ArenaLists::KEEP_ARENAS, thingKind=js::gc::FINALIZE_OBJECT2, fop=0x7ffc6ffedff0, this=0x7f2c2a49e030) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:2741
#8  0x00007f2c3a875fc0 in js::gc::ArenaLists::queueForegroundObjectsForSweep(js::FreeOp*) (this=this@entry=0x7f2c2a49e030, fop=fop@entry=0x7ffc6ffedff0) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:2876
#9  0x00007f2c3a88bd74 in js::gc::GCRuntime::beginSweepingZoneGroup() (this=this@entry=0x7f2c2a42e318) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:5069
Flags: needinfo?(olaf)
(In reply to olaf from comment #61)
> ...
> > Are you up to date with the libraries?
> 
> Yes, but depending on what your context of "up to date" is.

perhaps you can be more specific how current your libraries are without having specifics from Chiaki?
Flags: needinfo?(olaf)
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #63)
> (In reply to olaf from comment #61)
> > ...
> > > Are you up to date with the libraries?
> > 
> > Yes, but depending on what your context of "up to date" is.
> 
> perhaps you can be more specific how current your libraries are without
> having specifics from Chiaki?

Are you refering to the mozilla libs?

$ for i in `obs ls mozilla:Factory`;do rpm -q $i ; done | grep -vw not
MozillaFirefox-43.0.4-1.2.x86_64
MozillaFirefox-branding-openSUSE-40-3.1.x86_64
MozillaThunderbird-38.5.1-2.olh.2.x86_64
enigmail-1.8.2-1.4.x86_64
mozilla-nspr-4.11-1.1.x86_64
mozilla-nss-3.20.2-2.2.x86_64
(In reply to ISHIKAWA, Chiaki from comment #54)
> I suspect some kind of interlock issues. Exclusion of tasks are not done very well, perhaps?

You mean the various threads dont syncronize access to the shared objects, or a general refcounting bug? That sounds likely, given that running with NSPR_LOG_MODULES=imap:1 seems to hide the bug. Perhaps this little extra debugging either changes the access pattern or the timing.
Also running with valgrind turned up nothing in the last four days.
(In reply to olaf from comment #62)
> Created attachment 8714321 [details]
> bp-c9b8e73c-9f4c-4f03-8bc5-86e6e2160201
> 
> The setlocale change did not help. I will take the pain and run TB in
> valgrind for the rest of the week. Next I will try comment #53

Last Friday evening, after runing for 4 days, TB lost the ability to connect to the IMAP server in question. It doesnt get past SYN_SENT according to lsof. I guess this is another variant of the corruption. As usual, valgrind did not report anything.

The other 3 IMAP servers continue to work fine. mutt can access all the servers.
Flags: needinfo?(olaf)
The full valgrind log. Not sure if that is of any value:

==23183== 370 errors in context 4 of 2572:
==23183== Conditional jump or move depends on uninitialised value(s)
==23183==    at 0x4C2D558: strlen (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23183==    by 0x9C18F2B: NewStringCopyZ<(js::AllowGC)1u> (String.h:1160)
==23183==    by 0x9C18F2B: JS_NewStringCopyZ(JSContext*, char const*) (jsapi.cpp:4352)
==23183==    by 0x849423E: XPCConvert::NativeData2JS(JS::MutableHandle<JS::Value>, void const*, nsXPTType const&, nsID const*, nsresult*) (XPCConvert.cpp:232)
==23183==    by 0x84A62EF: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJSClass.cpp:1119)
==23183==    by 0x81665A5: PrepareAndDispatch (xptcstubs_x86_64_linux.cpp:122)
==23183==    by 0x8165B1C: SharedStub (in /usr/lib64/thunderbird/libxul.so)
==23183==    by 0x7FF37F5: mime_write_message_body(nsIMsgSend*, char const*, unsigned int) (nsMsgSend.cpp:1203)
==23183==    by 0x80C8EF5: mozilla::mailnews::QPEncoder::Write(char const*, int) (mimeenc.cpp:1024)
==23183==    by 0x800099E: nsMsgSendPart::Write() [clone .part.4] [clone .constprop.5] (nsMsgSendPart.cpp:608)
==23183==    by 0x7FF958C: nsMsgComposeAndSend::GatherMimeAttachments() (nsMsgSend.cpp:909)
==23183==    by 0x7FFAC8A: nsMsgComposeAndSend::HackAttachments(nsIArray*, nsIArray*) (nsMsgSend.cpp:2599)
==23183==    by 0x7FFB2FE: nsMsgComposeAndSend::Init(nsIMsgIdentity*, char const*, nsMsgCompFields*, nsIFile*, bool, bool, int, nsIMsgDBHdr*, char const*, nsACString_internal const&, nsIArray*, nsIArray*, char const*, nsACString_internal const&, int) (nsMsgSend.cpp:3176)
==23183==  Uninitialised value was created by a stack allocation
==23183==    at 0x8000280: nsMsgSendPart::PushBody(char const*, int) (nsMsgSendPart.cpp:219)
(In reply to olaf from comment #65)
> (In reply to ISHIKAWA, Chiaki from comment #54)
> > I suspect some kind of interlock issues. Exclusion of tasks are not done very well, perhaps?
> 
> You mean the various threads dont syncronize access to the shared objects,
> or a general refcounting bug? That sounds likely, given that running with
> NSPR_LOG_MODULES=imap:1 seems to hide the bug.

like bug 538034?
Flags: needinfo?(ishikawa)
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #68)
> (In reply to olaf from comment #65)
> > (In reply to ISHIKAWA, Chiaki from comment #54)
> > > I suspect some kind of interlock issues. Exclusion of tasks are not done very well, perhaps?
> > 
> > You mean the various threads dont syncronize access to the shared objects,
> > or a general refcounting bug? That sounds likely, given that running with
> > NSPR_LOG_MODULES=imap:1 seems to hide the bug.
>
> like bug 538034?

I dont see functional issues with NSPR_LOG_MODULES=imap:1.
(In reply to olaf from comment #67)
> Created attachment 8716865 [details]
> thunderbird_valdgrind.txt.gz
> 
> The full valgrind log. Not sure if that is of any value:
> 
> ==23183== 370 errors in context 4 of 2572:
> ==23183== Conditional jump or move depends on uninitialised value(s)
> ==23183==    at 0x4C2D558: strlen (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==23183==    by 0x9C18F2B: NewStringCopyZ<(js::AllowGC)1u> (String.h:1160)
> ==23183==    by 0x9C18F2B: JS_NewStringCopyZ(JSContext*, char const*)
> (jsapi.cpp:4352)
> ==23183==    by 0x849423E:
> XPCConvert::NativeData2JS(JS::MutableHandle<JS::Value>, void const*,
> nsXPTType const&, nsID const*, nsresult*) (XPCConvert.cpp:232)
> ==23183==    by 0x84A62EF: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*,
> unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*)
> (XPCWrappedJSClass.cpp:1119)
> ==23183==    by 0x81665A5: PrepareAndDispatch
> (xptcstubs_x86_64_linux.cpp:122)
> ==23183==    by 0x8165B1C: SharedStub (in /usr/lib64/thunderbird/libxul.so)
> ==23183==    by 0x7FF37F5: mime_write_message_body(nsIMsgSend*, char const*,
> unsigned int) (nsMsgSend.cpp:1203)
> ==23183==    by 0x80C8EF5: mozilla::mailnews::QPEncoder::Write(char const*,
> int) (mimeenc.cpp:1024)
> ==23183==    by 0x800099E: nsMsgSendPart::Write() [clone .part.4] [clone
> .constprop.5] (nsMsgSendPart.cpp:608)
> ==23183==    by 0x7FF958C: nsMsgComposeAndSend::GatherMimeAttachments()
> (nsMsgSend.cpp:909)
> ==23183==    by 0x7FFAC8A: nsMsgComposeAndSend::HackAttachments(nsIArray*,
> nsIArray*) (nsMsgSend.cpp:2599)
> ==23183==    by 0x7FFB2FE: nsMsgComposeAndSend::Init(nsIMsgIdentity*, char
> const*, nsMsgCompFields*, nsIFile*, bool, bool, int, nsIMsgDBHdr*, char
> const*, nsACString_internal const&, nsIArray*, nsIArray*, char const*,
> nsACString_internal const&, int) (nsMsgSend.cpp:3176)
> ==23183==  Uninitialised value was created by a stack allocation
> ==23183==    at 0x8000280: nsMsgSendPart::PushBody(char const*, int)
> (nsMsgSendPart.cpp:219)

I think this is indeed a corruption of a sort.
I think you need to insert a probe in the said PushBody to see if any of the locally
declared variables have undefined data at the beginning.
(Funny, though, I only see a few pointer type variables declared in there.
I am not sure how they can be "uninitialized"?)
Flags: needinfo?(ishikawa)
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #68)
> (In reply to olaf from comment #65)
> > (In reply to ISHIKAWA, Chiaki from comment #54)
> > > I suspect some kind of interlock issues. Exclusion of tasks are not done very well, perhaps?
> > 
> > You mean the various threads dont syncronize access to the shared objects,
> > or a general refcounting bug? That sounds likely, given that running with
> > NSPR_LOG_MODULES=imap:1 seems to hide the bug.
> 
> like bug 538034?

No, not as elaborate and specific as in bug 538034, but more mundante, "Oh, I forgot" type of bugs when multiple accounts to same server exist, etc.
Restore hijacked summary
Summary: Thunderbird crashes in nsImapMailFolder::ParseMsgHdrs → Thunderbird crashes due to use-after-free or pointer corruption
Same memory corruption with TB 45.

Thread 1 "thunderbird-bin" received signal SIGSEGV, Segmentation fault.
js::UncheckedUnwrap (wrapped=<optimized out>, wrapped@entry=0x7eff0557b520, stopAtWindowProxy=stopAtWindowProxy@entry=true, flagsp=flagsp@entry=0x0) at /usr/src/debug/thunderbird/mozilla/js/src/proxy/Wrapper.cpp:73
73                  wrapped = MaybeForwarded(wrapped);
Sun May  8 16:10:29 UTC 2016
68              wrapped = wrapped->as<ProxyObject>().private_().toObjectOrNull();
69
70              // This can be called from DirectProxyHandler::weakmapKeyDelegate() on a
71              // wrapper whose referent has been moved while it is still unmarked.
72              if (wrapped)
73                  wrapped = MaybeForwarded(wrapped);
74          }
75          if (flagsp)
76              *flagsp = flags;
77          return wrapped;

Thread 1 (Thread 0x7eff4c203740 (LWP 4293)):
#0  0x00007eff473df5c3 in js::UncheckedUnwrap(JSObject*, bool, unsigned int*) (wrapped=<optimized out>, wrapped@entry=0x7eff0557b520, stopAtWindowProxy=stopAtWindowProxy@entry=true, flagsp=flagsp@entry=0x0) at /usr/src/debug/thunderbird/mozilla/js/src/proxy/Wrapper.cpp:73
#1  0x00007eff473dc453 in js::NukeCrossCompartmentWrappers(JSContext*, js::CompartmentFilter const&, js::CompartmentFilter const&, js::NukeReferencesToWindow) (cx=<optimized out>, sourceFilter=..., targetFilter=..., nukeReferencesToWindow=nukeReferencesToWindow@entry=js::DontNukeWindowReferences) at /usr/src/debug/thunderbird/mozilla/js/src/proxy/CrossCompartmentWrapper.cpp:474
#2  0x00007eff45cfafef in WindowDestroyedEvent::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/dom/base/nsGlobalWindow.cpp:8518
#3  0x00007eff4566b5b4 in nsThread::ProcessNextEvent(bool, bool*) (this=0x7eff4adc8fc0, aMayWait=<optimized out>, aResult=0x7ffe3b7eaadf) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/nsThread.cpp:972
#4  0x00007eff45684d60 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aMayWait=aMayWait@entry=false) at /usr/src/debug/thunderbird/mozilla/xpcom/glue/nsThreadUtils.cpp:297
#5  0x00007eff45853864 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7eff38099880, aDelegate=0x7eff4adca4e0) at /usr/src/debug/thunderbird/mozilla/ipc/glue/MessagePump.cpp:95
#6  0x00007eff4583fdba in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:227
#7  0x00007eff4583fdba in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:201
#8  0x00007eff4673d6e9 in nsBaseAppShell::Run() (this=0x7eff32531040) at /usr/src/debug/thunderbird/mozilla/widget/nsBaseAppShell.cpp:156
#9  0x00007eff46cb5cf5 in nsAppStartup::Run() (this=0x7eff3252f6f0) at /usr/src/debug/thunderbird/mozilla/toolkit/components/startup/nsAppStartup.cpp:281
#10 0x00007eff46ce8600 in XREMain::XRE_mainRun() (this=this@entry=0x7ffe3b7ead58) at /usr/src/debug/thunderbird/mozilla/toolkit/xre/nsAppRunner.cpp:4285
#11 0x00007eff46ce88ab in XREMain::XRE_main(int, char**, nsXREAppData const*) (this=this@entry=0x7ffe3b7ead58, argc=argc@entry=1, argv=argv@entry=0x7ffe3b7ec248, aAppData=aAppData@entry=0x7ffe3b7eaf58) at /usr/src/debug/thunderbird/mozilla/toolkit/xre/nsAppRunner.cpp:4382
#12 0x00007eff46ce8adc in XRE_main(int, char**, nsXREAppData const*, uint32_t) (argc=1, argv=0x7ffe3b7ec248, aAppData=0x7ffe3b7eaf58, aFlags=<optimized out>) at /usr/src/debug/thunderbird/mozilla/toolkit/xre/nsAppRunner.cpp:4484
#13 0x0000000000405468 in do_main(int, char**, nsIFile*) (argc=argc@entry=1, argv=argv@entry=0x7ffe3b7ec248, xreDirectory=0x7eff4ad49a80) at /usr/src/debug/thunderbird/mail/app/nsMailApp.cpp:195
#14 0x0000000000404c32 in main(int, char**) (argc=1, argv=0x7ffe3b7ec248) at /usr/src/debug/thunderbird/mail/app/nsMailApp.cpp:332
more thoughts?
Crash Signature: [@ nsImapMailFolder::ParseMsgHdrs ] → [@ nsImapMailFolder::ParseMsgHdrs ] [@ libxul.so@0x2a1e5c3 | libxul.so@0x2a1b452 | libxul.so@0x139a5e9 | libxul.so@0x1339fee | libxul.so@0xc74575 | libxul.so@0x49f8437 | libxul.so@0x49c65e7 | libnspr4.so@0x2c000 ] [@ @0x0 | libxul.so@0xabe0f5 | libxul.s…
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(ishikawa)
No idea sorry
Flags: needinfo?(mkmelin+mozilla)
This time I was playing with a GroupWise Calendar invite.
Which is something I usually dont do, never use the TB Calender thing. While clicking on the "More ..." pulldown menu which is next to the Accept/Decline button TB crashed with the wellknown pattern.

Thread 1 "thunderbird-bin" received signal SIGSEGV, Segmentation fault.
nsBorderColors::~nsBorderColors (this=0x656d652e6c69616d, __in_chrg=<optimized out>) at /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleStruct.cpp:391
391       NS_CSS_DELETE_LIST_MEMBER(nsBorderColors, this, mNext);
Tue May 10 10:01:01 UTC 2016
386       mTwipsPerPixel = aPresContext->DevPixelsToAppUnits(1);
387     }
388
389     nsBorderColors::~nsBorderColors()
390     {
391       NS_CSS_DELETE_LIST_MEMBER(nsBorderColors, this, mNext);
392     }
393
394     nsBorderColors*
395     nsBorderColors::Clone(bool aDeep) const

Thread 1 (Thread 0x7f32195c7740 (LWP 3155)):
#0  0x00007f3213c4a8e3 in nsBorderColors::~nsBorderColors() (this=0x656d652e6c69616d, __in_chrg=<optimized out>) at /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleStruct.cpp:391
#1  0x00007f3213c52157 in nsStyleBorder::~nsStyleBorder() (this=0x7f31e4bb9830, __in_chrg=<optimized out>) at /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleStruct.cpp:443
#2  0x00007f3213c521d6 in nsStyleBorder::Destroy(nsPresContext*) (this=0x7f31e4bb9830, aContext=aContext@entry=0x7f31e73b2800) at /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleStruct.cpp:478
#3  0x00007f3213c5a1b3 in nsResetStyleData::Destroy(unsigned long, nsPresContext*) (this=0x7f31e1aba538, aBits=842350461457, aContext=aContext@entry=0x7f31e73b2800) at ./nsStyleStructList.h:127
#4  0x00007f3213c5a2aa in nsStyleContext::~nsStyleContext() (this=0x7f31e30b4988, __in_chrg=<optimized out>) at /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleContext.cpp:168
#5  0x00007f3213c5a2fb in nsStyleContext::Destroy() (this=0x7f31e30b4988) at /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleContext.cpp:1194
#6  0x00007f32136c4de5 in nsStyleContext::Release() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleContext.h:108
#7  0x00007f3213c5a27f in nsStyleContext::~nsStyleContext() (this=0x7f31e1b614c0, __in_chrg=<optimized out>) at /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleContext.cpp:162
#8  0x00007f3213c5a2fb in nsStyleContext::Destroy() (this=0x7f31e1b614c0) at /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleContext.cpp:1194
#9  0x00007f32136c4de5 in nsStyleContext::Release() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleContext.h:108
#10 0x00007f3213c7c67d in RefPtr<nsStyleContext>::assign_assuming_AddRef(nsStyleContext*) (aPtr=<optimized out>) at ../../dist/include/mozilla/RefPtr.h:362
#11 0x00007f3213c7c67d in RefPtr<nsStyleContext>::assign_assuming_AddRef(nsStyleContext*) (aPtr=<optimized out>) at ../../dist/include/mozilla/RefPtr.h:372
#12 0x00007f3213c7c67d in RefPtr<nsStyleContext>::assign_assuming_AddRef(nsStyleContext*) (this=this@entry=0x7fff99b562b8, aNewPtr=aNewPtr@entry=0x0) at ../../dist/include/mozilla/RefPtr.h:43
#13 0x00007f3213c85fb4 in mozilla::ElementRestyler::Restyle(nsRestyleHint) (aRawPtr=0x0, this=0x7fff99b562b8) at ../../dist/include/mozilla/RefPtr.h:34
#14 0x00007f3213c85fb4 in mozilla::ElementRestyler::Restyle(nsRestyleHint) (aRhs=0x0, this=0x7fff99b562b8) at ../../dist/include/mozilla/RefPtr.h:153
#15 0x00007f3213c85fb4 in mozilla::ElementRestyler::Restyle(nsRestyleHint) (this=this@entry=0x7fff99b563c8, aRestyleHint=aRestyleHint@entry=0) at /usr/src/debug/thunderbird/mozilla/layout/base/RestyleManager.cpp:3424
#16 0x00007f3213c86c7e in mozilla::ElementRestyler::RestyleContentChildren(nsIFrame*, nsRestyleHint) (this=this@entry=0x7fff99b56698, aParent=aParent@entry=0x7f31e27dd0c0, aChildRestyleHint=aChildRestyleHint@entry=0) at /usr/src/debug/thunderbird/mozilla/layout/base/RestyleManager.cpp:4861
#17 0x00007f3213c86cfa in mozilla::ElementRestyler::RestyleChildren(nsRestyleHint) (this=0x7fff99b56698, aChildRestyleHint=0) at /usr/src/debug/thunderbird/mozilla/layout/base/RestyleManager.cpp:4383
#18 0x00007f3213c85fd8 in mozilla::ElementRestyler::Restyle(nsRestyleHint) (this=this@entry=0x7fff99b56698, aRestyleHint=<optimized out>, aRestyleHint@entry=0) at /usr/src/debug/thunderbird/mozilla/layout/base/RestyleManager.cpp:3438
#19 0x00007f3213c86c7e in mozilla::ElementRestyler::RestyleContentChildren(nsIFrame*, nsRestyleHint) (this=this@entry=0x7fff99b56968, aParent=aParent@entry=0x7f31e1beb088, aChildRestyleHint=aChildRestyleHint@entry=0) at /usr/src/debug/thunderbird/mozilla/layout/base/RestyleManager.cpp:4861
....
(In reply to olaf from comment #76)
> Created attachment 8750724 [details]
> bp-b3755f86-c06a-4f8e-a9ae-8068a2160510
> 
> This time I was playing with a GroupWise Calendar invite.
> Which is something I usually dont do, never use the TB Calender thing. While
> clicking on the "More ..." pulldown menu which is next to the Accept/Decline
> button TB crashed with the wellknown pattern.
> 
> Thread 1 "thunderbird-bin" received signal SIGSEGV, Segmentation fault.
> nsBorderColors::~nsBorderColors (this=0x656d652e6c69616d,
> __in_chrg=<optimized out>) at
> /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleStruct.cpp:391
> 391       NS_CSS_DELETE_LIST_MEMBER(nsBorderColors, this, mNext);
> Tue May 10 10:01:01 UTC 2016
> 386       mTwipsPerPixel = aPresContext->DevPixelsToAppUnits(1);
> 387     }
> 388
> 389     nsBorderColors::~nsBorderColors()
> 390     {
> 391       NS_CSS_DELETE_LIST_MEMBER(nsBorderColors, this, mNext);
> 392     }
> 393
> 394     nsBorderColors*
> 395     nsBorderColors::Clone(bool aDeep) const
> 
> Thread 1 (Thread 0x7f32195c7740 (LWP 3155)):
> #0  0x00007f3213c4a8e3 in nsBorderColors::~nsBorderColors()
> (this=0x656d652e6c69616d, __in_chrg=<optimized out>) at
> /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleStruct.cpp:391
> #1  0x00007f3213c52157 in nsStyleBorder::~nsStyleBorder()
> (this=0x7f31e4bb9830, __in_chrg=<optimized out>) at
> /usr/src/debug/thunderbird/mozilla/layout/style/nsStyleStruct.cpp:443

This time, TB seemed to have crashed inside this Color handling routine.

Actually, I tried using windows TB 45.x 32-bit binary in windows 10 64-bit 
and checked to see if pushing "more" button of a calendar event message causes some failures. There, I saw "save" button and when I hit it, the event was recorded into TB's lightening calednar. No crash. 
Hmm., maybe the bug is unique to linux AND/OR unique to  64-bit version ?

Olaf, is your PC's memory known to be good?
Many years ago, I have an issue with bad memory sticks that manifests with memtest86+ check but BIOS testing did not detect it (and that is when I failed to use ECC memory at home PC. For now, all my PCs (except at the office of all the places!) use ECC for the comfort of my mind. At least, when the crash occurs, I am certain it is a software bug rather than a random hardware failure.)

I mentioned 64-bit because there *could* be bad cast between pointer and 32-bit integer somewhere...

I am using Debian, and my occasional valgrind testing does not find new memory bugs these days, but I don't use IMAP and imap testing seems to be not so through within |make mozmill| testing.
If there is a short procedure that can be reproducible (for example, I will try to see
if a linux version of TB 45 32-bit on my office PC will crash or not if I push "more" button of a calendar event message.

But the calendar events I receive come from OFFICe365 server and not from Groupwise. If you can produce a calendar event from a groupwise calendar server, maybe you can send one to my ishikawa@yk.rim.or.jp account so that I can possibly
test operation on my PCs. The event can be a "virtual meeting" sometime next week, etc.

TIA
Flags: needinfo?(ishikawa)
(In reply to ISHIKAWA, Chiaki from comment #77)
> Olaf, is your PC's memory known to be good?

Likely yes.
Its the same well known string written over a pointer, just check all the attached backtraces.
(In reply to olaf from comment #78)
> (In reply to ISHIKAWA, Chiaki from comment #77)
> > Olaf, is your PC's memory known to be good?
> 
> Likely yes.
> Its the same well known string written over a pointer, just check all the
> attached backtraces.

I see. It looks to me that there could be a DNS-resolver issue (if the host name, domain name gets
pasted over to random places). Maybe the version of resolver library on your system and mine differs somewhat and I don't see the issue (or that I don't use IMAP for real: I only use a local imap server, davecot server running on the same PC for testing. This may explain that I don't hit the problem. Hmm....)

Probably we need a more crash dumps from OTHER imap users also to nail down the cause of the bug.
(In reply to ISHIKAWA, Chiaki from comment #79)
> I see. It looks to me that there could be a DNS-resolver issue (if the host
> name, domain name gets

The name comes straight from /etc/hosts, otherwise it would come from the local dnsmasq. I forced slight variants of *.novell.com to see which config string is being used. But its always the same string.
After changing stack size from 8 to 24mb TB is still running. Will let it run for one more week, then go down to less than 8.

screenlog.2:+ ulimit -s 24576
screenlog.2:Tue May 10 12:24:13 UTC 2016
(In reply to olaf from comment #81)
> After changing stack size from 8 to 24mb TB is still running. Will let it
> run for one more week, then go down to less than 8.
> 
> screenlog.2:+ ulimit -s 24576
> screenlog.2:Tue May 10 12:24:13 UTC 2016

So you suspect stack overflow. How interesting. I have used TB under linux for 12+ years, but never had this issue (I think). It would be interesting if you can catch who is to blame (native c++ code, or badly written JS script? I understand you have many addons, correct?)
Is there a slim chance that in this example the linked list in mFirstChunk is not properly maintained?
The second element contains the well known host string. Perhaps mFirstChunk->mNextChunk should have been NULL already?

Thread 1 "thunderbird-bin" received signal SIGSEGV, Segmentation fault.
JS_SetPrivate (obj=0x6d6f6328, data=data@entry=0x0) at /usr/src/debug/thunderbird/mozilla/js/src/jsapi.cpp:1756
1756        obj->as<NativeObject>().setPrivate(data);
Fri May 20 06:36:15 UTC 2016
1751
1752    JS_PUBLIC_API(void)
1753    JS_SetPrivate(JSObject* obj, void* data)
1754    {
1755        /* This function can be called by a finalizer. */
1756        obj->as<NativeObject>().setPrivate(data);
1757    }
1758
1759    JS_PUBLIC_API(void*)
1760    JS_GetInstancePrivate(JSContext* cx, HandleObject obj, const JSClass* clasp, CallArgs* args)

Thread 1 (Thread 0x7fce5b9b7740 (LWP 4336)):
#0  0x00007fce56b2d419 in JS_SetPrivate(JSObject*, void*) (obj=0x6d6f6328, data=data@entry=0x0) at /usr/src/debug/thunderbird/mozilla/js/src/jsapi.cpp:1756
#1  0x00007fce5525825f in XPCWrappedNative::FlatJSObjectFinalized() (this=0x7fce0c1cd280) at /usr/src/debug/thunderbird/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:904
#2  0x00007fce56b60cbe in FinalizeTypedArenas<JSObject>(js::FreeOp*, js::gc::ArenaHeader**, js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) (fop=0x7ffe0bb97b50, this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/js/src/jsobjinlines.h:82
#3  0x00007fce56b60cbe in FinalizeTypedArenas<JSObject>(js::FreeOp*, js::gc::ArenaHeader**, js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) (thingSize=48, thingKind=js::gc::AllocKind::OBJECT2, fop=0x7ffe0bb97b50, this=0x7fcdf86c7000) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:512
#4  0x00007fce56b60cbe in FinalizeTypedArenas<JSObject>(js::FreeOp*, js::gc::ArenaHeader**, js::gc::SortedArenaList&, js::gc::AllocKind, js::SliceBudget&, js::gc::ArenaLists::KeepArenasEnum) (fop=0x7ffe0bb97b50, fop@entry=0x7fce422b3248, src=src@entry=0x7ffe0bb96858, dest=..., thingKind=thingKind@entry=js::gc::AllocKind::OBJECT2, budget=..., keepArenas=keepArenas@entry=js::gc::ArenaLists::KEEP_ARENAS) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:572
#5  0x00007fce56b6173d in js::gc::ArenaLists::forceFinalizeNow(js::FreeOp*, js::gc::AllocKind, js::gc::ArenaLists::KeepArenasEnum, js::gc::ArenaHeader**) (thingKind=js::gc::AllocKind::OBJECT2, keepArenas=js::gc::ArenaLists::KEEP_ARENAS, budget=..., dest=..., src=0x7ffe0bb96858, fop=0x7fce422b3248) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:617
#6  0x00007fce56b6173d in js::gc::ArenaLists::forceFinalizeNow(js::FreeOp*, js::gc::AllocKind, js::gc::ArenaLists::KeepArenasEnum, js::gc::ArenaHeader**) (this=this@entry=0x7fce422b3070, fop=fop@entry=0x7ffe0bb97b50, empty=empty@entry=0x7fce422b35e0, keepArenas=js::gc::ArenaLists::KEEP_ARENAS, thingKind=js::gc::AllocKind::OBJECT2) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:2885
#7  0x00007fce56b61a0d in js::gc::ArenaLists::queueForegroundObjectsForSweep(js::FreeOp*) (empty=0x7fce422b35e0, keepArenas=js::gc::ArenaLists::KEEP_ARENAS, thingKind=js::gc::AllocKind::OBJECT2, fop=0x7ffe0bb97b50, this=0x7fce422b3070) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:2868
#8  0x00007fce56b61a0d in js::gc::ArenaLists::queueForegroundObjectsForSweep(js::FreeOp*) (this=this@entry=0x7fce422b3070, fop=fop@entry=0x7ffe0bb97b50) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:3004
#9  0x00007fce56b6dfdc in js::gc::GCRuntime::beginSweepingZoneGroup() (this=this@entry=0x7fce422323f8) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:5217
#10 0x00007fce56b6edc2 in js::gc::GCRuntime::sweepPhase(js::SliceBudget&) (this=this@entry=0x7fce422323f8, sliceBudget=...) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:5491
#11 0x00007fce56b73de5 in js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason) (this=this@entry=0x7fce422323f8, budget=..., reason=reason@entry=JS::gcreason::REFRESH_FRAME) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:6086
#12 0x00007fce56b749ac in js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason) (this=this@entry=0x7fce422323f8, nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., reason=reason@entry=JS::gcreason::REFRESH_FRAME) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:6278
#13 0x00007fce56b74d55 in js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason) (this=this@entry=0x7fce422323f8, nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., reason=reason@entry=JS::gcreason::REFRESH_FRAME) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:6384
#14 0x00007fce56b76a38 in JS::NotifyDidPaint(JSRuntime*) (millis=0, reason=JS::gcreason::REFRESH_FRAME, this=0x7fce422323f8) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:6457
#15 0x00007fce56b76a38 in JS::NotifyDidPaint(JSRuntime*) (this=0x7fce422323f8) at /usr/src/debug/thunderbird/mozilla/js/src/jsgc.cpp:6518
...
This time with 42mb stack.

Thread 1 "thunderbird-bin" received signal SIGSEGV, Segmentation fault.
js::UncheckedUnwrap (wrapped=<optimized out>, wrapped@entry=0x7fe6269334c0, stopAtWindowProxy=stopAtWindowProxy@entry=true, flagsp=flagsp@entry=0x0) at /usr/src/debug/thunderbird/mozilla/js/src/proxy/Wrapper.cpp:73
73                  wrapped = MaybeForwarded(wrapped);
Sat May 21 05:31:49 UTC 2016
68              wrapped = wrapped->as<ProxyObject>().private_().toObjectOrNull();
69      
70              // This can be called from DirectProxyHandler::weakmapKeyDelegate() on a
71              // wrapper whose referent has been moved while it is still unmarked.
72              if (wrapped)
73                  wrapped = MaybeForwarded(wrapped);
74          }
75          if (flagsp)
76              *flagsp = flags;
77          return wrapped;

Thread 1 (Thread 0x7fe66d1b3740 (LWP 3026)):
#0  0x00007fe6683e05c3 in js::UncheckedUnwrap(JSObject*, bool, unsigned int*) (wrapped=<optimized out>, wrapped@entry=0x7fe6269334c0, stopAtWindowProxy=stopAtWindowProxy@entry=true, flagsp=flagsp@entry=0x0) at /usr/src/debug/thunderbird/mozilla/js/src/proxy/Wrapper.cpp:73
#1  0x00007fe6683dd453 in js::NukeCrossCompartmentWrappers(JSContext*, js::CompartmentFilter const&, js::CompartmentFilter const&, js::NukeReferencesToWindow) (cx=<optimized out>, sourceFilter=..., targetFilter=..., nukeReferencesToWindow=nukeReferencesToWindow@entry=js::DontNukeWindowReferences) at /usr/src/debug/thunderbird/mozilla/js/src/proxy/CrossCompartmentWrapper.cpp:474
#2  0x00007fe666cfbfef in WindowDestroyedEvent::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/dom/base/nsGlobalWindow.cpp:8518
#3  0x00007fe66666c5b4 in nsThread::ProcessNextEvent(bool, bool*) (this=0x7fe66bdc8fc0, aMayWait=<optimized out>, aResult=0x7ffee9ae0a0f) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/nsThread.cpp:972
#4  0x00007fe666685d60 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aMayWait=aMayWait@entry=false) at /usr/src/debug/thunderbird/mozilla/xpcom/glue/nsThreadUtils.cpp:297
#5  0x00007fe666854864 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7fe659899880, aDelegate=0x7fe66bde4330) at /usr/src/debug/thunderbird/mozilla/ipc/glue/MessagePump.cpp:95
#6  0x00007fe666840dba in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:227
#7  0x00007fe666840dba in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:201
#8  0x00007fe66773e6e9 in nsBaseAppShell::Run() (this=0x7fe648b30100) at /usr/src/debug/thunderbird/mozilla/widget/nsBaseAppShell.cpp:156
#9  0x00007fe667cb6cf5 in nsAppStartup::Run() (this=0x7fe648b2e060) at /usr/src/debug/thunderbird/mozilla/toolkit/components/startup/nsAppStartup.cpp:281
#10 0x00007fe667ce9600 in XREMain::XRE_mainRun() (this=this@entry=0x7ffee9ae0c88) at /usr/src/debug/thunderbird/mozilla/toolkit/xre/nsAppRunner.cpp:4285
#11 0x00007fe667ce98ab in XREMain::XRE_main(int, char**, nsXREAppData const*) (this=this@entry=0x7ffee9ae0c88, argc=argc@entry=1, argv=argv@entry=0x7ffee9ae2178, aAppData=aAppData@entry=0x7ffee9ae0e88) at /usr/src/debug/thunderbird/mozilla/toolkit/xre/nsAppRunner.cpp:4382
#12 0x00007fe667ce9adc in XRE_main(int, char**, nsXREAppData const*, uint32_t) (argc=1, argv=0x7ffee9ae2178, aAppData=0x7ffee9ae0e88, aFlags=<optimized out>) at /usr/src/debug/thunderbird/mozilla/toolkit/xre/nsAppRunner.cpp:4484
#13 0x0000000000405468 in do_main(int, char**, nsIFile*) (argc=argc@entry=1, argv=argv@entry=0x7ffee9ae2178, xreDirectory=0x7fe66bd49a80) at /usr/src/debug/thunderbird/mail/app/nsMailApp.cpp:195
#14 0x0000000000404c32 in main(int, char**) (argc=1, argv=0x7ffee9ae2178) at /usr/src/debug/thunderbird/mail/app/nsMailApp.cpp:332
Another one with 42mb stack. Stacktrace appearently identical to previous crash.

Thread 1 "thunderbird-bin" received signal SIGSEGV, Segmentation fault.
js::UncheckedUnwrap (wrapped=<optimized out>, wrapped@entry=0x7fdae3fa2ac0, stopAtWindowProxy=stopAtWindowProxy@entry=true, flagsp=flagsp@entry=0x0) at /usr/src/debug/thunderbird/mozilla/js/src/proxy/Wrapper.cpp:73
73                  wrapped = MaybeForwarded(wrapped);
Mon May 23 12:45:21 UTC 2016
68              wrapped = wrapped->as<ProxyObject>().private_().toObjectOrNull();
69
70              // This can be called from DirectProxyHandler::weakmapKeyDelegate() on a
71              // wrapper whose referent has been moved while it is still unmarked.
72              if (wrapped)
73                  wrapped = MaybeForwarded(wrapped);
74          }
75          if (flagsp)
76              *flagsp = flags;
77          return wrapped;


Thread 1 (Thread 0x7fdb5f8b0740 (LWP 4781)):
#0  0x00007fdb5aadee03 in js::UncheckedUnwrap(JSObject*, bool, unsigned int*) (wrapped=<optimized out>, wrapped@entry=0x7fdae3fa2ac0, stopAtWindowProxy=stopAtWindowProxy@entry=true, flagsp=flagsp@entry=0x0) at /usr/src/debug/thunderbird/mozilla/js/src/proxy/Wrapper.cpp:73
#1  0x00007fdb5aadbc93 in js::NukeCrossCompartmentWrappers(JSContext*, js::CompartmentFilter const&, js::CompartmentFilter const&, js::NukeReferencesToWindow) (cx=<optimized out>, sourceFilter=..., targetFilter=..., nukeReferencesToWindow=nukeReferencesToWindow@entry=js::DontNukeWindowReferences) at /usr/src/debug/thunderbird/mozilla/js/src/proxy/CrossCompartmentWrapper.cpp:474
#2  0x00007fdb593f91a7 in WindowDestroyedEvent::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/dom/base/nsGlobalWindow.cpp:8518
#3  0x00007fdb58d6960e in nsThread::ProcessNextEvent(bool, bool*) (this=0x7fdb5e4c9fc0, aMayWait=<optimized out>, aResult=0x7fffbafb8dbf) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/nsThread.cpp:972
#4  0x00007fdb58d82dba in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aMayWait=aMayWait@entry=false) at /usr/src/debug/thunderbird/mozilla/xpcom/glue/nsThreadUtils.cpp:297
#5  0x00007fdb58f518be in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7fdb4cd9f880, aDelegate=0x7fdb5e4ea330) at /usr/src/debug/thunderbird/mozilla/ipc/glue/MessagePump.cpp:95
#6  0x00007fdb58f3de14 in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:227
#7  0x00007fdb58f3de14 in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:201
#8  0x00007fdb59e3b9ed in nsBaseAppShell::Run() (this=0x7fdb3b12f0a0) at /usr/src/debug/thunderbird/mozilla/widget/nsBaseAppShell.cpp:156
#9  0x00007fdb5a3b42ad in nsAppStartup::Run() (this=0x7fdb3b130600) at /usr/src/debug/thunderbird/mozilla/toolkit/components/startup/nsAppStartup.cpp:281
#10 0x00007fdb5a3e6bb8 in XREMain::XRE_mainRun() (this=this@entry=0x7fffbafb9038) at /usr/src/debug/thunderbird/mozilla/toolkit/xre/nsAppRunner.cpp:4285
#11 0x00007fdb5a3e6e63 in XREMain::XRE_main(int, char**, nsXREAppData const*) (this=this@entry=0x7fffbafb9038, argc=argc@entry=1, argv=argv@entry=0x7fffbafba528, aAppData=aAppData@entry=0x7fffbafb9238) at /usr/src/debug/thunderbird/mozilla/toolkit/xre/nsAppRunner.cpp:4382
#12 0x00007fdb5a3e7094 in XRE_main(int, char**, nsXREAppData const*, uint32_t) (argc=1, argv=0x7fffbafba528, aAppData=0x7fffbafb9238, aFlags=<optimized out>) at /usr/src/debug/thunderbird/mozilla/toolkit/xre/nsAppRunner.cpp:4484
#13 0x0000000000405468 in do_main(int, char**, nsIFile*) (argc=argc@entry=1, argv=argv@entry=0x7fffbafba528, xreDirectory=0x7fdb5e449a80) at /usr/src/debug/th
Looks like ulimit -s 42M triggers the issue sooner.


Thread 1 "thunderbird-bin" received signal SIGSEGV, Segmentation fault.
0x00007f2afd02febe in CanonicalizeXPCOMParticipant (aIn=0x7f2aa22178e0) at /usr/src/debug/thunderbird/mozilla/xpcom/base/nsCycleCollector.cpp:946
946                           reinterpret_cast<void**>(&out));
Tue May 24 04:59:04 UTC 2016
941     static nsISupports*
942     CanonicalizeXPCOMParticipant(nsISupports* aIn)
943     {
944       nsISupports* out = nullptr;
945       aIn->QueryInterface(NS_GET_IID(nsCycleCollectionISupports),
946                           reinterpret_cast<void**>(&out));
947       return out;
948     }
949
950     static inline void

Thread 1 (Thread 0x7f2b03bcb740 (LWP 10202)):
#0  0x00007f2afd02febe in CanonicalizeXPCOMParticipant(nsISupports*) (aIn=0x7f2aa22178e0) at /usr/src/debug/thunderbird/mozilla/xpcom/base/nsCycleCollector.cpp:946
#1  0x00007f2afd033949 in CanonicalizeParticipant(void**, nsCycleCollectionParticipant**) (aParti=0x7ffdc9dcbcc0, aCp=0x7ffdc9dcbcc8) at /usr/src/debug/thunderbird/mozilla/xpcom/base/nsCycleCollector.cpp:961
#2  0x00007f2afd036cda in RemoveSkippableVisitor::Visit(nsPurpleBuffer&, nsPurpleBufferEntry*) (this=this@entry=0x7ffdc9dcbd18, aBuffer=..., aEntry=aEntry@entry=0x7f2af10d4a38) at /usr/src/debug/thunderbird/mozilla/xpcom/base/nsCycleCollector.cpp:2776
#3  0x00007f2afd03829c in nsPurpleBuffer::RemoveSkippable(nsCycleCollector*, bool, bool, void (*)()) (aVisitor=..., aBuffer=..., this=0x7f2af10cd0e0) at /usr/src/debug/thunderbird/mozilla/xpcom/base/nsCycleCollector.cpp:1016
#4  0x00007f2afd03829c in nsPurpleBuffer::RemoveSkippable(nsCycleCollector*, bool, bool, void (*)()) (aVisitor=..., this=0x7f2af10cd0d8) at /usr/src/debug/thunderbird/mozilla/xpcom/base/nsCycleCollector.cpp:1043
#5  0x00007f2afd03829c in nsPurpleBuffer::RemoveSkippable(nsCycleCollector*, bool, bool, void (*)()) (this=this@entry=0x7f2af10cd0d8, aCollector=aCollector@entry=0x7f2af10cd000, aRemoveChildlessNodes=aRemoveChildlessNodes@entry=false, aAsyncSnowWhiteFreeing=aAsyn
cSnowWhiteFreeing@entry=false, aCb=<optimized out>) at /usr/src/debug/thunderbird/mozilla/xpcom/base/nsCycleCollector.cpp:2799
#6  0x00007f2afd038362 in nsCycleCollector::ForgetSkippable(bool, bool) (this=0x7f2af10cd000, aRemoveChildlessNodes=aRemoveChildlessNodes@entry=false, aAsyncSnowWhiteFreeing=aAsyncSnowWhiteFreeing@entry=false) at /usr/src/debug/thunderbird/mozilla/xpcom/base/nsCycleCollector.cpp:2848
#7  0x00007f2afd0383da in nsCycleCollector_forgetSkippable(bool, bool) (aRemoveChildlessNodes=aRemoveChildlessNodes@entry=false, aAsyncSnowWhiteFreeing=<optimized out>) at /usr/src/debug/thunderbird/mozilla/xpcom/base/nsCycleCollector.cpp:4057
#8  0x00007f2afd7b98a2 in FireForgetSkippable(uint32_t, bool) (aSuspected=aSuspected@entry=200, aRemoveChildless=aRemoveChildless@entry=false) at /usr/src/debug/thunderbird/mozilla/dom/base/nsJSEnvironment.cpp:1354
#9  0x00007f2afd7c1132 in CCTimerFired(nsITimer*, void*) (aTimer=<optimized out>, aClosure=<optimized out>) at /usr/src/debug/thunderbird/mozilla/dom/base/nsJSEnvironment.cpp:1903
#10 0x00007f2afd06f252 in nsTimerImpl::Fire() (this=0x7f2aa552bbe0) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/nsTimerImpl.cpp:526
#11 0x00007f2afd067f91 in nsTimerEvent::Run() (this=0x7f2ab864c4f8) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/TimerThread.cpp:282
#12 0x00007f2afd06960e in nsThread::ProcessNextEvent(bool, bool*) (this=0x7f2b027c9fc0, aMayWait=<optimized out>, aResult=0x7ffdc9dcbf3f) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/nsThread.cpp:972
#13 0x00007f2afd082dba in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aMayWait=aMayWait@entry=true) at /usr/src/debug/thunderbird/mozilla/xpcom/glue/nsThreadUtils.cpp:297
#14 0x00007f2afd25190d in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7f2af109f880, aDelegate=0x7f2b027ea330) at /usr/src/debug/thunderbird/mozilla/ipc/glue/MessagePump.cpp:127
#15 0x00007f2afd23de14 in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:227
#16 0x00007f2afd23de14 in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:201
#17 0x00007f2afe13b9ed in nsBaseAppShell::Run() (this=0x7f2adf42f0a0) at /usr/src/debug/thunderbird/mozilla/widget/nsBaseAppShell.cpp:156
Crashes also with all plugins and extensions disabled.

Thread 1 "thunderbird-bin" received signal SIGSEGV, Segmentation fault.
0x00007f1e4094bd35 in nsImapMailFolder::ParseMsgHdrs (this=0x7f1dfd037400, aProtocol=0x7f1de492b800, aHdrXferInfo=0x7f1dccb664c0) at /usr/src/debug/thunderbird/mailnews/imap/src/nsImapMailFolder.cpp:2928
2928      nsresult rv = aHdrXferInfo->GetNumHeaders(&numHdrs);
Tue May 24 09:19:01 UTC 2016
2923      nsCOMPtr <nsIImapUrl> aImapUrl;
2924      nsImapAction imapAction = nsIImapUrl::nsImapTest; // unused value.
2925      if (!mDatabase)
2926        GetDatabase();
2927
2928      nsresult rv = aHdrXferInfo->GetNumHeaders(&numHdrs);
2929      if (aProtocol)
2930      {
2931        (void) aProtocol->GetRunningImapURL(getter_AddRefs(aImapUrl));
2932        if (aImapUrl)

Thread 1 (Thread 0x7f1e47570740 (LWP 22692)):
#0  0x00007f1e4094bd35 in nsImapMailFolder::ParseMsgHdrs(nsIImapProtocol*, nsIImapHeaderXferInfo*) (this=0x7f1dfd037400, aProtocol=0x7f1de492b800, aHdrXferInfo=0x7f1dccb664c0) at /usr/src/debug/thunderbird/mailnews/imap/src/nsImapMailFolder.cpp:2928
#1  0x00007f1e4098c776 in (anonymous namespace)::SyncRunnable2<nsIImapMailFolderSink, nsIImapProtocol*, nsIImapHeaderXferInfo*>::Run() (this=0x7f1dfd0d91c0) at /usr/src/debug/thunderbird/mailnews/imap/src/nsSyncRunnableHelpers.cpp:146
#2  0x00007f1e40a6960e in nsThread::ProcessNextEvent(bool, bool*) (this=0x7f1e461c9fc0, aMayWait=<optimized out>, aResult=0x7fff12dad03f) at /usr/src/debug/thunderbird/mozilla/xpcom/threads/nsThread.cpp:972
#3  0x00007f1e40a82dba in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aMayWait=aMayWait@entry=false) at /usr/src/debug/thunderbird/mozilla/xpcom/glue/nsThreadUtils.cpp:297
#4  0x00007f1e40c518be in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7f1e34a9f880, aDelegate=0x7f1e461ea330) at /usr/src/debug/thunderbird/mozilla/ipc/glue/MessagePump.cpp:95
#5  0x00007f1e40c3de14 in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:227
#6  0x00007f1e40c3de14 in MessageLoop::Run() (this=<optimized out>) at /usr/src/debug/thunderbird/mozilla/ipc/chromium/src/base/message_loop.cc:201
#7  0x00007f1e41b3b9ed in nsBaseAppShell::Run() (this=0x7f1e22d30100) at /usr/src/debug/thunderbird/mozilla/widget/nsBaseAppShell.cpp:156
#8  0x00007f1e420b42ad in nsAppStartup::Run() (this=0x7f1e22d316a0) at /usr/src/debug/thunderbird/mozilla/toolkit/components/startup/nsAppStartup.cpp:281
#9  0x00007f1e420e6bb8 in XREMain::XRE_mainRun() (this=this@entry=0x7fff12dad2b8) at /usr/src/debug/thunderbird/mozilla/toolkit/xre/nsAppRunner.cpp:4285
#10 0x00007f1e420e6e63 in XREMain::XRE_main(int, char**, nsXREAppData const*) (this=this@entry=0x7fff12dad2b8, argc=argc@entry=1, argv=argv@entry=0x7fff12dae7a8, aAppData=aAppData@entry=0x7fff12dad4b8) at /usr/src/debug/thunderbird/mozilla/toolkit/xre/nsAppRunner.cpp:4382
#11 0x00007f1e420e7094 in XRE_main(int, char**, nsXREAppData const*, uint32_t) (argc=1, argv=0x7fff12dae7a8, aAppData=0x7fff12dad4b8, aFlags=<optimized out>) at /usr/src/debug/thunderbird/mozilla/toolkit/xre/nsAppRunner.cpp:4484
#12 0x0000000000405468 in do_main(int, char**, nsIFile*) (argc=argc@entry=1, argv=argv@entry=0x7fff12dae7a8, xreDirectory=0x7f1e46149a80) at /usr/src/debug/thunderbird/mail/app/nsMailApp.cpp:195
#13 0x0000000000404c32 in main(int, char**) (argc=1, argv=0x7fff12dae7a8) at /usr/src/debug/thunderbird/mail/app/nsMailApp.cpp:332
This time something put garbage into a DOMString.

Thread 1 "thunderbird-bin" received signal SIGSEGV, Segmentation fault.
0x00007f2c49c2a8b7 in std::__atomic_base<int>::fetch_add (__m=std::memory_order_seq_cst, __i=1, this=this@entry=0x7f2b6d6f6326) at /usr/include/c++/5/bits/atomic_base.h:514
514           { return __atomic_fetch_add(&_M_i, __i, __m); }
Tue May 24 19:56:13 UTC 2016
509           }
510
511           _GLIBCXX_ALWAYS_INLINE __int_type
512           fetch_add(__int_type __i,
513                     memory_order __m = memory_order_seq_cst) noexcept
514           { return __atomic_fetch_add(&_M_i, __i, __m); }
515
516           _GLIBCXX_ALWAYS_INLINE __int_type
517           fetch_add(__int_type __i,
518                     memory_order __m = memory_order_seq_cst) volatile noexcept

Thread 1 (Thread 0x7f2c50803740 (LWP 4118)):
#0  0x00007f2c49c2a8b7 in mozilla::detail::AtomicBaseIncDec<int, (mozilla::MemoryOrdering)2>::operator++() (__m=std::memory_order_seq_cst, __i=1, this=this@entry=0x7f2b6d6f6326) at /usr/include/c++/5/bits/atomic_base.h:514
#1  0x00007f2c49c2a8b7 in mozilla::detail::AtomicBaseIncDec<int, (mozilla::MemoryOrdering)2>::operator++() (aVal=1, aPtr=...) at ../../dist/include/mozilla/Atomics.h:254
#2  0x00007f2c49c2a8b7 in mozilla::detail::AtomicBaseIncDec<int, (mozilla::MemoryOrdering)2>::operator++() (aPtr=...) at ../../dist/include/mozilla/Atomics.h:286
#3  0x00007f2c49c2a8b7 in mozilla::detail::AtomicBaseIncDec<int, (mozilla::MemoryOrdering)2>::operator++() (this=this@entry=0x7f2b6d6f6326) at ../../dist/include/mozilla/Atomics.h:609
#4  0x00007f2c49c2a8e8 in nsStringBuffer::ToString(unsigned int, nsAString_internal&, bool) (this=0x7f2b6d6f6326) at /usr/src/debug/thunderbird/mozilla/xpcom/string/nsSubstring.cpp:189
#5  0x00007f2c49c2a8e8 in nsStringBuffer::ToString(unsigned int, nsAString_internal&, bool) (this=0x7f2b6d6f6326, aLen=1869622881, aStr=..., aMoveOwnership=aMoveOwnership@entry=false) at /usr/src/debug/thunderbird/mozilla/xpcom/string/nsSubstring.cpp:295
#6  0x00007f2c4a3346aa in mozilla::dom::Element::GetAttr(int, nsIAtom*, nsAString_internal&) const (aString=..., this=0x7ffecf30fe70) at ../../dist/include/mozilla/dom/DOMString.h:171
#7  0x00007f2c4a3346aa in mozilla::dom::Element::GetAttr(int, nsIAtom*, nsAString_internal&) const (this=this@entry=0x7f2be4f9b280, aNameSpaceID=aNameSpaceID@entry=0, aName=aName@entry=0x7f2c33a25ea0, aResult=...) at /usr/src/debug/thunderbird/mozilla/dom/base/El
ement.cpp:2549
#8  0x00007f2c4a3371b9 in nsIContent::GetAttr(int, nsIAtom*, nsAString_internal&) const (this=this@entry=0x7f2be4f9b280, aNameSpaceID=aNameSpaceID@entry=0, aName=aName@entry=0x7f2c33a25ea0, aResult=...) at /usr/src/debug/thunderbird/mozilla/dom/base/FragmentOrEle
ment.cpp:910
#9  0x00007f2c4afd42a6 in nsSliderFrame::GetIntegerAttribute(nsIContent*, nsIAtom*, int) (content=0x7f2be4f9b280, atom=0x7f2c33a25ea0, defaultValue=defaultValue@entry=10) at /usr/src/debug/thunderbird/mozilla/layout/xul/nsSliderFrame.cpp:172
#10 0x00007f2c4afd4413 in nsSliderFrame::GetPageIncrement(nsIContent*) (content=<optimized out>) at /usr/src/debug/thunderbird/mozilla/layout/xul/nsSliderFrame.cpp:165
#11 0x00007f2c4afd931e in nsSliderFrame::DoLayout(nsBoxLayoutState&) (this=0x7f2be531ee20, aState=...) at /usr/src/debug/thunderbird/mozilla/layout/xul/nsSliderFrame.cpp:414
#12 0x00007f2c4afc8845 in nsIFrame::Layout(nsBoxLayoutState&) (this=this@entry=0x7f2be531ee20, aState=...) at /usr/src/debug/thunderbird/mozilla/layout/xul/nsBox.cpp:509
#13 0x00007f2c4afe3bf7 in nsSprocketLayout::Layout(nsIFrame*, nsBoxLayoutState&) (this=this@entry=0x7f2c0ba402c0, aBox=0x7f2be531e620, aState=...) at /usr/src/debug/thunderbird/mozilla/layout/xul/nsSprocketLayout.cpp:484
#14 0x00007f2c4afe4113 in nsSprocketLayout::Layout(nsIFrame*, nsBoxLayoutState&) (this=0x7f2c0ba402c0, aBox=0x7f2be531e620, aState=...) at /usr/src/debug/thunderbird/mozilla/layout/xul/nsSprocketLayout.cpp:177
#15 0x00007f2c4afc7749 in nsBoxFrame::DoLayout(nsBoxLayoutState&) (this=0x7f2be531e620, aState=...) at /usr/src/debug/thunderbird/mozilla/layout/xul/nsBoxFrame.cpp:911
#16 0x00007f2c4afc8845 in nsIFrame::Layout(nsBoxLayoutState&) (this=0x7f2be531e620, aState=...) at /usr/src/debug/thunderbird/mozilla/layout/xul/nsBox.cpp:509
#17 0x00007f2c4afc8d1d in nsBoxFrame::LayoutChildAt(nsBoxLayoutState&, nsIFrame*, nsRect const&) (aState=..., aBox=<optimized out>, aRect=...) at /usr/src/debug/thunderbird/mozilla/layout/xul/nsBoxFrame.cpp:1936
Attachment #8701589 - Attachment filename: bug1203977_use_after_free_crash.patch → [checked in] bug1203977_use_after_free_crash.patch
Assignee: mkmelin+mozilla → nobody
Attachment #8701589 - Attachment description: bug1203977_use_after_free_crash.patch → bug1203977_use_after_free_crash.patch [checked in, comment #33]
Attachment #8701589 - Attachment filename: [checked in] bug1203977_use_after_free_crash.patch → bug1203977_use_after_free_crash.patch
(In reply to Magnus Melin from comment #33 2016-01-01)
> https://hg.mozilla.org/comm-central/rev/7748cfb2e1be -> FIXED

Hard to judge becuase the crash rate was (and still is) so low, but this patch seems to have made no impact on signature of nsImapMailFolder::ParseMsgHdr according to the graph
https://crash-stats.mozilla.com/signature/?product=Thunderbird&date=%3E2015-12-01&signature=nsImapMailFolder%3A%3AParseMsgHdrs&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_sort=-date&page=1#graphs
I'm running it like this, and no crashes anymore.

env TMPDIR=/dev/shm G_SLICE=always-malloc NSPR_LOG_MODULES=imap:5,smtp:5,msgdb:5,gssapi:5,negotiateauth:5,msgpurge:5,,timestamp,sync NSPR_LOG_FILE=/dev/null thunderbird

Since there is nothing more todo on my side, closing.
Status: REOPENED → RESOLVED
Closed: 4 years ago3 years ago
Resolution: --- → WORKSFORME
Thanks for the update. Yes, this hijacked your issue. So if you have an issue in the future please file a new bug report.

This has a patch, so changing resolution to FIXED.
Resolution: WORKSFORME → FIXED
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #91)
> Thanks for the update. Yes, this hijacked your issue. So if you have an
> issue in the future please file a new bug report.
> 
> This has a patch, so changing resolution to FIXED.

This patch serves no purpose for the reported (and still unfixed) memory corruption.
> This patch serves no purpose for the reported (and still unfixed) memory corruption.

Reopening this because the patch made no detectable improvement overall, and olaf says, his problem remains. And filing a new bug would lose the context contained in this bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Thunderbird crashes due to use-after-free or pointer corruption → Thunderbird crashes due to use-after-free or pointer corruption (Linux,Mac)
olaf and Wayne, we should separate bugs per issue.  "use-after-free" is too generic issue.  Some issue isn't MailNews Core.
(In reply to Makoto Kato [:m_kato] from comment #94)
> olaf and Wayne, we should separate bugs per issue.  "use-after-free" is too
> generic issue.  Some issue isn't MailNews Core.

True. 

Before doing that, I'd like to see more reproducible, and/or crashes with patches land - where work has already been done, so we don't do double work - unless these crashes have a obvious path to being fixed.  IMO we should revisit this in a couple months.
Flags: needinfo?(vseerror)
One data point: doing strace with mutt shows a read() (or was it write?) to the socket took 16 seconds. All this for mutts 'c' command in pager. It simply means the server appearently "hangs" the client. Eventually TB runs into some timeout, one thread moves on while another one still processes the "hanging" connection. Once I find the time and energy to debug mutt to see what IMAP communication is going on and what part of it is that slow I will post the results.
... and the result for command from comment#90 remains true.
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #95)
> Before doing that, I'd like to see more reproducible, and/or crashes with
> patches land - where work has already been done, so we don't do double work
> - unless these crashes have a obvious path to being fixed.  IMO we should
> revisit this in a couple months.

To be more clear, what I mean is we have potential in other bugs which either have a patch, have developer comments, or may be reproducible. And, version 45 is not ideal to be testing on when when have much newer code in 52 beta and nightly.
Flags: needinfo?(vseerror)
Olaf, can you try version 54 or newer?  
http://www.mozilla.org/en-US/thunderbird/channel/

Ref fixed bug 1310467
Flags: needinfo?(olaf)
In October, Olaf wrote he hasn't been using Thunderbird for several months.

Remanining crashes are somehwat rare, about 20 in a month.  All have SyncRunnable2 on stack as previous. None of the crshes have contacts or comments
Flags: needinfo?(olaf)
Keywords: crash
Whiteboard: [revisit 2018-04-01]
Given comment 100 and there being no lack of other imap crash reports https://mzl.la/2NGq15d, I'd say this is likely covered in other bug reports, so => incomplete

Other viewpoints welcome
Status: REOPENED → RESOLVED
Closed: 3 years agoLast year
Resolution: --- → INCOMPLETE
Hmm, I forgot we had a checkin comment 33.  But we no longer have Olaf to reproduce.

Magnus, what would you like to do, keep this open?
Flags: needinfo?(mkmelin+mozilla)
No, seems better to file a new bug if someone can reproduce
Flags: needinfo?(mkmelin+mozilla)
Changing to FIXED because this bug has a patch, even if it didn't fix the reporter's issue
Resolution: INCOMPLETE → FIXED
You need to log in before you can comment on or make changes to this bug.