Mail Archives: cygwin/1999/06/24/15:04:37
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 AT sourceware DOT cygnus DOT com
- Raw text -