On Sun, Aug 13, 2017 at 10:00:24AM -0700, Ayaka Koshibe wrote: > 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
No one asked yet, but why is X dying ? Is there anything interesting in /var/log/Xorg.0.log ? I fail to see a connection with X there, so I'm wondering if you're running some strange window manager setup that gets killed by the signal sent to the application or if it's more weird. -- Matthieu Herrb
