Here is a report of a nice "hard to reproduce" kind of
bug in Povray that doesn't seem to have been reported
previously.  It seems to be related to the way Pov
manages bitmap image data, and colour maps in particular.

Description of the problem:

For a certain scene using bitmaps stored in PNG format
POV will seg-fault at parse-time.

My system is Windows NT 4.0, Service Pack 5, with 128 Meg
of RAM.

Analysis:

I have observed this problem in the IMP POV povray
binary, based on POV 3.1g, and it has also been observed
in the latest official Win32 binary.  

A simple test-case that reproduces the crash is as
follows:

#declare tmp = 
   texture { pigment {
     image_map { png "EarthMap.png" filter all 0.6 }
   } }
   texture { pigment {
     image_map { png "mouse.png" filter all 0.6 }
   } }

There is nothing special about the image-maps,
and they are not included here because they are
large.  The problem depends entirely on the memory
allocation sequence caused by the particular
images.

What seems to happen is that each image_map is
represented in POV by a Image_Struct (typedef'd
to IMAGE), which is not properly initialised in
every case.  The Purify product from Rational Corp
reports an "Unitialised Memory Read", of the
Colour_Map_Size field in line 298 of parstxtr.c:

{
  DBL filter;
  filter = Parse_Float();
  for (reg = 0 ; reg < Image->Colour_Map_Size ; reg++)
    Image->Colour_Map[reg].Filter
      = (unsigned short) (filter *255.0);
}

In fact, Colour_Map_Size was set to 4, 
while no Colour Map actually existed.  

In debug mode, this problem has been hard to
reproduce, and in release mode, it is harder to
track down.
 
Fix:

There are two alternative fixes -

1.  Ensure that every IMAGE read from a file
    correctly initialises the Colour_Map_Size
    and Colour_Map fields.  For example, some
    of the PNG formats initialise Colour_Map,
    but not Colour_Map_Size.

2.  Ensure that every IMAGE structure is
    is initialised to neutral defaults at
    time of creation.  Add the following
    two lines to the function Create_Image()
    in image.c, line 1265...

    Image->Colour_Map_Size = 0;
    Image->Colour_Map = (IMAGE_COLOUR *)NULL;

    The patched Create_Image() function looks
    like this:

IMAGE *Create_Image()
{
  IMAGE *Image;

  Image = (IMAGE *) POV_MALLOC(sizeof(IMAGE), "image file");

  Image->References = 1;

  Image->File_Type = NO_FILE;

  Image->Map_Type = PLANAR_MAP;

  Image->Interpolation_Type = NO_INTERPOLATION;

  Image->Once_Flag = FALSE;

  Image->Use_Colour_Flag = FALSE;

  Make_Vector(Image->Gradient, 1.0, -1.0, 0.0);

  Image->Colour_Map_Size = 0;
  Image->Colour_Map = (IMAGE_COLOUR *)NULL;

  return (Image);
}

Credits:

For further information, Nigel Stewart <nig### [at] eisanetau>
Bug was found by Richard Throgmorton <rth### [at] BENHAMCOM> 

-- 
Nigel Stewart (nig### [at] eisanetau)  http://www.eisa.net.au/~nigels/
Postgrad Research Student, RMIT University, Melbourne, Australia
All extremists should be taken out and shot.

Post a reply to this message

> >         Here is the full bug-report, but basically,
> >         using PNG with filter/transmit can crash POV
> >         in some circumstances (phase of the moon, etc)
> >         unless you use IMP POV!
> 
> Just out of curiousity what is the bit depth and number of colors in the png
> files causing the crash ? Filter and transmit only work on 8 bit 256 color
> images.

        As I recall it was 24 bit PNG files, combined
        with filter or transmit, that could potentially 
        cause a crash.  I think you're right about filter
        and transmit only working on indexed formats, but
        it shouldn't cause a seg fault, even if it doesn't
	work!

Post a reply to this message