[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Segmentation Fault with Octave MXE under Windows
From: |
Daniel J Sebald |
Subject: |
Re: Segmentation Fault with Octave MXE under Windows |
Date: |
Thu, 10 Jul 2014 03:54:08 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
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
- Re: Segmentation Fault with Octave MXE under Windows, (continued)
- Re: Segmentation Fault with Octave MXE under Windows, ijourneaux, 2014/07/09
- Re: Segmentation Fault with Octave MXE under Windows, ijourneaux, 2014/07/10
- Re: Segmentation Fault with Octave MXE under Windows, ijourneaux, 2014/07/10
- Re: Segmentation Fault with Octave MXE under Windows, Carnë Draug, 2014/07/10
- Message not available
- Re: Segmentation Fault with Octave MXE under Windows, Carnë Draug, 2014/07/10
- Re: Segmentation Fault with Octave MXE under Windows, Daniel J Sebald, 2014/07/10
- Re: Segmentation Fault with Octave MXE under Windows, Carnë Draug, 2014/07/10
- Re: Segmentation Fault with Octave MXE under Windows, ijourneaux, 2014/07/10
- Re: Segmentation Fault with Octave MXE under Windows, Daniel J Sebald, 2014/07/10
- Re: Segmentation Fault with Octave MXE under Windows, ijourneaux, 2014/07/10
- Re: Segmentation Fault with Octave MXE under Windows,
Daniel J Sebald <=
- Re: Segmentation Fault with Octave MXE under Windows, ijourneaux, 2014/07/09