Bug #14950: r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c

• Status: Closed
• Assignee: normalperson (Eric Wong)
• Target version: -
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN

[MSP-Greg (Greg L)]

@normalperson (Eric Wong)

Eric,

Both windows builds (mswin & mingw) failed compiling thread.c.

Attached logs of both.

Thanks, Greg

[hsbt (Hiroshi SHIBATA)]

• 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.

[normalperson (Eric Wong)]

• 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 [e-mail]
Reported-by: Greg L [e-mail]

[normalperson (Eric Wong)]

OK, r64110 should work. I mangled #ifdef nesting in r64109 :x

[MSP-Greg (Greg L)]

@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

[normalperson (Eric Wong)]

[e-mail] wrote:

1. 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.

[MSP-Greg (Greg L)]

@normalperson (Eric Wong)

Eric, r64111 passed Appveyor mswin & MingW (ruby-loco). Travis also.

Thanks, Greg

[nobu (Nobuyoshi Nakada)]

• 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.

[nobu (Nobuyoshi Nakada)]

• Status changed from Closed to Assigned

[normalperson (Eric Wong)]

[e-mail] wrote:

Since r64107, make test-all crashes by EINVAL at pthread_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

[nobu (Nobuyoshi Nakada)]

normalperson (Eric Wong) wrote:

[e-mail] wrote:

Since r64107, make test-all crashes by EINVAL at pthread_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.

[normalperson (Eric Wong)]

[e-mail] wrote:

normalperson (Eric Wong) wrote:

[e-mail] wrote:

Since r64107, make test-all crashes by EINVAL at pthread_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.

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.

[normalperson (Eric Wong)]

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 :<

[nobu (Nobuyoshi Nakada)]

• 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.

[nobu (Nobuyoshi Nakada)]

• 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.

[nobu (Nobuyoshi Nakada)]

• Status changed from Assigned to Closed

Sorry, it was my mistake.