* fetchmail almost works
@ 1999-06-24 10:37 Ian T Zimmerman
1999-06-24 12:02 ` Chris Faylor
1999-06-30 22:10 ` Ian T Zimmerman
0 siblings, 2 replies; 4+ messages in thread
From: Ian T Zimmerman @ 1999-06-24 10:37 UTC (permalink / raw)
To: cygwin
I compiled version 4.6.4 of fetchmail. It seems to work well (on my
binary mount that is) but from time to time generates access
violations. The little binary dump in the event log report seems to
indicate it occurs in WaitForMultipleObjects(), which I with my rusty
knowledge of Win32 translate into select(). Is that right?
I don't think I'd get anywhere systematically debugging with gdb as
this is intermittent. When this crash happens, a short stack trace is
left in my home directory, here it is:
[main] fetchmail 9623 (0) exception: trapped!
[main] fetchmail 9623 (1) exception: code 0xC0000005 at 0x407CD5
[main] fetchmail 9623 (0) exception: ax 0x0 bx 0x9 cx 0x1201 dx 0x61061104
[main] fetchmail 9623 (0) exception: si 0xA0374B8 di 0x0 bp 0x249FB30 sp 0x249FB00
[main] fetchmail 9623 (0) exception: exception is: STATUS_ACCESS_VIOLATION
[main] fetchmail 9623 (0) stack: Stack trace:
[main] fetchmail 9623 (0) stack: frame 0: sp = 0x249F914, pc = 0x6100A2C3
[main] fetchmail 9623 (0) stack: frame 1: sp = 0x249F950, pc = 0x77F96666
[main] fetchmail 9623 (0) stack: frame 2: sp = 0x249F974, pc = 0x77F8912B
[main] fetchmail 9623 (0) stack: frame 3: sp = 0x249FA00, pc = 0x77F763BA
[main] fetchmail 9623 (0) stack: frame 4: sp = 0x249FB30, pc = 0x41669C
[main] fetchmail 9623 (0) stack: frame 5: sp = 0x249FE4C, pc = 0x40A075
[main] fetchmail 9623 (0) stack: frame 6: sp = 0x249FE5C, pc = 0x40DB3D
[main] fetchmail 9623 (0) stack: frame 7: sp = 0x249FE78, pc = 0x40DAB3
[main] fetchmail 9623 (0) stack: frame 8: sp = 0x249FE94, pc = 0x40BE42
[main] fetchmail 9623 (0) stack: frame 9: sp = 0x249FF40, pc = 0x61004402
[main] fetchmail 9623 (0) stack: frame 10: sp = 0x249FF88, pc = 0x61004420
[main] fetchmail 9623 (0) stack: frame 11: sp = 0x249FF94, pc = 0x41FD0E
[main] fetchmail 9623 (0) stack: frame 12: sp = 0x249FFA4, pc = 0x40103A
[main] fetchmail 9623 (0) stack: frame 13: sp = 0x249FFC0, pc = 0x77F1BA06
[main] fetchmail 9623 (0) stack: frame 14: sp = 0x249FFF0, pc = 0x0
[main] fetchmail 9623 (0) stack: End of stack trace
Of course I don't expect this will be useful without some sort of load
map. (I can send the ooutput of "nm /usr/bin/fetchmail" if thought
helpful). Is there a way to produce a real core file that can be
loaded into gdb for post mortem analysis?
Particulars about my setup:
NT Workstation 4.0, SP5
Cygwin b20, unmodified
NTFS binary mount
CYGWIN=tty ntea
fetchmail config file is:
set daemon 300
set logfile /usr/local/var/log/fetchmail.log
poll light.lbin.com
protocol pop3
user itz is itz here
password ********
mda "/usr/local/bin/deliver -b /usr/local/var/spool/mail/%T"
(Oh yeah, I have successfully built deliver :-)
BTW, the crash also (sometimes) happens when I run fetchmail
interactively, so it is not specific to daemonization. And it also
happened when I let fetchmail use syslog instead of logging in a file.
Best regards,
--
Ian Zimmerman
Lightbinders, Inc.
2325 3rd Street #324, San Francisco, California 94107
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: fetchmail almost works
1999-06-24 10:37 fetchmail almost works Ian T Zimmerman
@ 1999-06-24 12:02 ` Chris Faylor
1999-06-30 22:10 ` Chris Faylor
1999-06-30 22:10 ` Ian T Zimmerman
1 sibling, 1 reply; 4+ messages in thread
From: Chris Faylor @ 1999-06-24 12:02 UTC (permalink / raw)
To: Ian T Zimmerman; +Cc: cygwin
On Thu, Jun 24, 1999 at 05:36:18PM +0000, Ian T Zimmerman wrote:
>I compiled version 4.6.4 of fetchmail. It seems to work well (on my
>binary mount that is) but from time to time generates access
>violations. The little binary dump in the event log report seems to
>indicate it occurs in WaitForMultipleObjects(), which I with my rusty
>knowledge of Win32 translate into select(). Is that right?
>
>I don't think I'd get anywhere systematically debugging with gdb as
>this is intermittent. When this crash happens, a short stack trace is
>left in my home directory, here it is:
>
>[main] fetchmail 9623 (0) exception: trapped!
>[main] fetchmail 9623 (1) exception: code 0xC0000005 at 0x407CD5
>[main] fetchmail 9623 (0) exception: ax 0x0 bx 0x9 cx 0x1201 dx 0x61061104
>[main] fetchmail 9623 (0) exception: si 0xA0374B8 di 0x0 bp 0x249FB30 sp 0x249FB00
>[main] fetchmail 9623 (0) exception: exception is: STATUS_ACCESS_VIOLATION
>
>Of course I don't expect this will be useful without some sort of load
>map. (I can send the ooutput of "nm /usr/bin/fetchmail" if thought
>helpful). Is there a way to produce a real core file that can be
>loaded into gdb for post mortem analysis?
It's useful enough to know that it is dying in fetchmail. You can translate
addresses either using gdb or addr2line.
It seems very likely that you are going to have to use gdb to debug this.
There isn't much anyone can do to remotely debug something from a stack
dump.
There is no way to produce a core file via cygwin, currently.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: fetchmail almost works
1999-06-24 12:02 ` Chris Faylor
@ 1999-06-30 22:10 ` Chris Faylor
0 siblings, 0 replies; 4+ messages in thread
From: Chris Faylor @ 1999-06-30 22:10 UTC (permalink / raw)
To: Ian T Zimmerman; +Cc: cygwin
On Thu, Jun 24, 1999 at 05:36:18PM +0000, Ian T Zimmerman wrote:
>I compiled version 4.6.4 of fetchmail. It seems to work well (on my
>binary mount that is) but from time to time generates access
>violations. The little binary dump in the event log report seems to
>indicate it occurs in WaitForMultipleObjects(), which I with my rusty
>knowledge of Win32 translate into select(). Is that right?
>
>I don't think I'd get anywhere systematically debugging with gdb as
>this is intermittent. When this crash happens, a short stack trace is
>left in my home directory, here it is:
>
>[main] fetchmail 9623 (0) exception: trapped!
>[main] fetchmail 9623 (1) exception: code 0xC0000005 at 0x407CD5
>[main] fetchmail 9623 (0) exception: ax 0x0 bx 0x9 cx 0x1201 dx 0x61061104
>[main] fetchmail 9623 (0) exception: si 0xA0374B8 di 0x0 bp 0x249FB30 sp 0x249FB00
>[main] fetchmail 9623 (0) exception: exception is: STATUS_ACCESS_VIOLATION
>
>Of course I don't expect this will be useful without some sort of load
>map. (I can send the ooutput of "nm /usr/bin/fetchmail" if thought
>helpful). Is there a way to produce a real core file that can be
>loaded into gdb for post mortem analysis?
It's useful enough to know that it is dying in fetchmail. You can translate
addresses either using gdb or addr2line.
It seems very likely that you are going to have to use gdb to debug this.
There isn't much anyone can do to remotely debug something from a stack
dump.
There is no way to produce a core file via cygwin, currently.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* fetchmail almost works
1999-06-24 10:37 fetchmail almost works Ian T Zimmerman
1999-06-24 12:02 ` Chris Faylor
@ 1999-06-30 22:10 ` Ian T Zimmerman
1 sibling, 0 replies; 4+ messages in thread
From: Ian T Zimmerman @ 1999-06-30 22:10 UTC (permalink / raw)
To: cygwin
I compiled version 4.6.4 of fetchmail. It seems to work well (on my
binary mount that is) but from time to time generates access
violations. The little binary dump in the event log report seems to
indicate it occurs in WaitForMultipleObjects(), which I with my rusty
knowledge of Win32 translate into select(). Is that right?
I don't think I'd get anywhere systematically debugging with gdb as
this is intermittent. When this crash happens, a short stack trace is
left in my home directory, here it is:
[main] fetchmail 9623 (0) exception: trapped!
[main] fetchmail 9623 (1) exception: code 0xC0000005 at 0x407CD5
[main] fetchmail 9623 (0) exception: ax 0x0 bx 0x9 cx 0x1201 dx 0x61061104
[main] fetchmail 9623 (0) exception: si 0xA0374B8 di 0x0 bp 0x249FB30 sp 0x249FB00
[main] fetchmail 9623 (0) exception: exception is: STATUS_ACCESS_VIOLATION
[main] fetchmail 9623 (0) stack: Stack trace:
[main] fetchmail 9623 (0) stack: frame 0: sp = 0x249F914, pc = 0x6100A2C3
[main] fetchmail 9623 (0) stack: frame 1: sp = 0x249F950, pc = 0x77F96666
[main] fetchmail 9623 (0) stack: frame 2: sp = 0x249F974, pc = 0x77F8912B
[main] fetchmail 9623 (0) stack: frame 3: sp = 0x249FA00, pc = 0x77F763BA
[main] fetchmail 9623 (0) stack: frame 4: sp = 0x249FB30, pc = 0x41669C
[main] fetchmail 9623 (0) stack: frame 5: sp = 0x249FE4C, pc = 0x40A075
[main] fetchmail 9623 (0) stack: frame 6: sp = 0x249FE5C, pc = 0x40DB3D
[main] fetchmail 9623 (0) stack: frame 7: sp = 0x249FE78, pc = 0x40DAB3
[main] fetchmail 9623 (0) stack: frame 8: sp = 0x249FE94, pc = 0x40BE42
[main] fetchmail 9623 (0) stack: frame 9: sp = 0x249FF40, pc = 0x61004402
[main] fetchmail 9623 (0) stack: frame 10: sp = 0x249FF88, pc = 0x61004420
[main] fetchmail 9623 (0) stack: frame 11: sp = 0x249FF94, pc = 0x41FD0E
[main] fetchmail 9623 (0) stack: frame 12: sp = 0x249FFA4, pc = 0x40103A
[main] fetchmail 9623 (0) stack: frame 13: sp = 0x249FFC0, pc = 0x77F1BA06
[main] fetchmail 9623 (0) stack: frame 14: sp = 0x249FFF0, pc = 0x0
[main] fetchmail 9623 (0) stack: End of stack trace
Of course I don't expect this will be useful without some sort of load
map. (I can send the ooutput of "nm /usr/bin/fetchmail" if thought
helpful). Is there a way to produce a real core file that can be
loaded into gdb for post mortem analysis?
Particulars about my setup:
NT Workstation 4.0, SP5
Cygwin b20, unmodified
NTFS binary mount
CYGWIN=tty ntea
fetchmail config file is:
set daemon 300
set logfile /usr/local/var/log/fetchmail.log
poll light.lbin.com
protocol pop3
user itz is itz here
password ********
mda "/usr/local/bin/deliver -b /usr/local/var/spool/mail/%T"
(Oh yeah, I have successfully built deliver :-)
BTW, the crash also (sometimes) happens when I run fetchmail
interactively, so it is not specific to daemonization. And it also
happened when I let fetchmail use syslog instead of logging in a file.
Best regards,
--
Ian Zimmerman
Lightbinders, Inc.
2325 3rd Street #324, San Francisco, California 94107
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-06-30 22:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-06-24 10:37 fetchmail almost works Ian T Zimmerman
1999-06-24 12:02 ` Chris Faylor
1999-06-30 22:10 ` Chris Faylor
1999-06-30 22:10 ` Ian T Zimmerman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).