From: Alan W. I. <ir...@be...> - 2004-09-03 05:34:39
|
Andrew, I hope you don't mind me taking the liberty of keeping this thread on plplot-devel. I am doing this because other developers may be interested as well, and we may need all the help we can get to solve this. More comments in context below. Alan On 2004-09-03 13:31+1000 Andrew Roach wrote: > Hello Alan and Rafael, > >> You will notice from the above error messages that the invalid read is >> associated with line 949 of gd.c which is the following: >> >> if (!gdImageTrueColor(dev->im_out)) >> >> but I recall you said that the gif device did not have TrueColor. So I am >> wondering if this is the cause of the invalid read. > > Yes, I am sure it is. > >> Should that line be executed for the gif device? > > Never. I can not actually belive that is has executed. Truecolour support for > the Gif driver is turned off not once, but twice ! (once implicitly, once > explicitly) There should be NO way for that command to execute for the gif > driver. > >> Because the C examples test show no severe memory management problems, I >> think there can only be two explanations of the problems encountered for >> gif and the high-level octave interface where extensive testing shows no >> gif problems for any other interface (including the low-level octave >> interface). >> >> 1. The high-level octave interface is not initializing the gif device >> correctly. >> >> 2. The high-level octave interface is initializing and using the gif >> device >> correctly, but it is doing it in a different way or different order than >> the >> C interface (or any other interface including the low-level octave >> interface), and this different way exercises a bug in the gif device >> driver. > > > I don't have octave on my system, so cant test, but I will tell you what I > think it might be. Remember a few months ago a problem popped up with octave, > GD, and freetype fonts ? Although I did not say anything at the time (I just > fixed it), what it turned out to be was octave was sending 256,256,256 to > represent white, when it should have sent 255,255,255. The 8 bit limit for > the colour index was being exceeded, and that mucked up freetype. I just > clamped freetype so anything greater than 255 (ie 256 in this case) was set > to 255. It fixed the problem, from freetype's side of things, but was just a > quick work around. Now if octave is doing a similar thing here, sending 256 > instead of 255 that would trick either libgd or the gd driver (or both!) into > truecolour mode since there was more than the 8 bit limit in an index > somewhere. It would probably be possible to patch the GD driver to clamp > values of 256 back to 255 in a couple of key places to stop this happening, > but I don't think, in this case, that is the real culprit. I think the > problem lies somewhere in octave. Your explanation sounded quite promising, but, alas, the input "ones" array used by the colormap (ones (10, 3)); command is multiplied by 255 in bindings/octave/PLplot/colormap.m so that should not produce a bad colour. I even tried colormap (ones (10, 3)-1); to make that an array of zeroes input, but the segfault is still produced for the gif device. So we have to think of some alternative explanation why the high-level octave interface (but not any other interface including the low-level octave interface) puts the gif device improperly into Truecolour mode. Andrew, can you think of any other way (no matter how strange) to do this except for a bad cmap1 colour? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |