In addition, I've tried attaching to the iperf client with gdb, but,
the times that I've done so, I couldn't recreate the X or iperf crash.
> It's not coredumping? Maybe it's actually exiting instead of aborting or
> getting a signal.
A few (five or six) dead X sessions later I did get two coredumps,
only one of which contained a trace:
#0 thrkill () at -:3
#1 0x0000096cd93b9b7d in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
#2 0x0000096cf0c9b5e4 in *_libpthread_pthread_mutex_unlock
(mutexp=Variable "mutexp" is not available.
)
at /usr/src/lib/librthread/rthread_mutex.c:267
#3 0x0000096a082084e2 in thread_destroy () at Thread.c:113
#4 0x0000096cd93e0280 in _libc___cxa_finalize (dso=0x0) at
/usr/src/lib/libc/stdlib/atexit.c:159
#5 0x0000096cd93ddbef in _libc_exit (status=The value of variable
'status' is distributed across several
locations, and GDB cannot access its value.
) at /usr/src/lib/libc/stdlib/exit.c:57
#6 0x0000096a08202c91 in Listener::runAsDaemon () from /usr/local/bin/iperf
#7 0x0000096a0820176d in listener_spawn () from /usr/local/bin/iperf
#8 0x0000096a082086b7 in thread_run_wrapper (paramPtr=0x96a08207d70)
at Thread.c:254
#9 0x0000096cf0c9d85e in _rthread_start (v=Variable "v" is not available.
) at /usr/src/lib/librthread/rthread.c:115
#10 0x0000096cd942b79b in __tfork_thread () at
/usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75
#11 0x0000000000000000 in ?? ()
For the other gdb gave me a "warning: Couldn't find general-purpose
registers in core file."
> What's the exact output when you run it, and what's the exit status ($?) in
> the shell afterwards?
The last output I can catch is the iperf client during its run:
Client output: iperf -p 5001 -t 5 -c 10.0.0.2
------------------------------------------------------------
Client connecting to 10.0.0.2, TCP port 5001
TCP window size: 17.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.1 port 14152 connected with 10.0.0.2 port 5001
When I run from tmux to keep my shell, Mininet itself is still running
after X dies, and the shell that ran iperf returns 0.
> Might want to check /var/crash/ for coredumps too
Searching from / hasn't given me core dumps, except the two times that
I've mentioned above...
> akoshibe said that she is able to reproduce it all the time, every time
> (and I assume on bsd.mp).
Yes, it is on bsd.mp.
On Sun, Aug 13, 2017 at 8:58 AM, Pratik Vyas <[email protected]> wrote:
> * Philip Guenther <[email protected]> [2017-08-12 20:59:05 -0700]:
>
>
>> 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?
>>
>
> Yes, I see the same stacktrace as akoshibe. I tried compiling
> librthread with gcc and it still aborted (I think it ran longer though).
> I am able to reproduce the bug more reliably with bsd.sp and running
> bochs without gui, if that explains some part of the issue. I can run
> more scientific tests later today.
>
> akoshibe said that she is able to reproduce it all the time, every time
> (and I assume on bsd.mp).
>
>
> --
> Pratik
