Hi there,

I got a segfault while switching mail folders.

Reading symbols from /usr/bin/icedove...Reading symbols from /usr/lib/debug//usr/lib/icedove/icedove...done.
done.
[New LWP 2540]
[New LWP 2544]
[New LWP 2543]
[New LWP 2556]
[New LWP 2561]
[New LWP 2569]
[New LWP 2545]
[New LWP 2547]
[New LWP 2564]
[New LWP 2594]
[New LWP 2560]
[New LWP 2548]
[New LWP 2570]
[New LWP 2598]
[New LWP 2549]
[New LWP 2577]
[New LWP 2563]
[New LWP 2603]
[New LWP 2550]
[New LWP 2566]
[New LWP 2620]
[New LWP 2651]
[New LWP 2551]
[New LWP 2568]
[New LWP 2565]
[New LWP 2552]
[New LWP 2578]
[New LWP 2553]
[New LWP 2588]
[New LWP 2589]
[New LWP 2590]
[New LWP 2622]
[New LWP 2571]
[New LWP 2649]
[New LWP 2554]
[New LWP 2546]
[New LWP 2623]
[New LWP 2555]
[New LWP 2621]
[New LWP 2599]
[New LWP 2557]
[New LWP 2596]
[New LWP 2558]
[New LWP 2592]
[New LWP 2559]
[New LWP 2573]
[New LWP 2572]
[New LWP 2567]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `icedove'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fda3ac2279b in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
37	../nptl/sysdeps/unix/sysv/linux/pt-raise.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x00007fda3ac2279b in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1  0x00007fda35295959 in nsProfileLock::FatalSignalHandler (signo=11, info=0x7ffd62d8ab70, context=0x7ffd62d8aa40)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/toolkit/profile/nsProfileLock.cpp:185
#2  0x00007fda35b72586 in AsmJSFaultHandler (signum=<optimized out>, info=<optimized out>, context=0x7ffd62d8aa40)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/js/src/asmjs/AsmJSSignalHandlers.cpp:1161
#3  <signal handler called>
#4  0x00007fd9fd9df178 in ?? ()
#5  0x00007fda34dff6a5 in nsDisplayList::DeleteAll (this=this@entry=0x7fd9fd9df220) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/layout/base/nsDisplayList.cpp:1816
#6  0x00007fda34e109f2 in nsDisplayWrapList::~nsDisplayWrapList (this=0x7fd9fd9df1d8, __in_chrg=<optimized out>)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/layout/base/nsDisplayList.cpp:3773
#7  0x00007fda34dff6a5 in nsDisplayList::DeleteAll (this=0x7ffd62d8b118) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/layout/base/nsDisplayList.cpp:1816
#8  0x00007fda34e555ce in nsLayoutUtils::PaintFrame (aRenderingContext=0x7fd9fd9df180, aRenderingContext@entry=0x0, aFrame=0x7fda16380ff0, aDirtyRegion=...,
    aBackstop=0, aBackstop@entry=4294440951, aFlags=1658368320) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/layout/base/nsLayoutUtils.cpp:3477
#9  0x00007fda34e5a47d in PresShell::Paint (this=0x7fda163c1000, aViewToPaint=aViewToPaint@entry=0x7fda1637b900, aDirtyRegion=..., aFlags=aFlags@entry=1)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/layout/base/nsPresShell.cpp:6105
#10 0x00007fda34c7c884 in nsViewManager::ProcessPendingUpdatesPaint (this=0x7fda1637f6c0, aWidget=aWidget@entry=0x7fda39cf6ab0)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/view/nsViewManager.cpp:467
#11 0x00007fda34c7ca33 in nsViewManager::ProcessPendingUpdatesForView (this=<optimized out>, aView=<optimized out>, aFlushDirtyRegion=aFlushDirtyRegion@entry=true)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/view/nsViewManager.cpp:398
#12 0x00007fda34c7cae3 in nsViewManager::ProcessPendingUpdates (this=this@entry=0x7fda1637f6c0)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/view/nsViewManager.cpp:1101
#13 0x00007fda34dd55a4 in nsRefreshDriver::Tick (this=0x7fda163c0c00, aNowEpoch=aNowEpoch@entry=1465913598009296, aNowTime=...)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/layout/base/nsRefreshDriver.cpp:1857
#14 0x00007fda34dd5884 in mozilla::RefreshDriverTimer::TickDriver (driver=<optimized out>, jsnow=jsnow@entry=1465913598009296, now=..., now@entry=...)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/layout/base/nsRefreshDriver.cpp:264
#15 0x00007fda34dd59b1 in mozilla::RefreshDriverTimer::TickRefreshDrivers (aJsNow=aJsNow@entry=1465913598009296, aNow=aNow@entry=..., aDrivers=...,
    this=0x7fda1a586100) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/layout/base/nsRefreshDriver.cpp:236
#16 0x00007fda34dd5a59 in mozilla::RefreshDriverTimer::Tick (this=0x7fda1a586100, jsnow=1465913598009296, now=...)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/layout/base/nsRefreshDriver.cpp:255
#17 0x00007fda34dd5b74 in RunRefreshDrivers (aTimeStamp=..., this=0x7fda1a586100) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/layout/base/nsRefreshDriver.cpp:566
#18 mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver (this=<optimized out>, aVsyncTimestamp=...)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/layout/base/nsRefreshDriver.cpp:486
#19 0x00007fda34dd01be in apply<mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver, void (mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::*)(mozilla::TimeStamp)> (m=<optimized out>, o=<optimized out>, this=<optimized out>) at ../../dist/include/nsThreadUtils.h:676
#20 nsRunnableMethodImpl<void (mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::*)(mozilla::TimeStamp), true, mozilla::TimeStamp>::Run (
    this=<optimized out>) at ../../dist/include/nsThreadUtils.h:870
#21 0x00007fda33a542b0 in nsThread::ProcessNextEvent (this=0x7fda39c65870, aMayWait=<optimized out>, aResult=0x7ffd62d8be87)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/xpcom/threads/nsThread.cpp:972
#22 0x00007fda33a6e9e1 in NS_ProcessNextEvent (aThread=<optimized out>, aMayWait=aMayWait@entry=false)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/xpcom/glue/nsThreadUtils.cpp:297
#23 0x00007fda33c4e791 in mozilla::ipc::MessagePump::Run (this=0x7fda39cdf9c0, aDelegate=0x7fda2a2041c0)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/ipc/glue/MessagePump.cpp:95
#24 0x00007fda33c3ecdb in RunHandler (this=0x7fda2a2041c0) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/ipc/chromium/src/base/message_loop.cc:227
#25 MessageLoop::Run (this=0x7fda2a2041c0) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/ipc/chromium/src/base/message_loop.cc:201
#26 0x00007fda34c8eaca in nsBaseAppShell::Run (this=0x7fd9fd9df180) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/widget/nsBaseAppShell.cpp:156
#27 0x00007fda35267a0d in nsAppStartup::Run (this=0x7fda24141880) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/toolkit/components/startup/nsAppStartup.cpp:281
#28 0x00007fda3529c79e in XREMain::XRE_mainRun (this=this@entry=0x7ffd62d8c128) at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/toolkit/xre/nsAppRunner.cpp:4285
#29 0x00007fda3529ca52 in XREMain::XRE_main (this=this@entry=0x7ffd62d8c128, argc=argc@entry=1, argv=argv@entry=0x7ffd62d8d628, aAppData=aAppData@entry=0x7ffd62d8c328)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/toolkit/xre/nsAppRunner.cpp:4382
#30 0x00007fda3529cc6d in XRE_main (argc=1, argv=0x7ffd62d8d628, aAppData=0x7ffd62d8c328, aFlags=<optimized out>)
    at /build/icedove-tNL3mB/icedove-45.1.0/mozilla/toolkit/xre/nsAppRunner.cpp:4484
#31 0x0000000000404c37 in do_main (argc=argc@entry=1, argv=argv@entry=0x7ffd62d8d628, xreDirectory=0x7fda39c3a9c0)
    at /build/icedove-tNL3mB/icedove-45.1.0/mail/app/nsMailApp.cpp:195
#32 0x00000000004043b7 in main (argc=1, argv=0x7ffd62d8d628) at /build/icedove-tNL3mB/icedove-45.1.0/mail/app/nsMailApp.cpp:332
(gdb) quit

Please let me know if I can contribute some more details about the crash.

Best regards,
Micha

Hello Micha,
[SNIP]

please follow the instruction from
https://wiki.debian.org/Icedove#Debugging completely.

The log you have send is unfortunately useless because the other threads
are not visible. Please unset the LANG so we got a english output, not
all the readers here are native german. That's all done by the example on
thw wiki site.

Also if possible consider using "set substitute-path ..." inside the gdb
session to a valide path. By this all can see the relvant source code
there Icedove is crashing.

https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html

Regards
Carsten

Unfortunately a second crash overwrote the first crash's core dump.

Attached is the backtrace from the second crash. Please let me know if
you need any additional information.

Best regards,
Micha

Hi Carsten,

Am 14.06.2016 um 16:44 schrieb Carsten Schoenert:

Well, I am not able to reproduce the issue reliably. So, what I did is a
post-mortem analysis of the generated coredump. So I guess I can't
change the LANG env, right?

Of course I can re-run gdb to generate a backtrace for all threads.
Would that help?

This is the icedove version installed in a stable release via APT, so I
have no clue what path to set here. I guess the Debian buildds know the
used paths. The used source code should be available in the Debian
archive, shouldn't it?

Best regards,
Micha

Hi Carsten,

the crash just succeeded again following the instructions given in the
Debian Wiki. Attached you find the generated log file.

Best regards,
Micha

Yet another coredump succeeded (see attached log file). This time I
remembered to let GDB generate a core dump file too. Please let me know
if you need further information.

Best regards,
Micha

Hello Micha,

those logs are much better as we cann see all the threads that are
running. I'm a little bit puzzled about the name of the log file and the
version on the other side that's visible in the log ...

On Tue, Jun 14, 2016 at 05:19:12PM +0200, Micha Lenk wrote:
[SNIP]

[SNIP]

That's originaly this function in line 1816

$ head -n 1819 mozilla/layout/base/nsDisplayList.cpp | tail -n8

void nsDisplayList::DeleteAll() {
  nsDisplayItem* item;
  while ((item = RemoveBottom()) != nullptr) {   <------------
    item->~nsDisplayItem();
  }
}

It looks like a Nullpointer exception but that needs a deeper code
inspection and my assumption can be wrong.

The cordump file isn't very helpful for us, so thanks, we don't need
that.

We have quite a lot of crash reports over the paste years, unfortunately
we have really not enough free time to dig into this issues deeply. And
we can't reproduce them, that makes it difficult to solve the real
problem. And sometime (or I expect most of the reports) are related to
addons that use the libxul interface. So it's even more complicated to
read the needed information from a gdb log, so sadly expect not to much.

The last time I remember there we was able to reproduce a crash was
depended to the xul-ext-foxyproxy-standard extension. But we couldn't
find the origin of the crash.

Regards
Carsten

Hello Micha,

that's exact our problem, I run into Icedove crashs too, but they are
really rare. Maybe 1 - 2 a month, and there are months thre nothing
happen.

Yes, only manually in the log file, and that's error prone. :-)

Well, that's something for advanced gdb using, so no worry.

The gdb trys to find the source like it was around while building. For the
version 1:45.1.0~deb8u1 the buildd was using

  /build/icedove-tNL3mB/icedove-45.1.0/

Of course you dont have such a folder, so gdb cant find the source for
the crashed function. You need to tell gdb a substion path (if you have
downloaded and extracted the source for Icedove locally).
For example, if have loaded the source from the package site
https://packages.debian.org/source/stable/icedove on the bottom ...
icedove_45.1.0.orig.tar.xz

http://security.debian.org/debian-security/pool/updates/main/i/icedove/icedove_45.1.0.orig.tar.xz

and extracted the archive into /home/user/icedove-source-45.1.0 than the
substion comand would be:

[start the debugger]
set substitute-path /build/icedove-tNL3mB/icedove-45.1.0/ /home/user/icedove-source-45.1.0
run
[the visible output]

Regards
Carsten

Hi Carsten,

one more debug protocol with a similar backtrace of the crashing thread.

By the way: the strange log file names are caused by the algorithm which
creates that names.
$(apt-cache show icedove) does not show the installed icedove versions,
but all versions found
in the apt cache. This can be the same version, but the cache can also
contain newer versions
(even more than one which will confuse the log file name completely).

Regards
Stefan

Hello Stefan,

tanks for the other gdb log.

Am 25.07.2016 um 20:33 schrieb Stefan Weil:
[SNIP]

well, I don’t think the log names are strange, they contain all the
information we need to keep the reports differ.
But you are right on the version that can be wrong selected, I changed
the wiki entry slightly to use dpkg-query.

Here is a new debug protocol from icedove 1:45.2.0-2+b1.
Icedove was run in safe mode without any extensions.

Could it be that the crashing code is operating with data which is invalid
because it was freed by another thread?

Stefan

I keep getting these crashes. It happens either when I switch IMAP mail
folders or when I switch messages in the message list:

(gdb) bt
#0  0x00007ffff49fc590 in vtable for nsDisplayThemedBackground () from
/usr/lib/icedove/libxul.so
#1  0x00007ffff1ce40cb in nsDisplayList::DeleteAll (this=0x7fffffffbda8)
at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/layout/base/nsDisplayList.cpp:1816
#2  0x00007ffff1d39ff4 in nsLayoutUtils::PaintFrame
(aRenderingContext=0x7fffcabb0978, aRenderingContext@entry=0x0,
aFrame=0x7fffcbb68c00, aDirtyRegion=..., aBackstop=0,
aBackstop@entry=4294967295, aFlags=4294950352)
     at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/layout/base/nsLayoutUtils.cpp:3477
#3  0x00007ffff1d3eea3 in PresShell::Paint (this=0x7fffcc07a800,
aViewToPaint=aViewToPaint@entry=0x7fffcbb58a80, aDirtyRegion=...,
aFlags=aFlags@entry=1) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/layout/base/nsPresShell.cpp:6105
#4  0x00007ffff1b61177 in nsViewManager::ProcessPendingUpdatesPaint
(this=0x7fffcd861a40, aWidget=aWidget@entry=0x7ffff6be73f0) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/view/nsViewManager.cpp:467
#5  0x00007ffff1b6134b in nsViewManager::ProcessPendingUpdatesForView
(this=this@entry=0x7fffcd861a40, aView=<optimized out>,
aFlushDirtyRegion=aFlushDirtyRegion@entry=true) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/view/nsViewManager.cpp:398
#6  0x00007ffff1b61417 in nsViewManager::ProcessPendingUpdates
(this=this@entry=0x7fffcd861a40) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/view/nsViewManager.cpp:1103
#7  0x00007ffff1cb9fc8 in nsRefreshDriver::Tick (this=0x7fffcc078c00,
aNowEpoch=aNowEpoch@entry=1474881640193136, aNowTime=...) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/layout/base/nsRefreshDriver.cpp:1857
#8  0x00007ffff1cba2a8 in mozilla::RefreshDriverTimer::TickDriver
(driver=<optimized out>, jsnow=jsnow@entry=1474881640193136, now=...,
now@entry=...) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/layout/base/nsRefreshDriver.cpp:264
#9  0x00007ffff1cba3d5 in
mozilla::RefreshDriverTimer::TickRefreshDrivers
(aJsNow=aJsNow@entry=1474881640193136, aNow=aNow@entry=...,
aDrivers=..., this=0x7fffd63644c0) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/layout/base/nsRefreshDriver.cpp:236
#10 0x00007ffff1cba47d in mozilla::RefreshDriverTimer::Tick
(this=0x7fffd63644c0, jsnow=1474881640193136, now=...) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/layout/base/nsRefreshDriver.cpp:255
#11 0x00007ffff1cba598 in RunRefreshDrivers (aTimeStamp=...,
this=0x7fffd63644c0) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/layout/base/nsRefreshDriver.cpp:566
#12
mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver
(this=<optimized out>, aVsyncTimestamp=...) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/layout/base/nsRefreshDriver.cpp:486
#13 0x00007ffff1cb4be2 in
apply<mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver, void
(mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::*)(mozilla::TimeStamp)>
(m=<optimized out>, o=<optimized out>, this=<optimized out>)
     at ../../dist/include/nsThreadUtils.h:676
#14 nsRunnableMethodImpl<void
(mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::*)(mozilla::TimeStamp),
true, mozilla::TimeStamp>::Run (this=<optimized out>) at
../../dist/include/nsThreadUtils.h:870
#15 0x00007ffff0937f58 in nsThread::ProcessNextEvent
(this=0x7ffff6b657a0, aMayWait=<optimized out>, aResult=0x7fffffffcb37)
at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/xpcom/threads/nsThread.cpp:972
#16 0x00007ffff0952689 in NS_ProcessNextEvent (aThread=<optimized out>,
aMayWait=aMayWait@entry=false) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/xpcom/glue/nsThreadUtils.cpp:297
#17 0x00007ffff0b32b27 in mozilla::ipc::MessagePump::Run
(this=0x7ffff6bcd940, aDelegate=0x7fffe73166a0) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/ipc/glue/MessagePump.cpp:95
#18 0x00007ffff0b23071 in RunHandler (this=0x7fffe73166a0) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/ipc/chromium/src/base/message_loop.cc:227
#19 MessageLoop::Run (this=0x7fffe73166a0) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/ipc/chromium/src/base/message_loop.cc:201
#20 0x00007ffff1b73498 in nsBaseAppShell::Run (this=0x7fffcabb0978) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/widget/nsBaseAppShell.cpp:156
#21 0x00007ffff214c4f7 in nsAppStartup::Run (this=0x7fffdc81bf10) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/toolkit/components/startup/nsAppStartup.cpp:281
#22 0x00007ffff218128a in XREMain::XRE_mainRun
(this=this@entry=0x7fffffffcdd8) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/toolkit/xre/nsAppRunner.cpp:4285
#23 0x00007ffff218153e in XREMain::XRE_main
(this=this@entry=0x7fffffffcdd8, argc=argc@entry=2,
argv=argv@entry=0x7fffffffe2d8, aAppData=aAppData@entry=0x7fffffffcfd8)
at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/toolkit/xre/nsAppRunner.cpp:4382
#24 0x00007ffff2181759 in XRE_main (argc=2, argv=0x7fffffffe2d8,
aAppData=0x7fffffffcfd8, aFlags=<optimized out>) at
/build/icedove-XX30r8/icedove-45.2.0/mozilla/toolkit/xre/nsAppRunner.cpp:4484
#25 0x0000000000404c37 in do_main (argc=argc@entry=2,
argv=argv@entry=0x7fffffffe2d8, xreDirectory=0x7ffff6b3b9c0) at
/build/icedove-XX30r8/icedove-45.2.0/mail/app/nsMailApp.cpp:195
#26 0x00000000004043b7 in main (argc=2, argv=0x7fffffffe2d8) at
/build/icedove-XX30r8/icedove-45.2.0/mail/app/nsMailApp.cpp:332

What I find suspicious is the parameter aRenderingContext@entry=0x0 when
calling frame #2. Is this an expected value for that parameter?

I found a matching bug report in the upstream bug tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=1198710
I will add a few comments there now.

I have a coredump file that I can run any GDB instruction you want with.
Please let me know if I can contribute somthing to fix this issue.

Regards,
Micha