Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability () -+-- Reporter: j.waldmann | Owner: simonmar Type: bug | Status: closed Priority: high| Milestone: 7.4.2 Component: Runtime System |Version: 7.4.1 Resolution: fixed | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by pcapriotti): * status: merge = closed * resolution: = fixed Comment: Merged as 20906163a6aee2b76de240c4171928f83a5d9077. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability ()
-+--
Reporter: j.waldmann | Owner: simonmar
Type: bug | Status: new
Priority: high| Milestone: 7.4.2
Component: Runtime System |Version: 7.4.1
Resolution: | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: Runtime crash | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
-+--
Comment(by marlowsd@…):
commit 734f1d484b12b785795b249b4116cfb4817ab55d
{{{
Author: Simon Marlow marlo...@gmail.com
Date: Wed Mar 28 11:45:39 2012 +0100
Fix a bug in threadStackOverflow() (maybe #5214)
If we overflow the current stack chunk and copy its entire contents
into the next stack chunk, we could end up with two UNDERFLOW_FRAMEs.
We had a special case to catch this in the case when the old stack
chunk was the last one (ending in STOP_FRAME), but it went wrong for
other chunks.
I found this bug while poking around in the core dump attached to
options and running the nofib suite: imaginary/wheel_sieve2 crashed
with +RTS -kc600 -kb300.
I don't know if this is the cause of all the symptoms reported in
rts/Threads.c | 35 ++-
1 files changed, 22 insertions(+), 13 deletions(-)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#comment:12
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability () -+-- Reporter: j.waldmann | Owner: simonmar Type: bug | Status: merge Priority: high| Milestone: 7.4.2 Component: Runtime System |Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by simonmar): * status: new = merge Comment: @vshabanov: thanks very much for the core dump. I poked around in it and did manage to find a bug in the RTS, the fix for which I have just committed (see above). I don't know whether this is the only bug, but it is certainly ''a'' bug. We'll close the ticket after the patch has been merged, on the optimistic assumption that the bug is fixed. Please try again with the 7.4.2 release candidate if possible, and re-open the ticket if you still have problems. Thanks again for the report. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability () -+-- Reporter: j.waldmann | Owner: simonmar Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: Runtime System |Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by simonmar): * owner: = simonmar * priority: normal = high * milestone: = 7.4.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability () -+-- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System |Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Comment(by vshabanov): I found some stack overflows in my program. Fixed one of them and sigsegvs are gone. Seems that stack overflow + exception handling (overflow is caught and written to log) + many threads (~ 100) leads to this error. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability () -+-- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System |Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Changes (by simonmar): * difficulty: = Unknown Comment: Thanks for the report. I've had a look at the code and can't see anything obvious that would lead to those assertion failures, and the `+RTS -Ds` output doesn't contain any useful clues either. Do you have a core dump corresponding to the first failure (the `ASSERTION FAILED: file rts/Schedule.c, line 1268`)? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability () -+-- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System |Version: 7.4.1 Resolution: | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: -+-- Comment(by vshabanov): You can download executable (won't work without additional setup, just for gdb), core and -Ds output from http://stuff.bazqux.com/5214-N2-NoSTM.tar.bz2 Program with -N2 and QSem+MVar pool worked all the night. But when compiled with -debug it fails quite fast. It even faulted with pool size 1. With -N1 program seems to work even with -debug. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability ()
-+--
Reporter: j.waldmann | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Runtime System |Version: 7.4.1
Resolution: | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: Runtime crash | Difficulty:
Testcase: | Blockedby:
Blocking: |Related:
-+--
Changes (by vshabanov):
* cc: vshabanoff@… (added)
* status: closed = new
* version: 7.0.3 = 7.4.1
* resolution: wontfix =
Comment:
I've got similar bug just after I've started using STM (through
Network.Riak.Connection.Pool). I'm also using FFI (curl hsdns).
It starting to appear with -N2.
I've compiled with -debug and got
{{{
Queue: internal error: ASSERTION FAILED: file rts/Schedule.c, line 1268
(GHC version 7.4.1 for x86_64_unknown_linux)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
}}}
gdb backtrace
{{{
Core was generated by `./Queue +RTS -N2'.
Program terminated with signal 6, Aborted.
#0 0x7f394f848405 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x7f394f848405 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7f394f84b680 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x02116fa2 in rtsFatalInternalErrorFn (
s=0x21e64c8 ASSERTION FAILED: file %s, line %u\n, ap=0x7f394b3f4870)
at rts/RtsMessages.c:170
#3 0x02116b5b in barf (
s=0x21e64c8 ASSERTION FAILED: file %s, line %u\n)
at rts/RtsMessages.c:42
#4 0x02116bbe in _assertFail (filename=0x21e7541
rts/Schedule.c,
linenum=1268) at rts/RtsMessages.c:57
#5 0x0211d6e4 in scheduleHandleThreadFinished (cap=0x27a40d0,
task=0x27fe060, t=0x7f3943ae05d8) at rts/Schedule.c:1268
#6 0x0211c891 in schedule (initialCapability=0x27a40d0,
task=0x27fe060) at rts/Schedule.c:545
#7 0x0211ea47 in scheduleWaitThread (tso=0x7f394c52d488,
ret=0x7f394b3f4ab0, pcap=0x7f394b3f4ab8) at rts/Schedule.c:2154
#8 0x02113f1f in rts_evalIO (cap=0x7f394b3f4ab8,
p=0x7f394c52d0d8,
ret=0x7f394b3f4ab0) at rts/RtsAPI.c:456
#9 0x01242d82 in NetworkziCurlziEasy_dmd3 ()
#10 0x7f3950dcab48 in ?? ()
from /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#11 0x7f3950de5434 in ?? ()
from /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#12 0x7f3950ddec42 in ?? ()
from /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#13 0x7f3950de9230 in ?? ()
from /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#14 0x7f3950de9ba5 in curl_multi_perform ()
from /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#15 0x00718297 in sjos_info ()
#16 0x in ?? ()
}}}
You can download -Ds output from http://stuff.bazqux.com/Ds.bz2
With parallel GC disabled I'm getting different error (and I'm getting it
much faster -- usually in a minute from program start)
{{{
Queue: internal error: ASSERTION FAILED: file rts/Capability.c, line 444
(GHC version 7.4.1 for x86_64_unknown_linux)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
}}}
gdb backtrace:
{{{
Core was generated by `./Queue +RTS -N8 -I10 -qg'.
Program terminated with signal 6, Aborted.
#0 0x7f0785c74405 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x7f0785c74405 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7f0785c77680 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x02116fa2 in rtsFatalInternalErrorFn (
s=0x21e64c8 ASSERTION FAILED: file %s, line %u\n, ap=0x7f077a0fcb80)
at rts/RtsMessages.c:170
#3 0x02116b5b in barf (
s=0x21e64c8 ASSERTION FAILED: file %s, line %u\n) at
rts/RtsMessages.c:42
#4 0x02116bbe in _assertFail (filename=0x21e41de
rts/Capability.c,
linenum=444) at rts/RtsMessages.c:57
#5 0x02a9 in releaseCapability_ (cap=0x3db9f70,
always_wakeup=rtsFalse) at rts/Capability.c:444
#6 0x0211160c in releaseCapabilityAndQueueWorker (cap=0x3db9f70)
at rts/Capability.c:565
#7 0x02111b50 in yieldCapability (pCap=0x7f077a0fcd48,
task=0x3e5b2e0)
at rts/Capability.c:692
#8 0x0211cc1f in scheduleYield (pcap=0x7f077a0fcd70,
task=0x3e5b2e0)
at rts/Schedule.c:659
#9 0x0211c245 in schedule (initialCapability=0x3db9f70,
task=0x3e5b2e0) at rts/Schedule.c:332
#10 0x0211ea47 in scheduleWaitThread (tso=0x7f077b1075b8,
ret=0x7f077a0fce50, pcap=0x7f077a0fce98) at rts/Schedule.c:2154
#11 0x02113f8e in
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability ()
-+--
Reporter: j.waldmann | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Runtime System |Version: 7.4.1
Resolution: | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: Runtime crash | Difficulty:
Testcase: | Blockedby:
Blocking: |Related:
-+--
Comment(by vshabanov):
It seems that error is actually unrelated to STM. I replaced resource-pool
with simple QSem+MVar[Connection] pool and still getting errors.
Another one this time
{{{
Core was generated by `./Queue +RTS -N8 -I10 -S -sstderr -qg'.
Program terminated with signal 11, Segmentation fault.
#0 0x02111f88 in suspendThread ()
(gdb) bt
#0 0x02111f88 in suspendThread ()
#1 0x0208d4c2 in s3Q3_info ()
#2 0x in ?? ()
}}}
With just -N2 option program seems to work (at least for last half an
hour).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#comment:6
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability () -+-- Reporter: j.waldmann | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System |Version: 7.0.3 Resolution: wontfix | Keywords: Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: x86_64 (amd64) Failure: Runtime crash | -+-- Comment(by simonmar): Rather than wontfix, probably worksforme is a more appropriate assessment here without more information. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability () -+-- Reporter: j.waldmann | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System |Version: 7.0.3 Resolution: wontfix | Keywords: Testcase: | Blockedby: Difficulty: | Os: Linux Blocking: | Architecture: x86_64 (amd64) Failure: Runtime crash | -+-- Changes (by igloo): * status: new = closed * resolution: = wontfix Comment: j.waldmann, please reopen this ticket (or open a new one) if you manage to get either a testcase, or the info Simon requested. Thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability () ---+ Reporter: j.waldmann |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Runtime System | Version: 7.0.3 Keywords: | Testcase: Blockedby: | Difficulty: Os: Linux | Blocking: Architecture: x86_64 (amd64) | Failure: Runtime crash ---+ Comment(by simonmar): If you can't boil it down to a smaller example, please try these steps: * compile with `-debug` and try again. This will hopefully turn the segfault into an ASSERT failure * find the smallest `-N` value that still triggers the bug * run the program with `+RTS -Ds`, capture the output, and attach it to the ticket (or send it to me if it's too big to attach). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5214#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5214: SIGSEGV in yieldCapability ()
#5214: SIGSEGV in yieldCapability ()
---+
Reporter: j.waldmann | Owner:
Type: bug | Status: new
Priority: normal | Component: Runtime System
Version: 7.0.3 |Keywords:
Testcase: | Blockedby:
Os: Linux |Blocking:
Architecture: x86_64 (amd64) | Failure: Runtime crash
---+
Comment(by j.waldmann):
Here is the end of an strace of a run that leads to a crash:
{{{
...
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
sched_yield() = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x19ee4fc, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee4f8, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x1a1826c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x1a18268, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19b381c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19b3818, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edb2c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edb28, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd4c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edd48, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd78, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932a88, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x19ee35c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee358, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19ee388, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932e08, FUTEX_WAKE_PRIVATE, 1) = 1
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
sched_yield() = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x19ee4fc, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee4f8, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x1a1826c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x1a18268, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19b381c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19b3818, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edb2c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edb28, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd4c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edd48, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd78, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932a88, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x19ee35c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee358, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19ee388, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932e08, FUTEX_WAKE_PRIVATE, 1) = 1
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
sched_yield() = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x19ee4fc, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee4f8, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x1a1826c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x1a18268, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19b381c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19b3818, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edb2c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edb28, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd4c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edd48, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd78, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932a88, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x19ee35c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee358, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19ee388, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932e08, FUTEX_WAKE_PRIVATE, 1) = 1
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
sched_yield() = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x19ee4fc, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee4f8, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x1a1826c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x1a18268, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19b381c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19b3818, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edb2c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edb28, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd4c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19edd48, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19edd78, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932a88, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x19ee35c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x19ee358, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_GT, 1}) = 1
futex(0x19ee388, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x1932e08, FUTEX_WAKE_PRIVATE, 1) = 1
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
sched_yield() = 0
sched_yield()
