bugGNU Octave - Bugs: bug #40248, embedding interpreter in...

 
 

bug #40248: embedding interpreter in standalone application produces segfault

Submitter:  Carlo de Falco <cdf>
Submitted:  Sat 12 Oct 2013 07:45:12 AM UTC
   
 
Category:  None Severity:  4 - Important
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  cdf
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 28 Oct 2013 06:12:50 PM UTC, comment #3: 

OK, assuming this is a "feature", I pushed this changeset:
http://hg.savannah.gnu.org/hgweb/octave/rev/d029ef208e4a

c.

Carlo de Falco <cdf>
Group Member
Thu 24 Oct 2013 08:01:10 AM UTC, comment #2: 

Hi,

Any updates on this one?

I have the patch to change the docs and examples
to document the need to use "clean_up_and_exit"
before shutting down the interpreter.

If this is not going to change before 3.8 I'd rather
push the changeset because I really don't like the
current situation where examples provided in the
source tree and in the manual consistently generate
corrupted memory/segfault errors.

c.

Carlo de Falco <cdf>
Group Member
Tue 15 Oct 2013 05:53:40 AM UTC, comment #1: 

as discussed in this thread:

http://octave.1599824.n4.nabble.com/segfault-when-embedding-the-interpreter-tp4658164.html

using 'cleanup_and_exit' stops the segfault.

Is it sufficient to change the example and the manual
to document that 'cleanup_and_exit' is required to exit
a program that embeds the interpreter?

Carlo de Falco <cdf>
Group Member
Sat 12 Oct 2013 07:45:12 AM UTC, original submission:  

Hi,

With a recent version of the development sources
whenever I try to run standalone programs embedding the interpretr, e.g. examples/embedded.cc, I get a segfault.



$ hg id
1e8f8900a041 tip @
$ mkoctfile -g --link-stand-alone embedded.cc -o embedded
$ ./embedded


This is the result of running the program in the interpreter
and the backtrace of the segfault.



GCD of [10, 15] is 5

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00000001024e4b1e in std::_Rb_tree_increment ()
(gdb) bt
#0  0x00000001024e4b1e in std::_Rb_tree_increment ()
#1  0x000000010036e7c0 in symbol_table::erase_subfunctions_in_scope ()
(gdb)


last time this was working was a couple of weeks ago.

c.

Carlo de Falco <cdf>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by cdf (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-28 cdf StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2013-10-15 cdf StatusNone Confirmed
        Assigned toNone cdf
        Operating SystemMac OS Any

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code