From: "Eregon (Benoit Daloze)" Date: 2012-11-04T21:09:25+09:00 Subject: [ruby-core:48849] [ruby-trunk - Bug #6825] forking and pthread_cond_timedwait: Invalid argument (EINVAL) on OS X / 1.9.3-p194 Issue #6825 has been updated by Eregon (Benoit Daloze). I poked around an produced a core dump (the bug would not reproduce under gdb with a breakpoint set). Arguments to pthread_cond_timedwait() seem valid, in particular the timespec is about 500ms in the future. Other calls to pthread_cond_timedwait() always return ETIMEDOUT or 0. I saw rb_thread_t::native_thread_data.sleep_cond was weirdly initialized. It is not initialized in native_thread_init() if HAVE_PTHREAD_CONDATTR_INIT is undefined. And it is used in any case in ubf_pthread_cond_signal(). Maybe checks for HAVE_PTHREAD_CONDATTR_INIT should not be done in native_thread_init() and native_thread_destroy() since these functions already do the right checks? This should be unrelated though, since OS X has pthread_condattr_init(). It might be related to GVL release by multiple threads but I have no clue. It does not seem related directly to the parallel DNS resolution, since some traces have only threads in native_cond_timedwait(). And from the "only reproducible on snow-leopard" argument, it seems snow-leopard pthread's bug. @kosaki @mrkn Would it be useful if I could provide you the core dump and other info? ---------------------------------------- Bug #6825: forking and pthread_cond_timedwait: Invalid argument (EINVAL) on OS X / 1.9.3-p194 https://bugs.ruby-lang.org/issues/6825#change-32339 Author: xentronium (Mark A) Status: Assigned Priority: Normal Assignee: Eregon (Benoit Daloze) Category: Target version: ruby -v: ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin10.8.0] https://gist.github.com/47e48301aea114e7b1d3 here is the gist with required setup to reproduce bug. Also crash log and stdout. It seems that forking is essential for this setup to crash. Also, if you use database connection in some way prior to forking, it might not crash (however, with more complex code it still does). ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin10.8.0] OS X 10.6.8 hostinfo output: Mach kernel version: Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 Kernel configured for up to 4 processors. 2 processors are physically available. 4 processors are logically available. Processor type: i486 (Intel 80486) Processors active: 0 1 2 3 Primary memory available: 8.00 gigabytes Default processor set: 88 tasks, 627 threads, 4 processors Load average: 0.55, Mach factor: 3.43 compiled with gcc version: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) -- http://bugs.ruby-lang.org/