Bug #14950
closedr64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c
Description
Eric,
Both windows builds (mswin & mingw) failed compiling thread.c.
Attached logs of both.
Thanks, Greg
Files
Updated by hsbt (Hiroshi SHIBATA) over 5 years ago
- File clang_macos.txt clang_macos.txt added
- Status changed from Open to Assigned
- Assignee set to normalperson (Eric Wong)
I got another error with macOS.
Updated by normalperson (Eric Wong) over 5 years ago
- Status changed from Assigned to Closed
Applied in changeset trunk|r64110.
thread.c: move ppoll wrapper into thread_pthread.c
thread_pthread.c relies on ppoll for rb_sigwait_sleep, so ensure
the compatibility wrapper is available for it.
[Bug #14950]
Reported-by: SHIBATA Hiroshi hsbt@ruby-lang.org
Reported-by: Greg L Greg.mpls@gmail.com
Updated by normalperson (Eric Wong) over 5 years ago
OK, r64110 should work. I mangled #ifdef nesting in r64109 :x
Updated by MSP-Greg (Greg L) over 5 years ago
@normalperson (Eric Wong) Eric,
Thanks. mswin passed, I haven't checked MinGW yet. Bad news is the Travis build had the following error in test-all:
1) Failure:
TestQueue#test_thr_kill [/home/travis/build/ruby/ruby/test/thread/test_queue.rb:153]:
only 0/250 done in 60 seconds.
Finished tests in 312.498195s, 63.4308 tests/s, 7303.2390 assertions/s.
19822 tests, 2282249 assertions, 1 failures, 0 errors, 78 skips
ruby -v: ruby 2.6.0dev (2018-07-30 trunk 64110) [x86_64-linux]
make: *** [yes-test-all] Error 1
Thanks, Greg
Updated by normalperson (Eric Wong) over 5 years ago
Greg.mpls@gmail.com wrote:
- Failure:
TestQueue#test_thr_kill [/home/travis/build/ruby/ruby/test/thread/test_queue.rb:153]:
only 0/250 done in 60 seconds.
Yep r64109 wasn't sufficient; but I'm working on it.
Updated by MSP-Greg (Greg L) over 5 years ago
Eric, r64111 passed Appveyor mswin & MingW (ruby-loco). Travis also.
Thanks, Greg
Updated by nobu (Nobuyoshi Nakada) over 5 years ago
- File crash-monitor.log crash-monitor.log added
- File ruby_2018-07-30-135956_ruby.crash ruby_2018-07-30-135956_ruby.crash added
Since r64107, make test-all
crashes by EINVAL at pthread_cond_timedwait
.
Attached logs at r64113.
Updated by nobu (Nobuyoshi Nakada) over 5 years ago
- Status changed from Closed to Assigned
Updated by normalperson (Eric Wong) over 5 years ago
nobu@ruby-lang.org wrote:
Since r64107,
make test-all
crashes by EINVAL atpthread_cond_timedwait
.
Attached logs at r64113.
I think r64117 will solve this (can't reproduce the problem, but
I understand it).
("process.c (waitpid_nogvl): prevent conflicting use of sleep_cond")
If not, we can try using:
#define USE_NATIVE_SLEEP_COND 0
Updated by nobu (Nobuyoshi Nakada) over 5 years ago
normalperson (Eric Wong) wrote:
nobu@ruby-lang.org wrote:
Since r64107,
make test-all
crashes by EINVAL atpthread_cond_timedwait
.
Attached logs at r64113.I think r64117 will solve this (can't reproduce the problem, but
I understand it).("process.c (waitpid_nogvl): prevent conflicting use of sleep_cond")
It still happens at r64123.
If not, we can try using:
#define USE_NATIVE_SLEEP_COND 0
It didn't help unfortunately.
Other than [BUG]
, drb/ut_large.rb can hang forever.
Updated by normalperson (Eric Wong) over 5 years ago
nobu@ruby-lang.org wrote:
normalperson (Eric Wong) wrote:
nobu@ruby-lang.org wrote:
Since r64107,
make test-all
crashes by EINVAL atpthread_cond_timedwait
.
Attached logs at r64113.I think r64117 will solve this (can't reproduce the problem, but
I understand it).("process.c (waitpid_nogvl): prevent conflicting use of sleep_cond")
It still happens at r64123.
If not, we can try using:
#define USE_NATIVE_SLEEP_COND 0It didn't help unfortunately.
Same backtraces as before?
Other than
[BUG]
, drb/ut_large.rb can hang forever.
How easy is this for you to reproduce? I ran "make exam" in a
loop for 24 hours while checking for unexpected core dumps before
committing r64107.
I wonder if condvars on OSX has a "memory" of which mutexes
are associated with it. If so, that would be a problem with
the rewritten GVL. So maybe a second condvar is necessary
in native_thread_data.
Updated by normalperson (Eric Wong) over 5 years ago
I wrote:
I wonder if condvars on OSX has a "memory" of which mutexes
are associated with it. If so, that would be a problem with
the rewritten GVL. So maybe a second condvar is necessary
in native_thread_data.
Maybe using separate condvar in r64124 will help.
(Maybe reverting r64123 helps, too)
Otherwise, maybe skip rb_native_cond_destroy
in native_thread_destroy but I don't think that
is the problem, here...
I need to go away for a few hours :<
Updated by nobu (Nobuyoshi Nakada) over 5 years ago
- Status changed from Assigned to Closed
normalperson (Eric Wong) wrote:
I wrote:
I wonder if condvars on OSX has a "memory" of which mutexes
are associated with it. If so, that would be a problem with
the rewritten GVL. So maybe a second condvar is necessary
in native_thread_data.Maybe using separate condvar in r64124 will help.
It seems fixed, thanks.
(Maybe reverting r64123 helps, too)
The crash had happened since r64110, I don't think it would help.
Updated by nobu (Nobuyoshi Nakada) over 5 years ago
- File ruby_2018-07-30-200222_ruby.crash ruby_2018-07-30-200222_ruby.crash added
- File crash.log crash.log added
- Status changed from Closed to Assigned
It still happens at TestOpen3#test_pipeline_start
.
And it seems less frequently with -O0 than with -O3.
Updated by nobu (Nobuyoshi Nakada) over 5 years ago
- Status changed from Assigned to Closed
Sorry, it was my mistake.