Bug#510589: still crashing in 17.0-1

2013-03-04 Thread Daniel Kahn Gillmor 
On Mon 2013-02-25 17:03:02 -0500, Daniel Kahn Gillmor wrote:

 I just got another crash with icedove 17.0.2-1, but i've been running
 nspr 2:4.9.5-1 (which i hadn't managed to rebuild with
 DEB_BUILD_OPTIONS=debug yet), so i don't have any specific assert()
 output to share yet.  I'm re-building 4.9.5 right now to enable
 debugging in it in case i can trigger it again.

OK, got it.  I'm not seeing too much extra information in either the
backtrace or the log, though.  maybe i need to look somewhere else?

the backtrace and a bit of poking around:

013-03-04 14:53:01.354 enigmailCommon.jsm: execStart: command = /usr/bin/gpg 
--charset utf-8 --display-charset utf-8 --batch --no-tty --status-fd 2 
--verify, needPassphrase=false, domWindow=[object ChromeWindow], 
listener=[object Object]
2013-03-04 14:53:01.354 [CONSOLE] enigmail /usr/bin/gpg --charset utf-8 
--display-charset utf-8 --batch --no-tty --status-fd 2 --verify
[New Thread 0x7fffc0dfd700 (LWP 10348)]
[New Thread 0x7fffaefff700 (LWP 10350)]
[New Thread 0x7fff8fbff700 (LWP 10349)]
[New Thread 0x7fff8e4ff700 (LWP 10351)]
[New Thread 0x7fffc11ff700 (LWP 10353)]
[New Thread 0x7fff99eff700 (LWP 10352)]
[New Thread 0x7fff8adff700 (LWP 10355)]
[New Thread 0x7fff8c8ff700 (LWP 10354)]
[New Thread 0x7fff89fff700 (LWP 10356)]
Assertion failure: pRec-state != _PR_PID_REAPED, at uxproces.c:521

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffb70ff700 (LWP 21153)]
0x770dc475 in *__GI_raise (sig=optimized out)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x770dc475 in *__GI_raise (sig=optimized out)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x770df6f0 in *__GI_abort () at abort.c:92
#2  0x762e506a in PR_Assert (
s=s@entry=0x7630a15b pRec-state != _PR_PID_REAPED, 
file=file@entry=0x7630a0b4 uxproces.c, ln=ln@entry=521)
at prlog.c:554
#3  0x76303020 in ProcessReapedChildInternal (pid=pid@entry=10347, 
status=0) at uxproces.c:521
#4  0x763036ef in WaitPidDaemonThread (unused=optimized out)
at uxproces.c:658
#5  0x763002eb in _pt_root (arg=0x7fffdd06e570) at ptthread.c:156
#6  0x7743ab50 in start_thread (arg=optimized out)
at pthread_create.c:304
#7  0x77184a7d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#8  0x in ?? ()
(gdb) up
#1  0x770df6f0 in *__GI_abort () at abort.c:92
92  abort.c: No such file or directory.
(gdb) up
#2  0x762e506a in PR_Assert (
s=s@entry=0x7630a15b pRec-state != _PR_PID_REAPED, 
file=file@entry=0x7630a0b4 uxproces.c, ln=ln@entry=521)
at prlog.c:554
554 abort();
(gdb) up
#3  0x76303020 in ProcessReapedChildInternal (pid=pid@entry=10347, 
status=0) at uxproces.c:521
521 PR_ASSERT(pRec-state != _PR_PID_REAPED);
(gdb) p pRec
$1 = (pr_PidRecord *) 0x7fff9a9bdfe0
(gdb) p *pRec
$2 = {pid = 10347, exitStatus = 0, state = _PR_PID_REAPED, reapedCV = 0x0, 
  next = 0x7fffab752560}
(gdb) 



and the debug log:

