[Octave-bug-tracker] [bug #62207] segfault in bug-35881/bug-35881.tst in 32-bit ARM and MIPS

[John W. Eaton]

Follow-up Comment #33, bug #62207 (project octave):

Can we determine whether the crash is happening when the new exception is
thrown from that location or whether it is crashing when accessing the
original execution_exception object in the catch block (or while making the
copy)?

If the problem occurs when accessing the original execution_exception object
in the catch block, then why would that be wrong?  As far as I can tell, we
throw the exception by value and catch it by const reference.  Shouldn't the
execution_exception object be valid at this point?

If the execution_exception object is being corrupted by some other mistake in
the code, where is that happening?  I suppose it could happen because of a
destructor that is called when unwinding the stack between the point where the
exception is thrown and the catch block where the crash happens.  But what
could be doing that?  I think all the info in the execution_exception object
stored by copying (though possibly reference counted).

Maybe try the attached change that simplifies execution_exception object to
not store the stack frame info?  This change should be applied without any of
the others applied.  If this change avoids the crash, then my guess is that
somehow we are accessing the call stack when we shouldn't?

(file #53034)

    _______________________________________________________

Additional Item Attachment:

File name: omit-stack-trace.txt           Size:1 KB
    <https://file.savannah.gnu.org/file/omit-stack-trace.txt?file_id=53034>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62207>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/