Analyzing a SEG FAULT that gdb doesn't help with

Michael Enright
Wed Jul 29 23:16:00 GMT 2015

've got a program which was running but suddenly does not run.

I've been trying to debug in the usual way but all I get is a stackdump.

I consulted the internet for advice on how to use a stackdump and it
was pretty clear. I also brought LDD into the mix.

The IP register when the SEGV occurs is at 6155d363. Below are the
ranges per DLL that LDD prints for my system (updated today by the

        ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77840000)
        kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x754a0000)
        KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll
        cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
        cygexpat-1.dll => /usr/bin/cygexpat-1.dll (0x6f630000)
        cygmozjs185-1.0.dll => /usr/bin/cygmozjs185-1.0.dll (0x6e590000)
        cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x6f580000)
        cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x6d000000)
        cygffi-6.dll => /usr/bin/cygffi-6.dll (0x6f600000)
        cygnspr4.dll => /usr/bin/cygnspr4.dll (0x6df70000)

So I tried to addr2line /usr/bin/cygwin1.dll 6155d363 and I got
nothing (?? at ??:?) I then reviewed in setup-x86 the possible cygwin
packages to see if there was a missing package I could use to enable
cygwin1.dll's addresses to be translated but I didn't recognize

I also tried strace. I got very little information regarding whatever
the programming failure is:
-----------------8 cut here 8---------------------------------------
Installation of CLOCK_SYNC_GET_CAPS_EX.txt successful
  107 1561415 [main] cdiclient 4536 write: 54 = write(1, 0x801BA9F8, 54)
15458 1576873 [main] cdiclient 4536 fhandler_pty_slave::write: pty0,
write(0x801BA9F8, 17)
  121 1576994 [main] cdiclient 4536
fhandler_pty_common::process_opost_output: (1852): pty output_mutex
(0x150): waiting -1 ms
   94 1577088 [main] cdiclient 4536
fhandler_pty_common::process_opost_output: (1852): pty output_mutex:
  118 1577206 [main] cdiclient 4536
fhandler_pty_common::process_opost_output: (1891): pty
output_mutex(0x150) released
   99 1577305 [main] cdiclient 4536 write: 17 = write(1, 0x801BA9F8, 17)
--- Process 4536, exception c0000005 at 6115D363
77604 1654909 [main] cdiclient 4536 exception::handle: In
cygwin_except_handler exception 0xC0000005 at 0x6115D363 sp 0x28BFA4
  146 1655055 [main] cdiclient 4536 exception::handle: In
cygwin_except_handler signal 11 at 0x6115D363
-----------------8 cut here 8---------------------------------------

There is a write to stdout immediately preceding the crash. I would
not guess that that is causing the problem. The write is using the
same buffer as the one just before it and any others I found and the
return value is equal to the byte count argument.

The write to stdout precedes the part of the program where I instruct
the JavaScript interpreter to call a function defined by the file that
has been interpreted already. It's possible that in the course of
executing that JavaScript it called into one of my JavaScript
extensions and that the problem lies there. But I can't even identify
where within cygwin1 or any other executable the SEGV occurred.

1) Why is it not the case that gdb handles this SEGV in the usual
manner? It too just allows the stackdump to be made and lets me know
that the inferior has run its course.

2) What tools have I overlooked in debugging this?

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list