0 dkg@alice:~$ tail -n 30  tmp/icedove-dbg.log 
-134363360[76d67260]: (textrunui) fontgroup: [Sans] lang: en-us script: 
25 len 1 weight: 400 width: 0 style: normal TEXTRUN [S] ENDTEXTRUN
-134363360[76d67260]: (textrunui) fontgroup: [Sans] lang: en-us script: 
25 len 1 weight: 400 width: 0 style: normal TEXTRUN [o] ENDTEXTRUN
-134363360[76d67260]: (textrunui) fontgroup: [Sans] lang: en-us script: 
25 len 10 weight: 400 width: 0 style: normal TEXTRUN [Lennart S…] ENDTEXTRUN
-134363360[76d67260]: (textrunui) fontgroup: [Sans] lang: en-us script: 
25 len 10 weight: 400 width: 0 style: normal TEXTRUN [Lennart S…] ENDTEXTRUN
-134363360[76d67260]: (textrunui) fontgroup: [Sans] lang: en-us script: 
25 len 10 weight: 400 width: 0 style: normal TEXTRUN [Lennart S…] ENDTEXTRUN
-134363360[76d67260]: (textrunui) fontgroup: [Sans] lang: en-us script: 
25 len 8 weight: 400 width: 0 style: normal TEXTRUN [02:19 PM] ENDTEXTRUN
-134363360[76d67260]: (textrunui) fontgroup: [Sans] lang: en-us script: 
25 len 8 weight: 400 width: 0 style: normal TEXTRUN [02:19 PM] ENDTEXTRUN
-134363360[76d67260]: (textrunui) fontgroup: [Sans] lang: en-us script: 
25 len 8 weight: 400 width: 0 style: normal TEXTRUN [02:19 PM] ENDTEXTRUN
-134363360[76d67260]: (textrunui) fontgroup: [Sans] lang: en-us script: 
25 len 21 weight: 400 width: 0 style: normal TEXTRUN [Re: USB3 3TB HDD boot] 
ENDTEXTRUN
-134363360[76d67260]: (textrunui) fontgroup: [Sans] lang: en-us script: 
25 len 21 weight: 400 width: 0 style: normal TEXTRUN [Re: USB3 3TB HDD boot] 
ENDTEXTRUN
-134363360[76d67260]: (textrunui) fontgroup: [Sans] lang: en-us script: 
25 len 21 weight: 400 width: 0 style: normal TEXTRUN [Re: USB3 3TB HDD boot] 
ENDTEXTRUN
-134363360[76d67260]: (textrunui) fontgroup: [Sans] lang: en-us script: 
25 len 7 weight: 400

Bug#510589: still crashing in 17.0-1

2013-02-25 Thread Daniel Kahn Gillmor 
Control: found 510589 17.0.2-1

On Sat 2013-01-19 11:16:14 -0800, Daniel Kahn Gillmor wrote:

 I've rebuilt nspr 2:4.9.4-2 with this option and installed it; i'm also
 running icedove under gdb.  I'll report if i get anything to replicate.

I just got another crash with icedove 17.0.2-1, but i've been running
nspr 2:4.9.5-1 (which i hadn't managed to rebuild with
DEB_BUILD_OPTIONS=debug yet), so i don't have any specific assert()
output to share yet.  I'm re-building 4.9.5 right now to enable
debugging in it in case i can trigger it again.

Mike, do you think this bug report should be shifted to nspr from
icedove?  i'm not sure how to best track this behavior down.  it seems
like a racy sort of thing, and i'm just hitting it randomly by virtue of
processing so much mail.

