On 01/16/2013 12:25 PM, Carsten Schoenert wrote:
> Hmm, o.k.
> Can you provide a longer entry from the end? The few lines are to short
> to see anything.

i'm afraid that was the full backtrace.  do you want more lines from
icedove-dbg.log?  how is that file organized?  the part of the line
before the colon appears to be a pointer (maybe a thread identifier?).

so here are some ways of looking at just that pointer:


0 dkg@alice:~$ grep -a 7fffaa6a6120
src/icedove/crashing/2013-01-16/icedove-dbg.log
-960497920[7fffaa6a6120]: libc.so.6 incr => 2 (find lib)
-960497920[7fffaa6a6120]: libc.so.6 decr => 1
-960497920[7fffaa6a6120]: libc.so.6 incr => 4 (find lib)
-960497920[7fffaa6a6120]: libc.so.6 decr => 3
0 dkg@alice:~$


looking just at the use of libc.so.6:

0 dkg@alice:~$ grep -a libc.so.6
src/icedove/crashing/2013-01-16/icedove-dbg.log  | tail -n 20
-134351072[7ffff6d5f260]: Unloaded library libc.so.6
-134351072[7ffff6d5f260]: Loaded library libc.so.6 (load lib)
-1272994048[7fffaa6a5df0]: libc.so.6 incr => 2 (find lib)
-1468012800[7fffaa6a5350]: libc.so.6 incr => 3 (find lib)
-1444940032[7fffaa6a5460]: libc.so.6 incr => 4 (find lib)
-1468012800[7fffaa6a5350]: libc.so.6 decr => 3
-1444940032[7fffaa6a5460]: libc.so.6 decr => 2
-1272994048[7fffaa6a5df0]: libc.so.6 decr => 1
-134351072[7ffff6d5f260]: Unloaded library libc.so.6
-134351072[7ffff6d5f260]: Loaded library libc.so.6 (load lib)
-960497920[7fffaa6a6120]: libc.so.6 incr => 2 (find lib)
-1452280064[7fffaa6a6450]: libc.so.6 incr => 3 (find lib)
-1452280064[7fffaa6a6450]: libc.so.6 decr => 2
-960497920[7fffaa6a6120]: libc.so.6 decr => 1
-134351072[7ffff6d5f260]: Unloaded library libc.so.6
-134351072[7ffff6d5f260]: Loaded library libc.so.6 (load lib)
-1452280064[7fffaa6a6450]: libc.so.6 incr => 2 (find lib)
-1444940032[7fffaa6a5460]: libc.so.6 incr => 3 (find lib)
-960497920[7fffaa6a6120]: libc.so.6 incr => 4 (find lib)
-960497920[7fffaa6a6120]: libc.so.6 decr => 3
0 dkg@alice:~$


what other sorts of hints or data are you looking for?  icedove-dbg.log
seems to contain some personal data (at least including server and
account names), plus it's absolutely huge.  I'm happy to try other
extractions of data from it if you can suggest them, though.  I can also
try to redact parts of it, though that gets tedious.

> Hopefully we see the than the reason why it's segfaulting. :/

what do you think about sebastian's reference to #672860?

        --dkg

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to