| Summary: | sci-visualization/gnuplot-5.2.2 hangs upon saving when run with --persist | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Vince C. <vincent.cadet> |
| Component: | Current packages | Assignee: | Ulrich Müller <ulm> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | junghans, sci |
| Priority: | Normal | Keywords: | UPSTREAM |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Sample gnuplot command file
Sample data for example2.gp GDB execution gnuplot trace while hung |
||
|
Description
Vince C.
2018-04-03 09:01:01 UTC
Created attachment 526426 [details]
Sample data for example2.gp
I shall add: there's no "Save" dialog window that shows up, gnuplot immediately hangs upon clicking the "Save" button. By "save button" you mean "Export plot to file", I suppose? (It shows in the second position from the left here, but only if I uncomment the "set term wxt ..." line in example2.gp.) Can you run gnuplot under gdb and produce a backtrace, so we can see where it hangs? Created attachment 530774 [details]
GDB execution
I'm sorry, I've just seen your comment. Fact is I absolutely have no idea how to do what you're asking (I've never used gdb, not a single time, don't even know how to use it). I have emerged gdb and run gnuplot through it. Attached is what it does. Note that gdb says, if I've got it right, that the main process exited normally and I even quit gdb... but the plot window is still visible! How come?
BTW, yes, that's the «Export plot to file» that I was talking about.
This looks like gnuplot is forking, and gdb is following the wrong process. You can try the following: 1. Start "gdb --args gnuplot ..." 2. At the (gdb) prompt, type "set follow-fork-mode child" 3. Type "run" 4. Reproduce the error in gnuplot 5. When gnuplot hangs, press Ctrl-C in gdb 6. Get a backtrace with "bt" or "bt full" If the above doesn't work, you can alternatively try to attach to the running process: 1a. Start gnuplot (without gdb) 2a. Reproduce the error 3a. Look up gnuplot's process id with "ps" 4a. Attach to the running gnuplot process with "gdb -p <pid>" 5a. Get a backtrace Created attachment 531026 [details]
gnuplot trace while hung
Thanks a lot for the hint.
Something interesting though. I've tried to attach gdb to the forked, running process (so I typed "continue") and clicked the export button, which made gnuplot hang as expected. But then even pressing Ctrl-C in gdb didn't work; all it did was to output "^C" and then nothing, no prompt — it's a deadlock, I presume. So I've had to attach gdb to the *hung* process instead. Now I've got a full trace, 84 nested calls.
Also note (I always forget that) forcibly closing the gnuplot window is not enough. I must "killall gnuplot" anyway. That's probably a consequence of the alleged deadlock.
(In reply to Vince C. from comment #6) > [...] I always forget that) forcibly closing the gnuplot window is not > enough. I must "killall gnuplot" anyway. Erm... looks like I forgot that I didn't forget to add that to the initial description. They must have taken my marbles away. Can you call the sanatorium for me please...? Thank you for the backtrace. This looks like the following upstream issue: https://sourceforge.net/p/gnuplot/bugs/1513/ Problem still present with gnuplot-5.2.6 and gvfs-1.38.2. Issue closed upstream anyway... Issue reopened upstream: https://sourceforge.net/p/gnuplot/bugs/2185/ Closing, because the upstream bug is fixed. Please reopen if the problem still exists with >=gnuplot-5.4.3. |
