Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#991 wxt terminal deadlocks in wxt_atexit() if window was xkilled

closed-accepted
nobody
None
5
2015-03-23
2011-05-18
Andreas Beckmann
No

The following small gnuplot script triggers a deadlock in gnuplot if the wxt windows was terminated by xkill (or something similar happened, e.g. running gnuplot remotely via ssh in a screen and the connection gets interrupted, after reconnecting to the screen the old X connection is no longer there):

plot x
print "use xkill to terminate the plot window, then press return"
pause -1
print "closing window"
set term wxt close
print "window closed

output looks like this:

command.c:358 Input line: "print "use xkill to terminate the window, then press return""
use xkill to terminate the window, then press return
command.c:358 Input line: "pause -1"
<unknown>: Fatal IO error 0 (Success) on X server localhost:10.0.

command.c:358 Input line: "print "closing window""
closing window
command.c:358 Input line: "set term wxt close"
^Cwxterminal/wxt_gui.cpp:3371 custom interrupt handler called
^Z
[1]+ Stopped src/gnuplot ../test2.gnuplot

A deadlock seems to occur first in the wxt thread when wxt_atexit is being executed, when calling wxt_MutexGuiEnter()
Later on the terminal thread deadlocks, too, when trying to terminate the wxt terminal window.

Since wxt_atexit() traps SIGINT it's not possible to terminate the stuck process with Ctrl-C, I have to use Ctrl-Z and kill %1

This behavior was introduced in the following commit (I imported the gnuplot CVS into git so that I could run git-bisect):

Author: tlecomte <tlecomte>
Date: Tue Jun 5 21:07:38 2007 +0000
Fix commit of 2007-05-23

Before the behavior as follows: forcible termination of the window caused an early abort of gnuplot, introduced in

Author: tlecomte <tlecomte>
Date: Wed May 23 21:51:18 2007 +0000
Add/fix comments and debugging messages, simplify wxt_atexit, wxtcleanup

and before that the gnuplot script successfully finished its remaining tasks and gnuplot terminated normally.

In my case I use a gnuplot script that first plots in wxt, waits for a return and thereafter replots the graph as postscript/pdf/png. All this is happening on a remote machine, therefore ssh, and in a long running screen session. I usually have some wxt plots open to compare things and from time to time the ssh session closes (e.g. when I suspend my laptop to move between office/home). So the stuck gnuplot processes are annoying, if it could be terminated by Ctrl-C this would be fine (but 4.2.x behavior where it terminates regularily would be even better).

Andreas

Discussion

  • Ethan Merritt
    Ethan Merritt
    2011-05-25

    I can confirm the reported behavior, but I don't know how to fix it. Suggestions?

     
  • As this looks like a locking issue, valgrind might help to debug it.
    I just tried running gnuplot in
    valgrind --tool=helgrind
    and it complains a lot about lock usage (I removed all the stack traces, keeping only the headlines):

    ==22065== Thread #1 is the program's root thread
    ==22065== Thread #1: Attempt to re-lock a non-recursive lock I already hold
    ==22065== Lock was previously acquired
    ==22065== Thread #2 was created
    ==22065== Thread #1: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion
    ==22065== Thread #1: lock order "0xD18D3E0 before 0xD2CB9C0" violated
    ==22065== Thread #1: lock order "0xD18D3E0 before 0xD2CB9C0" violated
    ==22065== Thread #1: lock order "0xD18D3E0 before 0xD2CB9C0" violated
    ==22065== Thread #1: lock order "0xD18D3E0 before 0xD2CB9C0" violated
    ==22065== Thread #1: lock order "0xD18D3E0 before 0xD2CB9C0" violated
    ==22065== Thread #1: lock order "0xD18D3E0 before 0xD2CB9C0" violated
    ==22065== Thread #2: Attempt to re-lock a non-recursive lock I already hold
    ==22065== Lock was previously acquired
    ==22065== Thread #1: Exiting thread still holds 1 lock
    ==22065== Thread #2: Exiting thread still holds 1 lock

    Even if I don't xkill the plot window, most of these errors are listed and thereafter the program exits with

    ==21942== Thread #1's call to pthread_mutex_destroy failed
    ==21942== with error code 16 (EBUSY: Device or resource busy)
    ==21942== Thread #1: Exiting thread still holds 1 lock

    You need to have the debug symbols for all of the libraries installed and an unstripped gnuplot with debug symbols so that the stack traces will be useful.

    I hope this helps.

    Andreas

     
  • Ethan Merritt
    Ethan Merritt
    2013-05-31

    • status: open --> closed-accepted
    • Group: --> 5.0
     
  • Ethan Merritt
    Ethan Merritt
    2013-05-31

    4.7 CVS version of wxt_gui.cpp now forcibly exits if a second ^C is seen before any response to the first is triggered. This lets you break out of the deadlocked state by hitting ^C twice. It's not a very satisfactory solution, but certainly better than requiring external intervention to kill the deadlocked process.