On Tue, Aug 28, 2018 at 10:24:24PM +0200, Torbjörn Andersson wrote:
> On 2018-08-28 20:48, Carsten Schoenert wrote:
> > Yes, the line gdb is showing were thunderbird is crashing is the
> > interesting part, I'm sure this will show us an upstream issue. I see
> > a small possibility that gcc8 might be the root for this crash. But
> > then I also expect we would see a lot more bug reports related to
> > thunderbird crashes.
>
> I was going to bed, but I figured a hasty reply now might still be more
> useful than a more carefully written reply in eight hours or so. :-)
>
> Here's the start of the backtrace I got from gdb. I hope that provides
> enough context:
>
> #0 0x00007f22828eb9b0 in
> mozilla::detail::nsTStringRepr<char16_t>::First()const
> (this=this@entry=0x7fff9ca7a5c0) at
> ./obj-thunderbird/dist/include/mozilla/Assertions.h:40
> #1 0x00007f22828182a2 in
> nsMsgLocalStoreUtils::nsShouldIgnoreFile(nsTSubstring<char16_t>&) (name=...)
> at ./comm/mailnews/local/src/nsMsgLocalStoreUtils.cpp:31
> #2 0x00007f228281676c in nsMsgBrkMBoxStore::AddSubFolders(nsIMsgFolder*,
> nsCOMPtr<nsIFile>&, bool) (this=0x7f225ea661f0, parent=0x7f226cf24438,
> path=..., deep=true) at ./comm/mailnews/local/src/nsMsgBrkMBoxStore.cpp:1063
> #3 0x00007f2282816ad8 in
> nsMsgBrkMBoxStore::DiscoverSubFolders(nsIMsgFolder*, bool)
> (this=0x7f225ea661f0, aParentFolder=0x7f226cf24438, aDeep=<optimized out>) at
> ./comm/mailnews/local/src/nsMsgBrkMBoxStore.cpp:69
> #4 0x00007f22827fd29e in
> nsMsgLocalMailFolder::GetSubFolders(nsISimpleEnumerator**)
> (this=this@entry=0x7f226cf24400, aResult=0x7fff9ca7a770) at
> ./obj-thunderbird/dist/include/nsCOMPtr.h:798
> #5 0x00007f2282687c7b in nsMsgDBFolder::ListFoldersWithFlags(unsigned int,
> nsIMutableArray*) (this=0x7f226cf24400, aFlags=4096, aFolders=0x7f225edffbe0)
> at ./obj-thunderbird/dist/include/nsCOMPtr.h:1367
>
> I tried printing the 'name' parameter from nsShouldIgnoreFile(), but I don't
> know if it's at all helpful:
>
> (gdb) print name
> $2 = (nsAString &) @0x7fff9ca7a5c0:
> {<mozilla::detail::nsTStringRepr<char16_t>> = {mData = 0x7f2285e2be84
> <gNullChar> u"", mLength = 0,
> mDataFlags = mozilla::detail::StringDataFlags::TERMINATED,
> mClassFlags = (mozilla::detail::StringClassFlags::INLINE |
> mozilla::detail::StringClassFlags::NULL_TERMINATED)}, static kMaxCapacity =
> 1073741817}
My knowledge about reading GDB logs are also ne the deepest but as
thunderbird is a multithreaded application it's also good to see all
threads that are involved.
This means you "just" need to call 'thread apply all bt' on the GDB
console.
Have a look for more detailed information about GDB debugging by viewing
onto the old Icedove related wiki site. (Note: the GDB starting call has
changed in between times)
https://wiki.debian.org/Icedove#Starting_Debugging
Unfortunately we did get no feedback from the original reporter so see
if there is also POP used to get the emails from the server. If yes it
looks like there is something broken in the upstream code for getting
messages by the POP protocol.
You could also try out the latest beta version from upstream, which is
the current base for the next Thunderbird long term version to see if
your setup is working there.
http://ftp.mozilla.org/pub/thunderbird/releases/60.0b11/linux-x86_64/
or
http://ftp.mozilla.org/pub/thunderbird/releases/60.0b11/linux-i686/
Any special need to use POP anyway? The defacto standard is now IMAP,
and there is also the possibility to move (not copy) emails after
fetching into local folders. This is in the end the same as using POP.
I'm quite sure this all is not Debian fault but if we forward this to
upstream they need clear information how to reproduce and how the logs
look like. But I'm also sure the motivation from upstream will be small
to look into a more or less deprecated protocol for fetching emails from
the server.
