Menu
▾
▴
gnuplot-beta
|
From: Philipp K. J. <ja...@ie...> - 2007-10-25 04:44:29
|
I seem to have run across a problem with
set hidden3d undefined x
in Gnuplot 4.2.2 on Linux (detailed version
info at the end of this message).
The following two commands will crash
gnuplot:
set hidden3d undefined 2
splot [][][:1] 10*exp(-(x**2 + y**2))
Gnuplot dies with the following message:
hidden3d.c:776: store_polygon: Assertion `p->ymax <= surface_scale' failed.
Note that the plot command is such that
there are values of the function outside
the plot range (z-range).
I get the same effect for
set hidden3d undefined 2
and
set hidden3d undefined 3
Only level = 1 is ok.
This occurs for both wxt and x11 terminals.
(I didn't try any others.)
Is this a known problem?
Best,
Ph.
Below the output of show version long:
G N U P L O T
Version 4.2 patchlevel 2
last modified 31 Aug 2007
System: Linux 2.6.18.2-34-default
Copyright (C) 1986 - 1993, 1998, 2004, 2007
Thomas Williams, Colin Kelley and many others
Type `help` to access the on-line reference manual.
The gnuplot FAQ is available from http://www.gnuplot.info/faq/
Send bug reports and suggestions to
<http://sourceforge.net/projects/gnuplot>
Compile options:
-READLINE +LIBREADLINE +HISTORY +BACKWARDS_COMPATIBILITY +BINARY_DATA
+GD_PNG +GD_JPEG +GD_TTF +GD_GIF +ANIMATION
-NOCWDRC +X11 +X11_POLYGON +MULTIBYTE +USE_MOUSE +HIDDEN3D_QUADTREE
+DATASTRINGS +HISTOGRAMS +OBJECTS +STRINGVARS +MACROS +IMAGE
|
|
From: Daniel J S. <dan...@ie...> - 2007-11-16 06:36:51
|
> Note that the plot command is such that > there are values of the function outside > the plot range (z-range). > Is this a known problem? See bug [ 1728063 ] hidden lines, scale assertion failure The patch range checks and looks fine. The consequence is that when all line segments get pushed off the edge of the screen it effectively outdoes any benefit quadtree gives because all the elements end up in the outermost bin of the division grid. But why a user would want to push the plot too far off the screen I'm not sure. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-10-25 05:11:05
|
On Wednesday 24 October 2007 21:44, Philipp K. Janert wrote: > > The following two commands will crash > gnuplot: > set hidden3d undefined 2 > splot [][][:1] 10*exp(-(x**2 + y**2)) I'm afraid I don't know what the 'undefined' option is supposed to do, so I can't comment on whether this is supposed to work. > Gnuplot dies with the following message: > hidden3d.c:776: store_polygon: Assertion `p->ymax <= surface_scale' failed. But that message arises, I think, simply because of the range and scale used for plotting. I've been getting this message a lot recently if I use the middle mouse button in splot mode to try to rescale the plot. I have tried replacing the assert statements with non-fatal warnings. That allows many mouse operations to succeed that otherwise would have triggered the assertion failure, but eventually it dies elsewhere on a segfault. So yes, there are serious known problems with the hidden3d scaling code. But I think that the 'undefined' option is not the cause; it just perturbs the chance of hitting the true bug. > Note that the plot command is such that > there are values of the function outside > the plot range (z-range). > > I get the same effect for > set hidden3d undefined 2 > and > set hidden3d undefined 3 > Only level = 1 is ok. > > This occurs for both wxt and x11 terminals. > (I didn't try any others.) > > Is this a known problem? > > Best, > > Ph. > > > > > > > Below the output of show version long: > > G N U P L O T > Version 4.2 patchlevel 2 > last modified 31 Aug 2007 > System: Linux 2.6.18.2-34-default > > Copyright (C) 1986 - 1993, 1998, 2004, 2007 > Thomas Williams, Colin Kelley and many others > > Type `help` to access the on-line reference manual. > The gnuplot FAQ is available from http://www.gnuplot.info/faq/ > > Send bug reports and suggestions to > <http://sourceforge.net/projects/gnuplot> > > Compile options: > -READLINE +LIBREADLINE +HISTORY +BACKWARDS_COMPATIBILITY +BINARY_DATA > +GD_PNG +GD_JPEG +GD_TTF +GD_GIF +ANIMATION > -NOCWDRC +X11 +X11_POLYGON +MULTIBYTE +USE_MOUSE +HIDDEN3D_QUADTREE > +DATASTRINGS +HISTOGRAMS +OBJECTS +STRINGVARS +MACROS +IMAGE > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Thomas S. <t.s...@fz...> - 2007-10-25 10:49:25
|
interesting, gnuplot 4.0 doesn't crash, it seems that repairing some bugs (too large z-values flip to negative(?) values when making the z-scaling too large with the middle mouse button, but, gp 4.0 doesn't crash!) introduced this behaviour. the assertion goes away when 'min' or 'max' are compared to 'surface_zscale' and not to 'surface_scale' as it is now in 'hidden3d.c'. (z-values don't have anything to do with the scaling of the x-y-plane) but then i run into this segmentation fault when 'surface_zscale' is around '10'. -- View this message in context: http://www.nabble.com/Gnuplot-crashing-for-%22hidden3d-undefined%22---tf4688619.html#a13404317 Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
|
From: Thomas S. <t.s...@fz...> - 2007-10-28 10:25:04
|
Hans-Bernhard Br=C3=B6ker-2 wrote: >=20 >> the macros 'GET_MIN' and 'GET_MAX' should be different for checking >> min or max values in x- and y- and for checking min or max values in >> z-direction. >=20 > No. At the point in the algorithm where these are used, x, y and z have > already been turned into view coordinates. They are checked against the > view frustum, >=20 ok, yes, but, we are scaling the whole plot by moving the mouse sidewards while pressing the middle button. there the comparison of the maximum x-, y-, z-values to 'surface_scale' is the right one, and 'surface_scale' increases when zooming in. the assertion mainly accurs when scaling only the z-coordinate (in plot coordinates) by moving the mouse pointer up (middle button pressed). here, 'surface_scale' is not affected at all, 'surface_zscale' increases instead. but the comparison of the maximum y-value (in view coordinates) is done against 'surface_scale' which doesn't change at all during this process. that's why i think that the y-min/max-values should be checked against some combination of 'surface_scale' and 'surface_zscale'. --=20 View this message in context: http://www.nabble.com/Gnuplot-crashing-for-%2= 2hidden3d-undefined%22---tf4688619.html#a13451968 Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
|
From: Thomas S. <t.s...@fz...> - 2007-10-25 11:03:03
|
oh, it's a little bit more difficult: the macros 'GET_MIN' and 'GET_MAX' should be different for checking min or max values in x- and y- and for checking min or max values in z-direction. who introduced the 'assert' statements into the 'GET_MIN' and 'GET_MAX' macros and why? Thomas Sefzick wrote: > > interesting, gnuplot 4.0 doesn't crash, it seems that repairing some > bugs (too large z-values flip to negative(?) values when making the > z-scaling too large with the middle mouse button, but, gp 4.0 doesn't > crash!) > introduced this behaviour. > > the assertion goes away when 'min' or 'max' are compared to > 'surface_zscale' and not to 'surface_scale' as it is now in 'hidden3d.c'. > (z-values don't have anything to do with the scaling of the x-y-plane) > > but then i run into this segmentation fault when 'surface_zscale' is > around '10'. > > -- View this message in context: http://www.nabble.com/Gnuplot-crashing-for-%22hidden3d-undefined%22---tf4688619.html#a13404528 Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
|
Re: Ggnuplot-beta@lists.sourceforge.netnuplot crashing
=?iso-8859-1?q?for=09?="hidden3d undefined" ?
From: Ethan A M. <merritt@u.washington.edu> - 2007-10-27 22:08:33
|
On Saturday 27 October 2007 13:18, Hans-Bernhard Br=F6ker wrote:
> Thomas Sefzick wrote:
>=20
> > who introduced the 'assert' statements into the 'GET_MIN' and 'GET_MAX'
> > macros and why?
>=20
> I did, for the reason assert() is pretty much always used: to ensure=20
> that worse, much harder to find problems don't appear further down the=20
> processing pipeline --- you did mention segfaults and strange=20
> wrap-around artifacts earlier...
=46or debugging - yes.
It would be more user friendly not to exit the program, however.
Instead it should be possible to disable the mouse interaction=20
until the next replot, and bail to the command line with an error
message int_error(). =20
Do you see any problems if the assert() statements were replaced by
if (whatever) {
[do something to disable mousing];
int_error(NO_CARET, "error message");
}
=2D-=20
Ethan A Merritt
|
|
From: <HBB...@t-...> - 2007-10-27 23:13:15
|
Ethan A Merritt wrote:
> On Saturday 27 October 2007 13:18, Hans-Bernhard Bröker wrote:
>> I did, for the reason assert() is pretty much always used: to ensure
>> that worse, much harder to find problems don't appear further down the
>> processing pipeline --- you did mention segfaults and strange
>> wrap-around artifacts earlier...
> For debugging - yes.
> It would be more user friendly not to exit the program, however.
> Instead it should be possible to disable the mouse interaction
> until the next replot, and bail to the command line with an error
> message int_error().
>
> Do you see any problems if the assert() statements were replaced by
> if (whatever) {
> [do something to disable mousing];
> int_error(NO_CARET, "error message");
> }
As long as it stays an int_error() (or rather graph_error(), as this
happens in the middle of drawing) --- no problems. An int_warning()
would be critically insufficient, tough.
|
|
From: <HBB...@t-...> - 2007-10-27 20:07:16
|
Philipp K. Janert wrote: > The following two commands will crash > gnuplot: > set hidden3d undefined 2 > splot [][][:1] 10*exp(-(x**2 + y**2)) > Gnuplot dies with the following message: > hidden3d.c:776: store_polygon: Assertion `p->ymax <= surface_scale' failed. Strangely enough, there's no such problem with the Win32 release version... > Note that the plot command is such that > there are values of the function outside > the plot range (z-range). Actually, no, there aren't. Not at the default setting of set isosamples 10 anyway. That's one too few. ;-> The problem itself is an internal constraint violation in the hidden3d algorithm. Something broke the code designed to ensure that out-of-range data points don't make it to that point of the algorithm. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-10-28 00:56:01
|
On Saturday 27 October 2007 13:07, Hans-Bernhard Br=F6ker wrote:
>=20
> The problem itself is an internal constraint violation in the hidden3d=20
> algorithm. Something broke the code designed to ensure that=20
> out-of-range data points don't make it to that point of the algorithm.
I first tried ./configure --disable-h3d-quadtree
The problem was still there.
Reverting hidden3d.c to cvs version 1.54 -> problem is still there
Reverting hidden3d.c to cvs version 1.53 -> problem is no longer evident
The ChangeLog entry for 1.54 is
2005-12-06 Hans-Bernhard Broeker <br...@ph...>
* src/hidden3d.c (COORD_TO_TREECELL, COORD_TO_BITMASK): Avoid
overflow by undoing effect of surface_scale before mapping to
integers.
(store_polygon): Add assert()s to internal macros GET_MIN,
GET_MAX, to catch problems not handled by above changes.
(in_front): Avoid accessing qlist[-1]. Make sure
p_list[] is always filled, even if doing a single-vertex pseudo
edge.
So it's your change. Do you want to have a look at it?
BUT....
=3D=3D=3D=3D=3D=3D=3D> THIS IS ONLY TRUE FOR --disable-h3d-quadtree=20
If I leave the quadtree code enabled, I get this failure even after reverti=
ng to 1.53 =20
=46urthermore, if I go back and rebuild from the 4.0 source with --enable-h=
3d-quadtree
then it fails.
So I there are two separate issues here:
=20
1) We changed the default 4.2 configuration to --enable-h3d-quadtree
2) The non-quadtree version was subsequently broken by the patch from 1.53 =
=2D> 1.54
=2D-=20
Ethan A Merritt
|
|
From: <HBB...@t-...> - 2007-10-28 21:09:29
|
Ethan A Merritt wrote: > On Saturday 27 October 2007 13:07, Hans-Bernhard Bröker wrote: >> The problem itself is an internal constraint violation in the hidden3d >> algorithm. Something broke the code designed to ensure that >> out-of-range data points don't make it to that point of the algorithm. > 2005-12-06 Hans-Bernhard Broeker <br...@ph...> > > * src/hidden3d.c (COORD_TO_TREECELL, COORD_TO_BITMASK): Avoid > overflow by undoing effect of surface_scale before mapping to > integers. > (store_polygon): Add assert()s to internal macros GET_MIN, > GET_MAX, to catch problems not handled by above changes. The overflows that this was designed to avoid would be those wrap-arounds mentioned elsewhere in this thread. Ultimately, the 'undefined <n>' option to hidden3d may have become unviable due to this change. At level 3 it is already documented as "use at your own risk". The simplest option would be to extend that warning to all settings other than the default of 1.0. > So it's your change. Do you want to have a look at it? I'll try to find some time to do that. > So I there are two separate issues here: > > 1) We changed the default 4.2 configuration to --enable-h3d-quadtree But only for ./configure builds. The config/makefile.* and config/config.* files weren't all updated. > 2) The non-quadtree version was subsequently broken by the patch from 1.53 -> 1.54 IIRC, the quadtree variant does its own implicit limit testing elsewhere, so it doesn't really need those assert()s. |
|
From: <HBB...@t-...> - 2007-10-27 20:18:55
|
Thomas Sefzick wrote: > the macros 'GET_MIN' and 'GET_MAX' should be different for checking > min or max values in x- and y- and for checking min or max values in > z-direction. No. At the point in the algorithm where these are used, x, y and z have already been turned into view coordinates. They are checked against the view frustum, > who introduced the 'assert' statements into the 'GET_MIN' and 'GET_MAX' > macros and why? I did, for the reason assert() is pretty much always used: to ensure that worse, much harder to find problems don't appear further down the processing pipeline --- you did mention segfaults and strange wrap-around artifacts earlier... |
|
From: <HBB...@t-...> - 2007-10-28 22:11:01
|
Thomas Sefzick wrote: > we are scaling the whole plot by moving the mouse sidewards while > pressing the middle button. there the comparison of the maximum > x-, y-, z-values to 'surface_scale' is the right one, and 'surface_scale' > increases when zooming in. Mouse interaction doesn't really have much to do with this --- or rather, it shouldn't. The key problem are the third and fourth parameter to 'set view', and how they affect the plot. From the start these parameters were the wrong approach to the perceived problem of incomplete space utilization by 3D plots. They cause the plot to outside all sensible boundaries --- the graph box, the viewport, and eventually even the page itself. surface_zscale (the fourth argument of 'set view') is the worst of them. The only effect this parameter reliably has is to blow the plot off the page. > that's why i think that the y-min/max-values should be checked > against some combination of 'surface_scale' and 'surface_zscale'. I think both of these variables should be killed for good. |
|
Re: Ggnuplot-beta@lists.sourceforge.netnuplot crashing
=?iso-8859-1?q?for=09?="hidden3d undefined" ?
From: Ethan A M. <merritt@u.washington.edu> - 2007-10-29 00:30:39
|
On Sunday 28 October 2007 15:11, Hans-Bernhard Br=F6ker wrote: >=20 > Mouse interaction doesn't really have much to do with this --- or=20 > rather, it shouldn't. Maybe I mis-understood the original bug report, but certainly the=20 problems that I have observed myself are directly due to mouse interaction. What happens, as Thomas described a moment ago, is that if you use the middle mouse button to zoom in the vertical, then the program dies on an assert test just before the plotted surface reaches the edge of the plot area. There is no particular reason that the program could not continue to zoom further; it would just have to clip to the top boundary of the plot. And that is exactly what version 4.0 does. The 1.53 -> 1.54 patch was the exact change that broke this. Actual segfaults or mis-tracking of the vertices doesn't happen unless/until there is more extreme abuse of the scaling parameters. Trials to replace the assert() statements with int_warn() return the behaviour to that of 4.0, which is much more user friendly. If you try really hard, you can make the program crash. But the way it is now, it crashes whenever you expand the plot even an infinitesimally beyond the plot border. This can easily happen while mousing, and it's quite annoying. I am thinking that the assert tests are looking at the wrong thing. As I read it, they will trigger as soon as the vertical extent of the plot hits 1.0 in screen coordinates. Why? Most of the terminals can do proper clipping. Certainly x11 and wxt seem to clip properly if I remove the assert statements. Do you recall which terminal was causing problems when you first put them in? EAM =20 > The key problem are the third and fourth parameter to 'set view', and=20 > how they affect the plot. From the start these parameters were the=20 > wrong approach to the perceived problem of incomplete space utilization=20 > by 3D plots. They cause the plot to outside all sensible boundaries ---= =20 > the graph box, the viewport, and eventually even the page itself. >=20 > surface_zscale (the fourth argument of 'set view') is the worst of them.= =20 > The only effect this parameter reliably has is to blow the plot off=20 > the page. >=20 > > that's why i think that the y-min/max-values should be checked > > against some combination of 'surface_scale' and 'surface_zscale'. >=20 > I think both of these variables should be killed for good. >=20 >=20 > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta >=20 =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Thomas S. <t.s...@fz...> - 2007-10-29 12:54:13
|
Ethan A Merritt wrote: > > Trials to replace the assert() statements with int_warn() return the > behaviour to that of 4.0, which is much more user friendly. > If you try really hard, you can make the program crash. But the way > it is now, it crashes whenever you expand the plot even an infinitesimally > beyond the plot border. This can easily happen while mousing, and > it's quite annoying. > i did some tests with gnuplot 4.0 patchlevel 0: regardless what i did - move the mouse excessively with middle button pressed - set 'scale' and 'scale_z' to absolutely nonsense values (e.g. set view 60,30,10000,10000) i didn't succeed in producing a segmentation fault! i got artefacts, many of them... but no program crash. this means, replacing the assert statements in version 4.2 doesn't result in complete version 4.0 behaviour, there are some more differences. -- View this message in context: http://www.nabble.com/Gnuplot-crashing-for-%22hidden3d-undefined%22---tf4688619.html#a13466741 Sent from the Gnuplot - Dev mailing list archive at Nabble.com. |
