|
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
|