this is frustrating because it makes it rather difficult to reproduce
reliably :(

here is the console output and gdb backtrace:

2013-02-25 13:46:40.217 [DEBUG] enigmailMessengerOverlay.js: messageFrameUnload
2013-02-25 13:46:40.217 [DEBUG] enigmailMsgHdrViewOverlay.js: this.messageUnload
2013-02-25 13:46:40.219 [DEBUG] enigmailMsgHdrViewOverlay.js: 
_listener_onStartHeaders
2013-02-25 13:46:40.219 [DEBUG] enigmailMessengerOverlay.js: setAttachmentReveal
2013-02-25 13:46:40.220 [DEBUG] enigmailCommon.jsm: getFrame: name=messagepane
2013-02-25 13:46:40.220 [DEBUG] enigmailMsgHdrViewOverlay.js: msgFrame=[object 
Window]
2013-02-25 13:46:40.221 [DEBUG] enigmailMsgHdrViewOverlay.js: 
enigmailPrepSecurityInfo
2013-02-25 13:46:40.259 [DEBUG] enigmailMsgHdrViewOverlay.js: 
_listener_onEndHeaders
2013-02-25 13:46:40.259 [DEBUG] enigmailMessengerOverlay.js: setAttachmentReveal
2013-02-25 13:46:40.284 [DEBUG] enigmailMessengerOverlay.js: messageDecrypt: 
[object Event]
2013-02-25 13:46:40.296 [DEBUG] enigmailCommon.jsm: dispatchEvent f=
2013-02-25 13:46:40.297 [DEBUG] enigmailCommon.jsm: dispatchEvent running 
mainEvent
2013-02-25 13:46:40.297 [DEBUG] enigmailMessengerOverlay.js: messageDecryptCb:
2013-02-25 13:46:40.297 [DEBUG] enigmailMessengerOverlay.js: header 
content-type: text/plain; charset=ISO-8859-1
2013-02-25 13:46:40.297 [DEBUG] enigmailMessengerOverlay.js: header 
content-transfer-encoding: 7bit
2013-02-25 13:46:40.297 [DEBUG] enigmailMessengerOverlay.js: header 
x-enigmail-version: 1.5
2013-02-25 13:46:40.297 [DEBUG] enigmailMessengerOverlay.js: header 
x-pgp-encoding-format: 
2013-02-25 13:46:40.297 [DEBUG] enumerateMimeParts:  - text/plain; 
charset=ISO-8859-1
2013-02-25 13:46:40.297 [DEBUG] enumerateMimeParts: 1 - text/plain; 
charset=ISO-8859-1
2013-02-25 13:46:40.297 [DEBUG] enigmailMessengerOverlay.js: embedded objects:  
/ 
2013-02-25 13:46:40.298 [DEBUG] enigmailMessengerOverlay.js: messageParse: false
2013-02-25 13:46:40.298 [DEBUG] enigmailCommon.jsm: getFrame: name=messagepane
2013-02-25 13:46:40.298 [DEBUG] enigmailMessengerOverlay.js: msgFrame=[object 
Window]
2013-02-25 13:46:40.298 [DEBUG] enigmailMessengerOverlay.js: 
bodyElement=[object HTMLBodyElement]
2013-02-25 13:46:40.299 [DEBUG] enigmailMessengerOverlay.js: 
messageParseCallback: false, false, importOnly=false, charset=ISO-8859-1, 
msgUrl=imap://d...@che.mayfirst.org:143/fetch%3EUID%3E.INBOX%3E313891, retry=1, 
signature=''
2013-02-25 13:46:40.299 [DEBUG] enigmail.js: Enigmail.decryptMessage: 2040 
bytes, 0
2013-02-25 13:46:40.299 [DEBUG] enigmail.js: Enigmail.decryptMessage: 
oldSignature=
2013-02-25 13:46:40.299 [DEBUG] enigmail.js: Enigmail.locateArmoredBlock: 0, ''
2013-02-25 13:46:40.299 [DEBUG] enigmail.js: Enigmail.locateArmoredBlock: 
blockType=SIGNED MESSAGE
2013-02-25 13:46:40.299 [DEBUG] enigmail.js: Enigmail.extractSignaturePart: 
part=3
2013-02-25 13:46:40.299 [DEBUG] enigmailCommon.jsm: decryptMessageStart: 
verifyOnly=true
2013-02-25 13:46:40.299 enigmailCommon.jsm: execStart: command = /usr/bin/gpg 
--charset utf-8 --display-charset utf-8 --batch --no-tty --status-fd 2 
--decrypt, needPassphrase=false, domWindow=[object ChromeWindow], 
listener=[object Object]
2013-02-25 13:46:40.299 [CONSOLE] enigmail /usr/bin/gpg --charset utf-8 
--display-charset utf-8 --batch --no-tty --status-fd 2 --decrypt
[New Thread 0x7fff8d8ff700 (LWP 32708)]
[New Thread 0x7fff8afff700 (LWP 32707)]
[New Thread 0x7fff895fe700 (LWP 32709)]
[New Thread 0x7fff8eaff700 (LWP 32710)]
[New Thread 0x7fff8a7fe700 (LWP 32712)]
[New Thread 0x7fff8fbff700 (LWP 32711)]
[Thread 0x7fff8eaff700 (LWP 32710) exited]
[Thread 0x7fff8afff700 (LWP 32707) exited]
2013-02-25 13:46:40.512 [DEBUG] enigmail.js: decryptMessage: got plaintext: 'On 
02/24/2013 03:23 PM, Henri Salo wrote:
 Hello list,

 With wpscan-team I noticed that file jwplayer.swf in WordPress
 plugin smart-flv is vulnerable to reflected XSS vulnerability.

 URL: http://wordpress.org/extend/plugins/smart-flv/
 416d0313c5f286c3a8e9daff520a9f44439b93f7
 http://plugins.svn.wordpress.org/smart-flv/trunk/jwplayer.swf

 With user interaction (clicking the page):

Bug#510589: still crashing in 17.0-1

2013-02-25 Thread Mike Hommey 
On Mon, Feb 25, 2013 at 02:03:02PM -0800, Daniel Kahn Gillmor wrote:
 Control: found 510589 17.0.2-1
 
 On Sat 2013-01-19 11:16:14 -0800, Daniel Kahn Gillmor wrote:
 
  I've rebuilt nspr 2:4.9.4-2 with this option and installed it; i'm also
  running icedove under gdb.  I'll report if i get anything to replicate.
 
 I just got another crash with icedove 17.0.2-1, but i've been running
 nspr 2:4.9.5-1 (which i hadn't managed to rebuild with
 DEB_BUILD_OPTIONS=debug yet), so i don't have any specific assert()
 output to share yet.  I'm re-building 4.9.5 right now to enable
 debugging in it in case i can trigger it again.
 
 Mike, do you think this bug report should be shifted to nspr from
 icedove?  i'm not sure how to best track this behavior down.  it seems
 like a racy sort of thing, and i'm just hitting it randomly by virtue of
 processing so much mail.

It could still be a problem on icedove's end.

Mike


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#510589: Fwd: Re: Bug#510589: still crashing in 17.0-1

2013-01-19 Thread Carsten Schoenert 
Hello Mike,

can you please take a look into this bug?
You know more of the internal mystique of Icedove. :)
This forwarded mail is the beginning of the interesting part that Daniel
has posted.

