On Sat, 12 Aug 2017, akosh...@gmail.com wrote:
> The mininet network emulator includes an 'iperf' test case, which runs 
> an iperf client against a daemonized instance of an iperf server. The 
> client instance will occasionally hang, and when sent a sigint, cause X 
> to crash. Iperf itself will leave a core with the following backtrace:
> #0  thrkill () at -:3
> #1  0x000009fbbd34bb7d in _libc_abort () at 
> /usr/src/lib/libc/stdlib/abort.c:52
> #2  0x000009fb9efd1762 in _libpthread_pthread_mutex_unlock 
> (mutexp=0x9fbe2e418d4)
>     at /usr/src/lib/librthread/rthread_mutex.c:267

This is the "you unlocked a mutex that you didn't have locked: die die!" 
abort...and is the second weirdish pthread mutex consistency check failure 
seen since the switch to clang, the other being a similar mutex 
consistency check weirdness Pratik Vyas has seen with qemu, his being the 
"you're locking a mutex that you already have locked, with no timeout!" 
case.  Those both *could* be related to memory visibility issues, or code 
hoisting where the libpthread source assumes certain optimizations won't 
occur, but clang performs them.

It sounded like this isn't difficult to reproduce, or at least you've done 
so a couple times already.  I suggest rebuilding libpthread with gcc 
instead of clang and see if it's equally reproducible.  If not, well, you 
can get done what you originally were trying to do with iperf...

Pratik, did you say you tried recompiling all libpthread with gcc?

Philip Guenther

Reply via email to