Re: Segmentation Fault with Octave MXE under Windows

[Carnë Draug]

On 29 May 2014 18:44, Daniel J Sebald <address@hidden> wrote:
> On 05/29/2014 12:22 PM, Daniel J Sebald wrote:
>>
>> On 05/29/2014 12:14 PM, John W. Eaton wrote:
>
> [snip]
>>>
>>> It is supposed to be initialized properly in every constructor, never 0.
>>> If that's not the case, can you point to a constructor where it is not
>>> initialized?
>>
>>
>> The test would indicate that "rep" is being used out of scope. The
>> problem might lie elsewhere. I'm looking at the function
>> __magick_read__.cc at the moment for any "delete" called twice or
>> something similar. Array<> is used in __magick_read__.cc, but I'm not
>> seeing anything odd just yet.
>
>
> The destructor could be a red herring--simply the place where a problem
> shows up.  This __magick_read__.cc is somewhat hard to follow.  It is doing
> some tricky stuff disposing of image frames (multiple I suppose, in the case
> of GIF).  One question I have is how "disposalmethod" option is assured to
> have nFrames entries:
>
>   const Array<std::string> disposalmethod = options.getfield
> ("disposalmethod").cellstr_value ();
>   for (octave_idx_type i = 0; i < nFrames; i++)
>     {
>       imvec[i].quality (quality);
>       imvec[i].animationDelay (delaytime(i));
>       imvec[i].gifDisposeMethod (disposal_methods[disposalmethod(i)]);
>     }

The disposal method does not do what you think it does. This is only a
flag written to file that specifies how the image viewer *not Octave*
will display it. See [1]. Depending on the value, a new frame may be
displayed on top of it, or the previous may be discarded first
(remember that gif files allow for transparencies).

Carnë

[1] http://www.theimage.com/animation/pages/disposal.html