This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
pthread::atforkchild()
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin-developers at cygwin dot com>
- Date: Tue, 7 Mar 2006 13:25:08 -0000
- Subject: 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....