octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Segmentation Fault with Octave MXE under Windows


From: Carnë Draug
Subject: Re: Segmentation Fault with Octave MXE under Windows
Date: Thu, 10 Jul 2014 16:03:51 +0100

On 10 July 2014 15:42, Journeaux, Ian <address@hidden> wrote:
> On 10 July 2014 09:21, Carnë Draug said:
>>
>> Have you tried?
>>
>> a = imformats ();
>> clear -f
>> exit
>
> Carne
> That results in the same segfault
>
> 0x68A6AD12 (0x0022FA30 0x77992DD6 0x0022FFC4 0x778B8CD5), _ZN5ArrayIdED2Ev() 
> + 0
> x12 bytes(s)
> panic: Segmentation violation -- stopping myself...
> attempting to save variables to 'octave-workspace'...
>
> I will post this comment to the discussion group directly as my email system 
> adds the typical legal disclaimer.
>
> Does this point us to a direction as to where the error is coming from?

Yes [1]

On 4 June 2014 17:16, Carnë Draug wrote:
> On 4 June 2014 17:09, Daniel J Sebald <[hidden email]> wrote:
>> On 06/04/2014 04:31 AM, ijourneaux wrote:
>>>
>>> This is the bug report associated with this topic.
>>>
>>> https://savannah.gnu.org/bugs/?41699<https://savannah.gnu.org/bugs/?41699>
>>>
>>> I tried navigating up the backtrace to see where the problem was
>>> originating. The segfault goes through
>>>
>>> symbol_table::erase_scope (local_scope);
>>>
>>> which has a "// FIXME: this is really playing with fire." at line 236.
>>> Useful info or just a red herring?
>>
>>
>> Not sure.  local_scope is assigned the value "sid" which is passed into the
>> routine.  If the procedure is that octave_user_function assumes control and
>> cleanup of the function table for that scope, then it's fine.  But if some
>> other part of the code is still using those parts of the function table then
>> it is a problem.  Cleanup should be done elsewhere.  erase_scope() in
>> symtab.h ensures the scope is local.
>
> The following may be complete rubbish or related if there's something
> related to scope of functions: imformats keeps a persistent struct
> with function handles for the private functions within
> "m/image/private". This is created during the first call to one of the
> image IO functions (imwrite, imread, and imfinfo).

It may still be related with this (just not from that specific line).
As I mentioned before, imformats() is called for each of the imageIO
functions. Try to remove the persistence of the structure it creates
internally and see if that fixes it.

Carnë

[1] 
http://octave.1599824.n4.nabble.com/Segmentation-Fault-with-Octave-MXE-under-Windows-tp4664305p4664470.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]