Thx
Carsten

 Original-Nachricht 
Betreff: Re: Bug#510589: still crashing in 17.0-1

On 01/13/2013 04:08 AM, Carsten Schoenert wrote:
 You have to call backtrace with a few more arguments, icedove is a multi
 threaded program, so we must to see all the threads. So please try
 (gdb) thread apply all bt

thanks for the suggestion!

i've tried this, but all the stack frames are still anonymous memory
locations (weirdly, with the exception of a single non-helpful line in
thread 35:

Thread 35 (LWP 17416):
#0  0x7f37da62f64b in ?? ()
#1  0x076f in ?? ()
#2  0x7f37bc82c188 in ?? ()
#3  0x7f37bc8630e8 in ?? ()
#4  0x07d9 in ?? ()
#5  0x7f378b9fecd0 in ?? ()
#6  0x7fff347ffa1b in gettimeofday ()
#7  0x07da in ?? ()
#8  0x07d9 in ?? ()
#9  0x07d9 in ?? ()
#10 0x7f37bc8630e8 in ?? ()
#11 0x076f0002 in ?? ()
#12 0x in ?? ()

)

 This looks like there are no debugging symbols. Without the symbols it's
 impossible to track down the error.

I have the corresponding icedove-dbg package -- what other package do i
need?

 just need the output of icedove made with the gdb while crashing. In
 the Icdove wiki page [1] are all the needed part to collect this data.
 Please check if the segfaults also happen while using a clean fresh
 profile without any extensions! Many problems happen to users that uses
 migrated User Profiles from Thunderbird 1.5. or 2.0.

the segfaults i've seen have not be trivially reproducible or tied to
any particular action.  they happen after at least a day of active use
(and i process a lot of e-mail).  This is not something i can actually
do with a fresh profile, or without the extensions i rely on (enigmail
in particular).

 If you can also collect data from the icedove activity itself [2] so
 please do.

this seems to want me to run icedove while creating a huge activity log.
 I'll try this, but given the amount of activity between crashes, i
suspect this file is likely to be enormous.  I'll see what i can do with
it, though.

 Depending on point the segfault happen it's maybe necessary to install
 more packages with debugging symbols.

which packages should i install beyond icedove-dbg?

 fwiw, I'm running icedove from experimental:
 
 Strange, all my various icedove versions doesn't segfaulting for a long
 time. Which debian release do you use?

I use primarily wheezy, but with some packages from sid and experimental.

--dkg



-- 
Mit freundlichen Grüßen
Carsten Schönert


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#510589: still crashing in 17.0-1

