|
From: sfeam <sf...@us...> - 2015-02-13 06:24:47
|
On Thursday, 12 February 2015 05:08:09 PM Philipp K. Janert wrote:
>
> I seem to be encountering a problem when running
> splot in a loop.
>
> Assume this is in a file called "script.gp":
>
> t = 0
> while( 1 ) {
> t = t + 0.1
> splot [][][-1:1] cos(sqrt(x**2+y**2) - t)
> }
>
> Then
> load "script.gp"
> runs fine and can be stopped w/ Control-C.
>
> Now, let's assume that I let it run for a few
> seconds, then stop it, then "load" the script
> again. After about 2 or 3 repetitions of this
> cycle, gnuplot becomes unresponsive - sometimes
> printing the following message:
>
> wxt display server shutting down - no response
> Gnuplot not exited using gp_exit(). Exit handlers may not work
> correctly!
>
> Sometimes not even that. It has to be killed externally.
I suspect it would work to hit ctrl-C twice in quick
succession. There is an extra check for pretty much
exactly this case.
> Is this known behavior?
Well what did you expect?
You put the program in an infinite loop sending messages
from one process (gnuplot main program) to another
(outboard wxt driver running in a separate thread)
with no delay in the loop.
So the communication channel between them is presumably
saturated. Then you kill one end with ^C, probably
truncating the last message sent. Is it any
wonder that the other end of the channel is left waiting for
completion of that last message, which never comes?
> I have no idea how to
> debug this. (The problem is not an overflow
> of "t". I checked that.)
I don't really see anything to debug.
Try ^C ^C.
If that doesn't work then open up gdb -p <pid>
using the pid of the hung process and type
"where" to find where it is stuck.
But I'll bet it's waiting for a poll() operation
on the communication channel which is now defunct.
Ethan
|