This is the mail archive of the cygwin-developers 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]

pthread::atforkchild()



  I see it calls a list of callback functions:

----------------------------------<snip>----------------------------------
void
pthread::atforkchild ()
{
  MT_INTERFACE->fixup_after_fork ();

  __fp_unlock_all ();

  callback *cb = MT_INTERFACE->pthread_child;
  while (cb)
    {
      cb->cb ();
      cb = cb->next;
    }
}
----------------------------------<snip>----------------------------------

  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.

----------------------------------<snip>----------------------------------
(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/fork.cc:176
#2  0x61052d43 in fork () at /usr/build/src-winsup/winsup/cygwin/fork.cc:528
#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/malloc_wrapper.cc:72
#6  0x100103f0 in ?? ()
#7  0x00000001 in ?? ()
#8  0x00000000 in ?? () from
(gdb)
----------------------------------<snip>----------------------------------

  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.

----------------------------------<snip>----------------------------------
(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}
----------------------------------<snip>----------------------------------

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

----------------------------------<snip>----------------------------------
(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
----------------------------------<snip>----------------------------------

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?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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