2013-01-19 Thread Mike Hommey 
On Fri, Jan 18, 2013 at 04:31:19PM -0500, Daniel Kahn Gillmor wrote:
 On Wed 2013-01-16 12:10:22 -0500, Daniel Kahn Gillmor wrote:
 
  woo, yay(?), i got one!
 
 and i just got another one:
 
 [New Thread 0x7fff8fdfd700 (LWP 10439)]
 
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x7fffcf1ff700 (LWP 28932)]
 pt_PostNotifyToCvar (cvar=0x0, broadcast=broadcast@entry=0) at ptsynch.c:280
 280   ptsynch.c: No such file or directory.
 (gdb) bt
 #0  pt_PostNotifyToCvar (cvar=0x0, broadcast=broadcast@entry=0) at 
 ptsynch.c:280
 #1  0x762fdcbb in PR_NotifyCondVar (cvar=optimized out) at 
 ptsynch.c:413
 #2  0x76305859 in ProcessReapedChildInternal (pid=pid@entry=10430, 
 status=optimized out) at uxproces.c:531
 #3  0x76305e77 in WaitPidDaemonThread (unused=optimized out) at 
 uxproces.c:658
 #4  0x763033b3 in _pt_root (arg=0x7fffd0060bc0) at ptthread.c:156
 #5  0x7743ab50 in start_thread (arg=optimized out) at 
 pthread_create.c:304
 #6  0x77184a7d in clone () at 
 ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
 #7  0x in ?? ()
 (gdb) 
 
 
 0 dkg@alice:~$ tail -n 30 tmp/icedove-dbg.log 
 -470812928[76d5f7b0]:   PR_Read returned [n=10]
 -470812928[76d5f7b0]: nsSocketTransport::SendStatus [this=d0be9640 
 status=804b0006]
 -470812928[76d5f7b0]: nsSocketInputStream::Read [this=d0be9770 
 count=32758]
 -470812928[76d5f7b0]:   calling PR_Read [count=32758]
 -470812928[76d5f7b0]:   PR_Read returned [n=-1]
 -470812928[76d5f7b0]: nsSocketInputStream::AsyncWait [this=d0be9770]
 -470812928[76d5f7b0]: STS poll iter [1]
 -470812928[76d5f7b0]:   active [4] { handler=a244bbc0 condition=0 
 pollflags=5 }
 -470812928[76d5f7b0]:   active [3] { handler=d02951c0 condition=0 
 pollflags=5 }
 -470812928[76d5f7b0]:   active [2] { handler=a4181cc0 condition=0 
 pollflags=5 }
 -470812928[76d5f7b0]:   active [1] { handler=cdf6d760 condition=0 
 pollflags=5 }
 -470812928[76d5f7b0]:   active [0] { handler=d0be9640 condition=0 
 pollflags=5 }
 -470812928[76d5f7b0]:   idle [0] { handler=d0be9300 condition=0 
 pollflags=0 }
 -470812928[76d5f7b0]:   calling PR_Poll [active=5 idle=1]
 -470812928[76d5f7b0]: poll timeout: 65535
 -470812928[76d5f7b0]: timeout = 65535000 milliseconds
 -470812928[76d5f7b0]: ...returned after 0 milliseconds
 -470812928[76d5f7b0]: STS poll iter [1]
 -470812928[76d5f7b0]:   active [4] { handler=a244bbc0 condition=0 
 pollflags=5 }
 -470812928[76d5f7b0]:   active [3] { handler=d02951c0 condition=0 
 pollflags=5 }
 -470812928[76d5f7b0]:   active [2] { handler=a4181cc0 condition=0 
 pollflags=5 }
 -470812928[76d5f7b0]:   active [1] { handler=cdf6d760 condition=0 
 pollflags=5 }
 -470812928[76d5f7b0]:   active [0] { handler=d0be9640 condition=0 
 pollflags=5 }
 -470812928[76d5f7b0]:   idle [0] { handler=d0be9300 condition=0 
 pollflags=0 }
 -470812928[76d5f7b0]:   calling PR_Poll [active=5 idle=1]
 -470812928[76d5f7b0]: poll timeout: 65535
 -470812928[76d5f7b0]: timeout = 65535000 milliseconds
 -1755318528[7fffbdbc1f20]: ReadNextLine [stream=99c73810 nb=10 needmore=0]
 -1755318528[7fffbdbc1f20]: 
 956f7000:che.mayfirst.org:S-INBOX:CreateNewLineFromSocket: + idling
 -1317939456[7fffc04ee6a0]: libc.so.6 decr = 3
 0 dkg@alice:~$ 
 
 
 So this looks like the same spot.
 
 I'm running libnspr4 2:4.9.2-1.  I'll try switching to 2:4.9.4-2 from
 sid instead and see if i can replicate.

You may want to rebuild nspr with DEB_BUILD_OPTIONS=debug, seeing your
backtrace, you'll likely hit some assert, which may give better insight.

Mike


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#510589: still crashing in 17.0-1

2013-01-19 Thread Daniel Kahn Gillmor 
On 01/19/2013 03:57 AM, Mike Hommey wrote:

 You may want to rebuild nspr with DEB_BUILD_OPTIONS=debug, seeing your
 backtrace, you'll likely hit some assert, which may give better insight.

I've rebuilt nspr 2:4.9.4-2 with this option and installed it; i'm also
running icedove under gdb.  I'll report if i get anything to replicate.

thanks for the suggestions, Mike and Carsten.

--dkg



signature.asc
Description: OpenPGP digital signature

Bug#510589: still crashing in 17.0-1

2013-01-18 Thread Daniel Kahn Gillmor 
On Wed 2013-01-16 12:10:22 -0500, Daniel Kahn Gillmor wrote:

 woo, yay(?), i got one!

and i just got another one:

[New Thread 0x7fff8fdfd700 (LWP 10439)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcf1ff700 (LWP 28932)]
pt_PostNotifyToCvar (cvar=0x0, broadcast=broadcast@entry=0) at ptsynch.c:280
280 ptsynch.c: No such file or directory.
(gdb) bt
#0  pt_PostNotifyToCvar (cvar=0x0, broadcast=broadcast@entry=0) at ptsynch.c:280
#1  0x762fdcbb in PR_NotifyCondVar (cvar=optimized out) at 
ptsynch.c:413
#2  0x76305859 in ProcessReapedChildInternal (pid=pid@entry=10430, 
status=optimized out) at uxproces.c:531
#3  0x76305e77 in WaitPidDaemonThread (unused=optimized out) at 
uxproces.c:658
#4  0x763033b3 in _pt_root (arg=0x7fffd0060bc0) at ptthread.c:156
#5  0x7743ab50 in start_thread (arg=optimized out) at 
pthread_create.c:304
#6  0x77184a7d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x in ?? ()
(gdb) 


