This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Analyzing a SEG FAULT that gdb doesn't help with


'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
way).

        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
(0x75820000)
        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
anything.

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:
acquired
  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:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]