severity 848299 important usertag 848299 id-crash-45.1.0 thanks Hello Mirko, lowering down the severity as Icedove isn't completely broken or renders the package into a security whole. https://www.debian.org/Bugs/Developer#severities
On Fri, Dec 16, 2016 at 01:52:23AM +0100, Mirko Vogt wrote: [...] > One of icedove's threads randomly(TM) crashes with SIGPIPE in libc's send.c > > This can happen shortly after being started or after running for a > couple of hours. No direct trigger identified so far. Unfortunately this happen since version 45.1.0-1 in unstable/sid and jessie-security partially. Please look into similar bug reports and propose a merge within a another bug report if possible. https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=id-crash-45.1.0;users=c.schoen...@t-online.de > Output of gdb: > > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > Core was generated by `/usr/bin/icedove'. > Program terminated with signal SIGPIPE, Broken pipe. > #0 0x00007ffff7bcd65f in __libc_send (fd=67, buf=0x7fffa9834000, n=31, > flags=0) at ../sysdeps/unix/sysv/linux/x86_64/send.c:26 > 26 ../sysdeps/unix/sysv/linux/x86_64/send.c: No such file or directory. > [Current thread is 1 (Thread 0x7fffe2ffe700 (LWP 28924))] > > backtrace for this particular thread: > > (gdb) bt > #0 0x00007ffff7bcd65f in __libc_send (fd=67, buf=0x7fffa9834000, n=31, > flags=0) at ../sysdeps/unix/sysv/linux/x86_64/send.c:26 > #1 0x00007ffff5ea4e4b in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so > #2 0x00007fffeeca759a in ?? () from /usr/lib/x86_64-linux-gnu/libssl3.so > #3 0x00007fffeec9b999 in ?? () from /usr/lib/x86_64-linux-gnu/libssl3.so > #4 0x00007fffeec9d694 in ?? () from /usr/lib/x86_64-linux-gnu/libssl3.so > #5 0x00007fffeecad9fb in ?? () from /usr/lib/x86_64-linux-gnu/libssl3.so > #6 0x00007ffff3998afe in ?? () from /usr/lib/icedove/libxul.so > #7 0x00007ffff3998b86 in ?? () from /usr/lib/icedove/libxul.so > #8 0x00007ffff22d6fc0 in ?? () from /usr/lib/icedove/libxul.so > #9 0x00007ffff22db356 in ?? () from /usr/lib/icedove/libxul.so > #10 0x00007ffff22d8c50 in ?? () from /usr/lib/icedove/libxul.so > #11 0x00007ffff22d8fdc in ?? () from /usr/lib/icedove/libxul.so > #12 0x00007ffff22e0cb5 in ?? () from /usr/lib/icedove/libxul.so > #13 0x00007ffff225ea53 in ?? () from /usr/lib/icedove/libxul.so > #14 0x00007ffff2278ae9 in ?? () from /usr/lib/icedove/libxul.so > #15 0x00007ffff245be9b in ?? () from /usr/lib/icedove/libxul.so > #16 0x00007ffff244bf62 in ?? () from /usr/lib/icedove/libxul.so > #17 0x00007ffff2260742 in ?? () from /usr/lib/icedove/libxul.so > #18 0x00007ffff5ea8549 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so > #19 0x00007ffff7bc4464 in start_thread (arg=0x7fffe2ffe700) at > pthread_create.c:333 > #20 0x00007ffff6e679df in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 This looks not very helpful as the debugging symbols are missing. > Core dump exists but I'm not keen of publishing it due to included > sensitive data. I'm happy to help debugging though. The Icedove Wiki page contains information for creating good GDB logs, please have a look. Core dumps are not that helpful at all as we don't have the time nor the knowledge to analyze them. https://wiki.debian.org/Icedove Regards Carsten
