Dave Korn
Tue Mar 7 13:25:00 GMT 2006

  I see it calls a list of callback functions:

pthread::atforkchild ()
  MT_INTERFACE->fixup_after_fork ();

  __fp_unlock_all ();

  callback *cb = MT_INTERFACE->pthread_child;
  while (cb)
      cb->cb ();
      cb = cb->next;

  I got one of those SEGV-on-pressing-ctrl-C bugs, and fortunately error_start
jumped in and grabbed it.  The backtrace is slightly obfuscated by the
frameless function call to pthread::atforkchild() in between frok::child and
(some random address in the data segment of) cygiconv-2.

(gdb) bt
#0  0x0061bab1 in riscos1_wctomb () from /usr/bin/cygiconv-2.dll
#1  0x61051ff0 in frok::child (this=0x22eb70)
    at /usr/build/src-winsup/winsup/cygwin/
#2  0x61052d43 in fork () at /usr/build/src-winsup/winsup/cygwin/
#3  0x6109b89f in _sigfe ()
    at /usr/build/src-winsup/winsup/cygwin/cygtls.h:232
#4  0x0022ed18 in ?? ()
#5  0x6105db5a in malloc (size=4220284)
    at /usr/build/src-winsup/winsup/cygwin/
#6  0x100103f0 in ?? ()
#7  0x00000001 in ?? ()
#8  0x00000000 in ?? () from

  Looking at the thread data, it appears well formed, but the callback address
in the cb member of the one and only entry on the pthread_child list is
plainly wrong.

(gdb) print user_data
No symbol "user_data" in current context.
(gdb) print __cygwin_user_data
$1 = {initial_sp = 0x22ffa8 "", magic_biscuit = 168, dll_major = 1005,
  dll_minor = 20, impure_ptr_ptr = 0x61116168, envptr = 0x4146c4,
  malloc = 0x40eb90 <malloc>, free = 0x40e9d0 <free>,
  realloc = 0x40eb70 <realloc>, fmode_ptr = 0x4146c0, main = 0x40aad0 <main>,
  ctors = 0x40ed40, dtors = 0x40ed48, data_start = 0x40f000,
  data_end = 0x40f440, bss_start = 0x414000, bss_end = 0x414770,
  calloc = 0x40eb80 <calloc>, premain = {0x40ed10 <cygwin_premain0>,
    0x40ed00 <cygwin_premain1>, 0x40ecf0 <cygwin_premain2>,
    0x40ece0 <cygwin_premain3>}, run_ctors_p = 0, unused = {0, 0, 0, 0, 0, 0,
    0}, forkee = 0, hmodule = 0x400000, api_major = 0, api_minor = 155,
  unused2 = {0, 0, 0, 0, 0}, resourcelocks = 0x6111a4c0,
  threadinterface = 0x61152014, impure_ptr = 0x61115d40}
(gdb) print __cygwin_user_data->threadinterface
$2 = (MTinterface *) 0x61152014
(gdb) print *__cygwin_user_data->threadinterface
$3 = {concurrency = 0, threadcount = 1, pthread_prepare = 0x0,
  pthread_child = 0x100102b0, pthread_parent = 0x0}
(gdb) print __cygwin_user_data->threadinterface->pthread_child
$4 = (callback *) 0x100102b0
(gdb) print *__cygwin_user_data->threadinterface->pthread_child
$5 = {cb = 0x61bab0 <riscos1_wctomb+70640>, next = 0x0}

  I'm inclined to suspect that the pthread_child member may just be wrong.
The area of memory it points to looks like this:

(gdb) x/128xw 0x10010200
0x10010200:     0x6117f9dc      0x6117fa04      0x6117fa2c      0x6117fa54
0x10010210:     0x6117fa7c      0x6117fac4      0x00000000      0x00000013
0x10010220:     0x6573746e      0x00000063      0x00000000      0x00000013
0x10010230:     0x6e626d73      0x63657374      0x00000000      0x00000013
0x10010240:     0x74746f6e      0x00000079      0x00000000      0x0000002b
0x10010250:     0x6f727265      0x74735f72      0x3a747261      0x635c3a43
0x10010260:     0x69776779      0x69625c6e      0x64675c6e      0x78652e62
0x10010270:     0x00000065      0x0000003b      0x00000030      0x0061bc90
0x10010280:     0x0061b7e0      0x00000000      0x00000000      0x00000014
0x10010290:     0x00000000      0x00000000      0x00000000      0xffffffff
0x100102a0:     0x00000014      0x00000000      0x00000000      0x00000013
0x100102b0: >>> 0x0061bab0      0x00000000      0x00000000      0x00000023
0x100102c0:     0x7273752f      0x6e69622f      0x6779632f      0x6e6f6369
0x100102d0:     0x2e322d76      0x006c6c64      0x00000000      0x00000023
0x100102e0:     0x7273752f      0x6e69622f      0x6779632f      0x6c746e69
0x100102f0:     0x642e332d      0x00006c6c      0x00000000      0x0000001b
0x10010300:     0x00000000      0x10010318      0x00000000      0x00000000
0x10010310:     0x00636367      0x0000002b      0x7472612f      0x2f696d69
0x10010320:     0x6c6f6f74      0x79632f73      0x6e697767      0x6168732f
0x10010330:     0x6c2f6572      0x6c61636f      0x00000065      0x00000013
0x10010340:     0x00636367      0x00000000      0x00000000      0x00000033
0x10010350:     0x4d217b25      0x217b253a      0x253a4d4d      0x7c444d7b
0x10010360:     0x3a444d4d      0x2a6f7b25      0x514d2d3a      0x7d2a2520
0x10010370:     0x007d7d7d      0x00000000      0x00000030      0x00000ff3
0x10010380:     0x10011368      0x00000000      0x70676d2d      0x65732d72
0x10010390:     0x69732d74      0x312d657a      0x00000036      0x00000000
0x100103a0:     0x72616d2d      0x696d2d67      0x65722d6e      0x00312d67
0x100103b0:     0x72616d2d      0x616d2d67      0x65722d78      0x00342d67
0x100103c0:     0x72616d2d      0x65722d67      0x65722d74      0x00312d67
0x100103d0:     0x73756d2d      0x6f6d2d65      0x00696476      0x00000000
0x100103e0:     0x6e696d2d      0x72726574      0x73747075      0x00000000
0x100103f0:     0x00316363      0x00000000      0x0000452d      0x00000000

which is something else altogether: the strings in it include:

0x10010220:      "ntsec"
0x10010230:      "smbntsec"
0x10010240:      "notty"
0x10010250:      "error_start:C:\\cygwin\\bin\\gdb.exe"
0x100102c0:      "/usr/bin/cygiconv-2.dll"
0x100102e0:      "/usr/bin/cygintl-3.dll"
0x100102fc:      "\033"
0x10010304:      "\030\003\001\020"
0x10010310:      "gcc"
0x10010318:      "/artimi/tools/cygwin/share/locale"

so it looks like part of the heap.

  Can anyone think of any more useful data to gather before I dismiss the
crashed instance?

Can't think of a witty .sigline today....

More information about the Cygwin-developers mailing list