0 dkg@alice:~$ tail -n 30 tmp/icedove-dbg.log 
-470812928[76d5f7b0]:   PR_Read returned [n=10]
-470812928[76d5f7b0]: nsSocketTransport::SendStatus [this=d0be9640 
status=804b0006]
-470812928[76d5f7b0]: nsSocketInputStream::Read [this=d0be9770 count=32758]
-470812928[76d5f7b0]:   calling PR_Read [count=32758]
-470812928[76d5f7b0]:   PR_Read returned [n=-1]
-470812928[76d5f7b0]: nsSocketInputStream::AsyncWait [this=d0be9770]
-470812928[76d5f7b0]: STS poll iter [1]
-470812928[76d5f7b0]:   active [4] { handler=a244bbc0 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [3] { handler=d02951c0 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [2] { handler=a4181cc0 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [1] { handler=cdf6d760 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [0] { handler=d0be9640 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   idle [0] { handler=d0be9300 condition=0 pollflags=0 
}
-470812928[76d5f7b0]:   calling PR_Poll [active=5 idle=1]
-470812928[76d5f7b0]: poll timeout: 65535
-470812928[76d5f7b0]: timeout = 65535000 milliseconds
-470812928[76d5f7b0]: ...returned after 0 milliseconds
-470812928[76d5f7b0]: STS poll iter [1]
-470812928[76d5f7b0]:   active [4] { handler=a244bbc0 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [3] { handler=d02951c0 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [2] { handler=a4181cc0 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [1] { handler=cdf6d760 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [0] { handler=d0be9640 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   idle [0] { handler=d0be9300 condition=0 pollflags=0 
}
-470812928[76d5f7b0]:   calling PR_Poll [active=5 idle=1]
-470812928[76d5f7b0]: poll timeout: 65535
-470812928[76d5f7b0]: timeout = 65535000 milliseconds
-1755318528[7fffbdbc1f20]: ReadNextLine [stream=99c73810 nb=10 needmore=0]
-1755318528[7fffbdbc1f20]: 
956f7000:che.mayfirst.org:S-INBOX:CreateNewLineFromSocket: + idling
-1317939456[7fffc04ee6a0]: libc.so.6 decr = 3
0 dkg@alice:~$ 


So this looks like the same spot.

I'm running libnspr4 2:4.9.2-1.  I'll try switching to 2:4.9.4-2 from
sid instead and see if i can replicate.

--dkg


pgpKg4q2CiEAZ.pgp
Description: PGP signature

Bug#510589: still crashing in 17.0-1

2013-01-16 Thread Daniel Kahn Gillmor 
On Mon 2013-01-14 13:00:06 -0500, Daniel Kahn Gillmor wrote:

 i've installed a bunch of other -dbg packages (e.g. libc6-dbg,
 libnspr4-dbg, libnss3-dbg, ...), in the hopes that that will give me
 more feedback in the next crash.

woo, yay(?), i got one!

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcf1ff700 (LWP 22319)]
pt_PostNotifyToCvar (cvar=0x0, broadcast=broadcast@entry=0) at ptsynch.c:280
280 ptsynch.c: No such file or directory.
(gdb) bt
#0  pt_PostNotifyToCvar (cvar=0x0, broadcast=broadcast@entry=0)
at ptsynch.c:280
#1  0x762fdcbb in PR_NotifyCondVar (cvar=optimized out)
at ptsynch.c:413
#2  0x76305859 in ProcessReapedChildInternal (pid=pid@entry=28412, 
status=optimized out) at uxproces.c:531
#3  0x76305e77 in WaitPidDaemonThread (unused=optimized out)
at uxproces.c:658
#4  0x763033b3 in _pt_root (arg=0x7fffd0067bc0) at ptthread.c:156
#5  0x7743ab50 in start_thread (arg=optimized out)
at pthread_create.c:304
#6  0x77184a7d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x in ?? ()
(gdb) 

I was running it with NSPR_LOG_MODULES=all:5
NSPR_LOG_FILE=~/tmp/icedove-dbg.log, and the mozilla debug log after a
couple days is 1.3GiB.  it ends with this:

-1670387968[7fff8fc2d040]: STS dispatch [7fff925039f0]
-470812928[76d5f7b0]: ...returned after 0 milliseconds
-470812928[76d5f7b0]: nsSocketOutputStream::Write [this=8ec62d60 count=37]
-470812928[76d5f7b0]:   calling PR_Write [count=37]
-470812928[76d5f7b0]:   PR_Write returned [n=37]
-470812928[76d5f7b0]: nsSocketTransport::SendStatus [this=8ec62c00 
status=804b0005]
-470812928[76d5f7b0]: nsSocketOutputStream::AsyncWait [this=8ec62d60]
-470812928[76d5f7b0]: STS poll iter [1]
-470812928[76d5f7b0]:   active [4] { handler=8ec642c0 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [3] { handler=8ec63900 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [2] { handler=8ec60500 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [1] { handler=8ec62c00 condition=0 
pollflags=7 }
-470812928[76d5f7b0]:   active [0] { handler=b3ec26a0 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   calling PR_Poll [active=5 idle=0]
-470812928[76d5f7b0]: poll timeout: 100
-470812928[76d5f7b0]: timeout = 10 milliseconds
-470812928[76d5f7b0]: ...returned after 0 milliseconds
-470812928[76d5f7b0]: nsSocketTransport::OnSocketReady [this=8ec62c00 
outFlags=2]
-470812928[76d5f7b0]: nsSocketOutputStream::OnSocketReady [this=8ec62d60 
cond=0]
-470812928[76d5f7b0]: STS poll iter [1]
-470812928[76d5f7b0]:   active [4] { handler=8ec642c0 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [3] { handler=8ec63900 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [2] { handler=8ec60500 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [1] { handler=8ec62c00 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   active [0] { handler=b3ec26a0 condition=0 
pollflags=5 }
-470812928[76d5f7b0]:   calling PR_Poll [active=5 idle=0]
-470812928[76d5f7b0]: poll timeout: 100
-470812928[76d5f7b0]: timeout = 10 milliseconds
-960497920[7fffaa6a6120]: libc.so.6 decr = 3

i have the gdb buffer still open -- any suggestions for other things i
might want to explore while i've still got it?

  --dkg


pgpfy4NML0mIi.pgp
Description: PGP signature

Bug#510589: still crashing in 17.0-1

2013-01-16 Thread Carsten Schoenert 
Hello Daniel,

Am 16.01.2013 18:10, schrieb Daniel Kahn Gillmor:
 On Mon 2013-01-14 13:00:06 -0500, Daniel Kahn Gillmor wrote:
 
 i've installed a bunch of other -dbg packages (e.g. libc6-dbg,
 libnspr4-dbg, libnss3-dbg, ...), in the hopes that that will give me
 more feedback in the next crash.
 
 woo, yay(?), i got one!

Hmm, o.k.
Can you provide a longer entry from the end? The few lines are to short
to see anything.

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

-- 
Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#510589: still crashing in 17.0-1

2013-01-16 Thread Sebastian Ramacher 
On 2013-01-16 12:10:22, Daniel Kahn Gillmor wrote:
 On Mon 2013-01-14 13:00:06 -0500, Daniel Kahn Gillmor wrote:
 
  i've installed a bunch of other -dbg packages (e.g. libc6-dbg,
  libnspr4-dbg, libnss3-dbg, ...), in the hopes that that will give me
  more feedback in the next crash.
 
 woo, yay(?), i got one!
 
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x7fffcf1ff700 (LWP 22319)]
 pt_PostNotifyToCvar (cvar=0x0, broadcast=broadcast@entry=0) at ptsynch.c:280
 280   ptsynch.c: No such file or directory.
 (gdb) bt
 #0  pt_PostNotifyToCvar (cvar=0x0, broadcast=broadcast@entry=0)
 at ptsynch.c:280
 #1  0x762fdcbb in PR_NotifyCondVar (cvar=optimized out)
 at ptsynch.c:413
 #2  0x76305859 in ProcessReapedChildInternal (pid=pid@entry=28412, 
 status=optimized out) at uxproces.c:531
 #3  0x76305e77 in WaitPidDaemonThread (unused=optimized out)
 at uxproces.c:658
 #4  0x763033b3 in _pt_root (arg=0x7fffd0067bc0) at ptthread.c:156
 #5  0x7743ab50 in start_thread (arg=optimized out)
 at pthread_create.c:304
 #6  0x77184a7d in clone ()
 at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
 #7  0x in ?? ()
 (gdb) 

Looks like #672860. I had the same traceback when using icedove and
enigmail to view signed mails.

Regards
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature

Bug#510589: still crashing in 17.0-1

2013-01-16 Thread Daniel Kahn Gillmor 
On 01/16/2013 12:29 PM, Sebastian Ramacher wrote:
 Looks like #672860. I had the same traceback when using icedove and
 enigmail to view signed mails.

it certainly does look similar to me.

--dkg



signature.asc
Description: OpenPGP digital signature

Bug#510589: still crashing in 17.0-1

2013-01-16 Thread Daniel Kahn Gillmor 
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[76d5f260]: Unloaded library libc.so.6
-134351072[76d5f260]: 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[76d5f260]: Unloaded library libc.so.6
-134351072[76d5f260]: 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[76d5f260]: Unloaded library libc.so.6
-134351072[76d5f260]: 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



signature.asc
Description: OpenPGP digital signature

Bug#510589: still crashing in 17.0-1

2013-01-14 Thread Carsten Schoenert 
Hello

Am 13.01.2013 18:32, schrieb Daniel Kahn Gillmor:
 thanks for the suggestion!
 
 i've tried this, but all the stack frames are still anonymous memory
 locations (weirdly, with the exception of a single non-helpful line in
 thread 35:

That's what I mean with other packages with debugging symbols. I
believe your segfaults don't come from icedove itself. I thought they
come from a other package, but don't know which package it could be. So
a good backtrace would be really helpfull.

 I have the corresponding icedove-dbg package -- what other package do i
 need?

As I can see you use a core dump, mhh as I remember right (I'm not at
home while writing this mail) the gdb always show the package there the
symbol would come from while the binary is running inside. So please try
to icedove inside the gdb.

 I use primarily wheezy, but with some packages from sid and experimental.

o.k. thanks

-- 
Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#510589: still crashing in 17.0-1

2013-01-14 Thread Daniel Kahn Gillmor 
On 01/14/2013 11:45 AM, Carsten Schoenert wrote:
 As I can see you use a core dump, mhh as I remember right (I'm not at
 home while writing this mail) the gdb always show the package there the
 symbol would come from while the binary is running inside. So please try
 to icedove inside the gdb.

running icedove inside gdb makes it significantly slower and less
responsive.  checking my mail is a critical part of my daily workflow,
so this is a pretty difficult task.  it's a shame if this is the only
approach we can ask of people to help us debug :(

i've installed a bunch of other -dbg packages (e.g. libc6-dbg,
libnspr4-dbg, libnss3-dbg, ...), in the hopes that that will give me
more feedback in the next crash.

--dkg



signature.asc
Description: OpenPGP digital signature

Bug#510589: still crashing in 17.0-1

2013-01-13 Thread Daniel Kahn Gillmor 
On 01/13/2013 04:08 AM, Carsten Schoenert wrote:
 You have to call backtrace with a few more arguments, icedove is a multi
 threaded program, so we must to see all the threads. So please try
 (gdb) thread apply all bt

thanks for the suggestion!

i've tried this, but all the stack frames are still anonymous memory
locations (weirdly, with the exception of a single non-helpful line in
thread 35:

Thread 35 (LWP 17416):
#0  0x7f37da62f64b in ?? ()
#1  0x076f in ?? ()
#2  0x7f37bc82c188 in ?? ()
#3  0x7f37bc8630e8 in ?? ()
#4  0x07d9 in ?? ()
#5  0x7f378b9fecd0 in ?? ()
#6  0x7fff347ffa1b in gettimeofday ()
#7  0x07da in ?? ()
#8  0x07d9 in ?? ()
#9  0x07d9 in ?? ()
#10 0x7f37bc8630e8 in ?? ()
#11 0x076f0002 in ?? ()
#12 0x in ?? ()

)

 This looks like there are no debugging symbols. Without the symbols it's
 impossible to track down the error.

I have the corresponding icedove-dbg package -- what other package do i
need?

 just need the output of icedove made with the gdb while crashing. In
 the Icdove wiki page [1] are all the needed part to collect this data.
 Please check if the segfaults also happen while using a clean fresh
 profile without any extensions! Many problems happen to users that uses
 migrated User Profiles from Thunderbird 1.5. or 2.0.

the segfaults i've seen have not be trivially reproducible or tied to
any particular action.  they happen after at least a day of active use
(and i process a lot of e-mail).  This is not something i can actually
do with a fresh profile, or without the extensions i rely on (enigmail
in particular).

 If you can also collect data from the icedove activity itself [2] so
 please do.

this seems to want me to run icedove while creating a huge activity log.
 I'll try this, but given the amount of activity between crashes, i
suspect this file is likely to be enormous.  I'll see what i can do with
it, though.

 Depending on point the segfault happen it's maybe necessary to install
 more packages with debugging symbols.

which packages should i install beyond icedove-dbg?

 fwiw, I'm running icedove from experimental:
 
 Strange, all my various icedove versions doesn't segfaulting for a long
 time. Which debian release do you use?

I use primarily wheezy, but with some packages from sid and experimental.

--dkg



signature.asc
Description: OpenPGP digital signature