Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
To:	cygwin AT sourceware DOT cygnus DOT com
Subject:	fetchmail almost works
From:	Ian T Zimmerman <itz AT lbin DOT com>
Date:	24 Jun 1999 17:36:18 +0000
Message-ID:	<87kjq1cm51.fsf@amazon.lbin.com>
Lines:	67
X-Mailer:	Gnus v5.6.45/XEmacs 21.0(beta67) - "20 minutes to Nikko"

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 AT sourceware DOT cygnus DOT com

- Raw text -