Re: Segmentation Fault with Octave MXE under Windows

[Daniel J Sebald]

On 07/09/2014 09:32 PM, ijourneaux wrote:
> Daniel Sebald wrote
> >           if (!rep)
> >           {
> >             fprintf(stdout, "NULL POINTER!  RETURNING.\n");
> >             return;
> >           }
> >           fprintf(stdout, "Pointer OK.\n");
>
> I modified the code as you proposed. If I have the line
>
> fprintf(stdout, "Pointer OK.\n");
>
> in the code, I get a bunch of "Pointer OK" lines showing up in the cmd
> window. Unfortunately I get too many lines to quickly to see anything else.
> I certainly don't see the Segfault error.

All right, that rules out the use of NULL pointer.  The source of the 
problem is probably within __magick_read__.cc, i.e., this function:

DEFUN_DLD (__magick_read__, args, nargout,

It calls

  std::vector<Magick::Image> imvec;
  read_file (args(0).string_value () imvec);

and read_file() makes use of the Image Magick library:

      Magick::readImages (&imvec, filename);

So there is a lot going on there.  I looked at the header file from the 
Image Magick library.  It's kind of confusing.  I see two such files in 
the include directory:

/usr/include/GraphicsMagick/Magick++/STL.h
/usr/include/ImageMagick/Magick++/STL.h

and the two header files are slightly different in places.


> So I though let's just remove the line
>
> fprintf(stdout, "Pointer OK.\n");
>
> With that single change, I don't see any lines
> NULL POINTER!  RETURNING
> and the segfault message reappears.
>
> I am not sure what is happening.

Sometimes these types of segfault bugs are haphazard.  Shuffling around 
program or data memory just the slightest bit will change the 
manifestation of the bug.

All of that Magick library code is too much for me to dig into right 
now.  But it is clear that there is a lot happening in terms of 
acquiring hunks of memory, cloning parameters, keeping track of these 
image hunks in a list, etc.  And as far as this eventually being 
transformed into an octave_value_list object that Octave can understand, 
that is done with

read_indexed_images<TYPE> ();

A couple things strike me.  One is that it's certainly conceivable that 
your version of Image Magick code has a bug in it.  The second is the 
fact that there sure seems to be a lot going on with the stack.  The 
contents of

  std::vector<Magick::Image> imvec;

probably has at its core heap memory from cloning and whatnot (and where 
that is freed after being copied to an Octave container, I'm not sure). 
 So your stack could be overflowing (hence the strange comment you saw 
about no stack).  The octave_value_list is created on the stack and 
passed back to the calling code.  I assume the octave_value_list is 
what's being accounted for by the "repcount" to cut down on memory usage.

Anyway, that's all mere speculation, but lets try something to 
understand why the segmentation fault is showing up where it is and that 
is confirm that it is the deleting of the octave_value_list where the 
system fault lies.  Remove the "fprintf" statements, and put new ones 
like this:

    virtual ~Array (void)
    {
      if (--rep->count == 0)
      {
fprintf(stdout, "RIGHT BEFORE DELETE\n");
        delete rep;
fprintf(stdout, "RIGHT AFTER DELETE\n");
        rep = NULL;
      }
    }

I'm wondering if by stack overflow or something else about copying 
Magick::Image objects the class object that is deleted is corrupted 
somehow.  If you see "RIGHT BEFORE DELETE" and then the segfault 
message, then the crash is during that delete.

Now, if that is the case, I'm thinking you should be able to investigate 
a little bit from the Octave command line what might be happening.  That 
is, rather than

test imread
exit(0)

Try some of the commands that are within the test code of imread to 
create, save to file and retrieve from file some image with a pattern (a 
ramp, alternate levels, etc.).  Try to display that image in a plot. 
Check whether that image looks the way it should.  I would think that if 
the class object is corrupted, the image might look incorrect.

Dan