|
From: Ethan M. <merritt@u.washington.edu> - 2012-03-18 03:48:08
|
On Saturday, 17 March 2012, Robert Dodier wrote:
> Take 2 -- I've now subscribed to gnuplot-beta ...
>
> Some additional info from Joaquin: he patched axis.c as suggested and
> the observed result is endless repetitions of
>
> gen_tics: top of loop; start=1.000000e+00, end=1.000000e+00,
> step=1.110223e-16, tic=1.000000e+00
>
> which shows that Gnuplot is indeed stuck in the loop in axis.c.
>
> Thanks for any light you can shed on this.
The section of code immediately above the site of your patch
exists exactly for the purpose of preventing such an infinite
loop. See axis.c lines 1098-1113.
It runs through the same for() loop with an internal
test for making progress through the requested range.
And in fact in your output dump, I can see that the warning
message from this test has been triggered:
warning: tick interval too small for machine precision
When it issues this warning, the code sets
step = end - start;
which is intended to guarantee that the subsequent loop
for (tic = start; tic <= end; tic += step)
will terminate the second time through.
This is confirmed by your debug output (at least to the
precision of the values printed). So it is annoying that
the code, although paranoid about precision, is apparently
not paranoid enough.
Does it do the same thing if you compile with optimization
level -O0 ?
Ethan
>
> Robert Dodier
>
>
> ---------- Forwarded message ----------
> From: Robert Dodier <rob...@gm...>
> Date: Sat, 17 Mar 2012 14:27:19 -0600
> Subject: Fwd: [Maxima] still having plotting problem
> To: gnu...@li..., ult...@gm...
>
> Joaquin, thanks for the GDB output.
>
> Looking at gnuplot/src/axis.c, I see that the call to gprintf
> is within a loop which won't terminate if end + step == end
> or step + end == step (this is possible for very small values of step).
>
> In order to verify whether that is actually happening, can you
> apply the attached patch (axis.c-patch) and try
> plot "maxout.gnuplot_pipes" in gnuplot again?
>
> If all is well, you should get a small number of output lines
> and then a plot. If it's actually stuck in that loop, you'll get unending
> output. Let us know how it plays out.
>
> best
>
> Robert Dodier
>
> PS to Gnuplot developers: Maxima generated maxout.gnuplot_pipes
> and then called Gnuplot to plot it. Gnuplot gets stuck.
> gdb_output.txt shows a stack trace. Gnuplot was pulled from CVS
> and compiled on a Ubuntu 10.10 or 11.10 system (I forget which)
> with x86_64 cpu if I remember correctly. When I try the same thing on
> my system (Gnuplot CVS on Ubuntu 8.04 on x86),
> the data are successfully plotted.
>
> ---------- Forwarded message ----------
> From: joaquin borges <ult...@gm...>
> Date: Sat, 17 Mar 2012 14:15:25 -0300
> Subject: Re: [Maxima] still having plotting problem
> To: Robert Dodier <rob...@gm...>
>
> On 03/17/2012 02:37 AM, Robert Dodier wrote:
> > Thanks for sending maxout.gnuplot_pipes.
> > When I run gnuplot (4.7 from cvs) it successfully plots the data.
> > So it's hard to figure out what's going on.
> >
> > One idea: can you run Gnuplot within gdb (debugger).
> > If the installed binary has been stripped of symbols,
> > try running the one from the build directory. e.g.
> >
> > $ cd<whatever>/gnuplot
> > $ gdb src/gnuplot
> > <now try the offending data file>
> >
> > When Gnuplot seems to wait forever, hit control-C
> > and then enter the command "where" in gdb.
> > It should give you a stack trace.
> >
> > best
> >
> > Robert Dodier
> >
> Thanks for your reply .
> The output of gdb is attached
> best
> joaquin
>
|