From: Ethan A M. <merritt@u.washington.edu> - 2005-09-19 04:10:49
|
On Sunday 18 September 2005 08:41 pm, you wrote: > Is this more revealing? Well, no. That's a trace of gnuplot itself. But it's the auxilliary program gnuplot_x11 that is actually crashing. So all this trace tells us is that gnuplot is unhappy that gnuplot_x11 crashed. > If it is not, what can I do to make it more revealing? Here is what you can do to isolate gnuplot_x11, and trace its behaviour. First save the stream of commands that would normally go from gnuplot to gnuplot_x11. Put them in a separate file: gnuplot> set term xlib gnuplot> set output "bug.x" gnuplot> plot x,x gnuplot> quit Now feed that file to gnuplot_x11 to confirm the problem: gnuplot_x11 --noevents < bug.x Assuming that still exhibits the problem, run it again using the valgrind toolset: valgrind --tool=addrcheck --leak-check=yes --leak-resolution=med \ --log-file=valgrind ./gnuplot_x11 < bug.x That should produce a log file "valgrind.pid????", where ???? is the process number, that contains an analysis of various sorts of memory problems, illegal accesses, and so on. I warn you that I have done this on several machines (but not on Fedora Core 4 because I don't have a machine set up with it). Under Mandrake 10.0, Valgrind finds seveal leaks and unitialized memory accesses inside the XFree86 libraries themselves, but nothing of note in gnuplot_x11. Under Mandrake 10.1, which uses X.org rather than XFree86, valgrind finds no errors of note. So I'm inclinded to guess that you have either an X error, or a compiler error. As I understand it, Fedora 4 ships with gcc 4.something_bleeding_edge. Depending on what valgrind finds or doesn't find, you might want to try installing gcc 3.4 or whatever Fedora provides as a fallback. If that fixes it, then report it through Redhat as a compiler bug. Otherwise, I'd be very interested to hear what valgrind finds. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |