On 2008-12-14 02:51-0800 Alan W. Irwin wrote:
[...]I had to turn off the -dev xfig test
> because of a spectacular error (first time I have ever seen a glibc
> backtrace!) generated by example 27 for that device.
I have looked into this error with gdb, and the problem is the bufflen and
count were being held in shorts and thus were overflowing for the large
number of points being drawn for the spirographic lines for example 27. The
realloc subsequently failed because of the negative size. That then
triggered the spectacular double-free error. Here is my initial attempt at
a fix for these problems.
Index: xfig.c
===================================================================
--- xfig.c (revision 9101)
+++ xfig.c (working copy)
@@ -41,8 +41,8 @@
#define XFIG_COLBASE 33 /* xfig first user color, plplot colormap0[0],
the background color */
-static short *buffptr, bufflen;
-static short count;
+static short *buffptr;
+static int bufflen, count;
static int curwid = 1;
static int curcol = 1;
static int firstline = 1;
@@ -146,7 +146,7 @@
bufflen = 2 * BSIZE;
buffptr = (short *) malloc(sizeof(short) * bufflen);
if (buffptr == NULL)
- plexit("Out of memory!");
+ plexit("plD_init_xfig: Out of memory!");
}
void
@@ -234,8 +234,7 @@
tempptr = (short *)
realloc((void *) buffptr, bufflen * sizeof(short));
if (tempptr == NULL) {
- free((void *) buffptr);
- plexit("Out of memory!");
+ plexit("plD_line_xfig: Out of memory!");
}
buffptr = tempptr;
}
This patch is only part of the story. x27c.c (with the above xfig.c patch)
makes an xfig file that is so large that it overflows the spare 2G (!) I
have on my disk. If I cut down NPNTS by a factor of ten (from 20000 to
2000) in x27c.c, the file is quite reasonably sized (383K) and also gives a
reasonable looking result with the xfig application. It looks to me that
that file size should scale with NPNTS, but that would predict ~4M for the
file size (which is consistent with the size of the svg results for this
example) and definitely not anything that should exceed 2GB. Thus, there is
probably something wrong with the above patch (C is not my favorite language
to programme) or there may be some other part of xfig.c that does not scale
well with the relatively large number of points in the spirographic lines to
be plotted for example 27.
Thus, this post is just to get the discussion going about the proper fix for
this xfig.c bug that is triggered by example 27. Of course, -dev xfig is
probably not used that much (and particularly not in the way done by the
spirographic lines with the large number of points in example 27) so it is
mostly a matter of our pride as PLplot developers to fix this correctly.
Thus, I feel this bug fix has lower priority than the release today so that
any commits concerning this bug should be held until after Hazen is finished
with the release so as not to disrupt his work. However, I hope we can
get this bug dealt with in the next few days just to get it out of our hair.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
