segfault and onCleanup()

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

segfault and onCleanup()

Rik-4
On 12/07/2011 12:41 PM, John W. Eaton wrote:
> I'm not seeing this crash, but I checked in this change as a temporary
> fix for those of you who are.
>
> I don't know that I'll be able to debug this problem unless I can
> find a way to reproduce it myself.


I've single-stepped through the segfault.  The trouble is not directly in cleanup_instance().  Rather the code 'delete instance;' triggers the destructor for the class.  The destructor defined in ov-typeinfo.h is empty, but there are a number of Array objects in the class and the destructor for the Array class is called.  It is not the first element of the Array object which triggers the segfault.  It seems to be the 14th but I don't know if that is the 14th element of the Array or the 14th Array object.  It also might simply be a red herring.  The relevant part of the trace is below.

#18 0x00002aaaad757460 in _int_free (av=0x7fffffffd1f0, p=0x0) at malloc.c:5017
#19 0x00002aaaab1059cb in ~octave_value (this=0x63ce70, __in_chrg=<value optimized out>) at ov.h:311
#20 0x00002aaaab106c8f in ~ArrayRep (this=0x63ce70, __in_chrg=<value optimized out>) at ../liboctave/Array.h:94
#21 0x00002aaaab106321 in ~Array (this=0x62cfe8, __in_chrg=<value optimized out>) at ../liboctave/Array.h:235
#22 0x00002aaaab5b3582 in ~octave_value_typeinfo (this=0x62cfc0, __in_chrg=<value optimized out>) at ov-typeinfo.h:192
#23 0x00002aaaab5b3f67 in octave_value_typeinfo::cleanup_instance () at ov-typeinfo.h:223
#24 0x00002aaaac3ea2c8 in ~singleton_cleanup_list (this=0x612380, __in_chrg=<value optimized out>) at singleton-cleanup.cc:39
#25 0x00002aaaab4c02a1 in singleton_cleanup_list::cleanup () at ../liboctave/singleton-cleanup.h:26
#26 0x00002aaaab4bd280 in clean_up_and_exit (retval=0) at toplev.cc:697
#27 0x00002aaaab46f5d1 in octave_main (argc=11, argv=0x7fffffffd1f8, embedded=0) at octave.cc:904
#28 0x0000000000400769 in main (argc=11, argv=0x7fffffffd1f8) at main.c:35

Also, most of the time I can start 'run-octave' and mess around in the interpreter without problems.  However, it is always reproducible with 'make check'.  I did some verification with runtests and the following functions always cause a segfault when exiting octave if I have used 'test XXX'.

./linear-algebra/onenormest.m
./geometry/griddata3.m
./geometry/delaunay.m
./plot/trisurf.m
./plot/triplot.m
./plot/trimesh.m
./sparse/svds.m
../src/DLD-FUNCTIONS/onCleanup.cc

The common element (clue?) is that they all use onCleanup within a %!test block.  If I comment out the onCleanup () call then the segfault disappears.  Actually, on further trolling through the code, these are the only points where onCleanup is ever used.  I did a quick test with the following in the file blah.m

function blah ()
  restore_state = onCleanup (@() disp ("hello"));
  disp ("First");
endfunction

Calling blah() correctly displays
First
hello

but this segfaults as well when I exit Octave.  This problem isn't confined to some weirdness of %!test blocks.

I'm of the opinion that the whole onCleanup class is broken.  Perhaps you can see quickly what is wrong.  Otherwise, the %!test blocks can be rewritten to use unwind_protect blocks to accomplish the same task of restoring the random seed.

Cheers,
Rik


Reply | Threaded
Open this post in threaded view
|

segfault and onCleanup()

John W. Eaton
Administrator
On  7-Dec-2011, Rik wrote:

| On 12/07/2011 12:41 PM, John W. Eaton wrote:
| > I'm not seeing this crash, but I checked in this change as a temporary
| > fix for those of you who are.
| >
| > I don't know that I'll be able to debug this problem unless I can
| > find a way to reproduce it myself.
|
| I've single-stepped through the segfault.  The trouble is not directly in
| cleanup_instance().  Rather the code 'delete instance;' triggers the destructor
| for the class.  The destructor defined in ov-typeinfo.h is empty, but there are
| a number of Array objects in the class and the destructor for the Array class
| is called.  It is not the first element of the Array object which triggers the
| segfault.  It seems to be the 14th but I don't know if that is the 14th element
| of the Array or the 14th Array object.  It also might simply be a red herring. 
| The relevant part of the trace is below.
|
| #18 0x00002aaaad757460 in _int_free (av=0x7fffffffd1f0, p=0x0) at malloc.c:5017
| #19 0x00002aaaab1059cb in ~octave_value (this=0x63ce70, __in_chrg=<value
| optimized out>) at ov.h:311
| #20 0x00002aaaab106c8f in ~ArrayRep (this=0x63ce70, __in_chrg=<value optimized
| out>) at ../liboctave/Array.h:94
| #21 0x00002aaaab106321 in ~Array (this=0x62cfe8, __in_chrg=<value optimized
| out>) at ../liboctave/Array.h:235
| #22 0x00002aaaab5b3582 in ~octave_value_typeinfo (this=0x62cfc0, __in_chrg=
| <value optimized out>) at ov-typeinfo.h:192
| #23 0x00002aaaab5b3f67 in octave_value_typeinfo::cleanup_instance () at
| ov-typeinfo.h:223
| #24 0x00002aaaac3ea2c8 in ~singleton_cleanup_list (this=0x612380, __in_chrg=
| <value optimized out>) at singleton-cleanup.cc:39
| #25 0x00002aaaab4c02a1 in singleton_cleanup_list::cleanup () at ../liboctave/
| singleton-cleanup.h:26
| #26 0x00002aaaab4bd280 in clean_up_and_exit (retval=0) at toplev.cc:697
| #27 0x00002aaaab46f5d1 in octave_main (argc=11, argv=0x7fffffffd1f8, embedded=
| 0) at octave.cc:904
| #28 0x0000000000400769 in main (argc=11, argv=0x7fffffffd1f8) at main.c:35
|
| Also, most of the time I can start 'run-octave' and mess around in the
| interpreter without problems.  However, it is always reproducible with 'make
| check'.  I did some verification with runtests and the following functions
| always cause a segfault when exiting octave if I have used 'test XXX'.
|
| ./linear-algebra/onenormest.m
| ./geometry/griddata3.m
| ./geometry/delaunay.m
| ./plot/trisurf.m
| ./plot/triplot.m
| ./plot/trimesh.m
| ./sparse/svds.m
| ../src/DLD-FUNCTIONS/onCleanup.cc
|
| The common element (clue?) is that they all use onCleanup within a %!test
| block.  If I comment out the onCleanup () call then the segfault disappears. 
| Actually, on further trolling through the code, these are the only points where
| onCleanup is ever used.  I did a quick test with the following in the file
| blah.m
|
| function blah ()
|   restore_state = onCleanup (@() disp ("hello"));
|   disp ("First");
| endfunction
|
| Calling blah() correctly displays
| First
| hello
|
| but this segfaults as well when I exit Octave.  This problem isn't confined to
| some weirdness of %!test blocks.
|
| I'm of the opinion that the whole onCleanup class is broken.  Perhaps you can
| see quickly what is wrong.  Otherwise, the %!test blocks can be rewritten to
| use unwind_protect blocks to accomplish the same task of restoring the random
| seed.

I don't see anything really wrong with onCleanup except that it is
dynamically loaded.  So I checked in a change to build it into
liboctinterp so that clearing it should not be able to cause trouble.

I also checked in some changes for gh_manager and reactivated all the
singleton cleanup_instance functions.  As part of the gh_manager
changes, errors in closerequestfcn callback functions should be
handled better than I think they were before.

You'll need to be sure to remove the obsolete onCleanup.oct file
from your build directory.

I'm not seeing any crashes now.  I've run make check multiple times and
also ran through all the plot demos without seeing Octave crashing
when it exits.

If you see failures, please let me know what OS (32 or 64 bit?),
compiler version, etc. that you are using so I can try to duplicate
the problems you are seeing.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

bpabbott
Administrator
On Dec 8, 2011, at 6:59 AM, John W. Eaton wrote:

> On  7-Dec-2011, Rik wrote:
>
> | On 12/07/2011 12:41 PM, John W. Eaton wrote:
> | > I'm not seeing this crash, but I checked in this change as a temporary
> | > fix for those of you who are.
> | >
> | > I don't know that I'll be able to debug this problem unless I can
> | > find a way to reproduce it myself.
> |
> | I've single-stepped through the segfault.  The trouble is not directly in
> | cleanup_instance().  Rather the code 'delete instance;' triggers the destructor
> | for the class.  The destructor defined in ov-typeinfo.h is empty, but there are
> | a number of Array objects in the class and the destructor for the Array class
> | is called.  It is not the first element of the Array object which triggers the
> | segfault.  It seems to be the 14th but I don't know if that is the 14th element
> | of the Array or the 14th Array object.  It also might simply be a red herring.
> | The relevant part of the trace is below.
> |
> | #18 0x00002aaaad757460 in _int_free (av=0x7fffffffd1f0, p=0x0) at malloc.c:5017
> | #19 0x00002aaaab1059cb in ~octave_value (this=0x63ce70, __in_chrg=<value
> | optimized out>) at ov.h:311
> | #20 0x00002aaaab106c8f in ~ArrayRep (this=0x63ce70, __in_chrg=<value optimized
> | out>) at ../liboctave/Array.h:94
> | #21 0x00002aaaab106321 in ~Array (this=0x62cfe8, __in_chrg=<value optimized
> | out>) at ../liboctave/Array.h:235
> | #22 0x00002aaaab5b3582 in ~octave_value_typeinfo (this=0x62cfc0, __in_chrg=
> | <value optimized out>) at ov-typeinfo.h:192
> | #23 0x00002aaaab5b3f67 in octave_value_typeinfo::cleanup_instance () at
> | ov-typeinfo.h:223
> | #24 0x00002aaaac3ea2c8 in ~singleton_cleanup_list (this=0x612380, __in_chrg=
> | <value optimized out>) at singleton-cleanup.cc:39
> | #25 0x00002aaaab4c02a1 in singleton_cleanup_list::cleanup () at ../liboctave/
> | singleton-cleanup.h:26
> | #26 0x00002aaaab4bd280 in clean_up_and_exit (retval=0) at toplev.cc:697
> | #27 0x00002aaaab46f5d1 in octave_main (argc=11, argv=0x7fffffffd1f8, embedded=
> | 0) at octave.cc:904
> | #28 0x0000000000400769 in main (argc=11, argv=0x7fffffffd1f8) at main.c:35
> |
> | Also, most of the time I can start 'run-octave' and mess around in the
> | interpreter without problems.  However, it is always reproducible with 'make
> | check'.  I did some verification with runtests and the following functions
> | always cause a segfault when exiting octave if I have used 'test XXX'.
> |
> | ./linear-algebra/onenormest.m
> | ./geometry/griddata3.m
> | ./geometry/delaunay.m
> | ./plot/trisurf.m
> | ./plot/triplot.m
> | ./plot/trimesh.m
> | ./sparse/svds.m
> | ../src/DLD-FUNCTIONS/onCleanup.cc
> |
> | The common element (clue?) is that they all use onCleanup within a %!test
> | block.  If I comment out the onCleanup () call then the segfault disappears.
> | Actually, on further trolling through the code, these are the only points where
> | onCleanup is ever used.  I did a quick test with the following in the file
> | blah.m
> |
> | function blah ()
> |   restore_state = onCleanup (@() disp ("hello"));
> |   disp ("First");
> | endfunction
> |
> | Calling blah() correctly displays
> | First
> | hello
> |
> | but this segfaults as well when I exit Octave.  This problem isn't confined to
> | some weirdness of %!test blocks.
> |
> | I'm of the opinion that the whole onCleanup class is broken.  Perhaps you can
> | see quickly what is wrong.  Otherwise, the %!test blocks can be rewritten to
> | use unwind_protect blocks to accomplish the same task of restoring the random
> | seed.
>
> I don't see anything really wrong with onCleanup except that it is
> dynamically loaded.  So I checked in a change to build it into
> liboctinterp so that clearing it should not be able to cause trouble.
>
> I also checked in some changes for gh_manager and reactivated all the
> singleton cleanup_instance functions.  As part of the gh_manager
> changes, errors in closerequestfcn callback functions should be
> handled better than I think they were before.
>
> You'll need to be sure to remove the obsolete onCleanup.oct file
> from your build directory.
>
> I'm not seeing any crashes now.  I've run make check multiple times and
> also ran through all the plot demos without seeing Octave crashing
> when it exits.
>
> If you see failures, please let me know what OS (32 or 64 bit?),
> compiler version, etc. that you are using so I can try to duplicate
> the problems you are seeing.
>
> jwe

John, I'm getting an error due to missing ov-cleanup.h. Should the #include be ...

diff --git a/src/ov-oncleanup.cc b/src/ov-oncleanup.cc
--- a/src/ov-oncleanup.cc
+++ b/src/ov-oncleanup.cc
@@ -25,7 +25,7 @@
 #endif
 
 #include "defun.h"
-#include "ov-cleanup.h"
+#include "ov-oncleanup.h"
 #include "ov-fcn.h"
 #include "ov-usr-fcn.h"
 #include "pt-misc.h"

Ben




Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

bpabbott
Administrator

On Dec 8, 2011, at 10:12 AM, Ben Abbott wrote:

> On Dec 8, 2011, at 6:59 AM, John W. Eaton wrote:
>
>> On  7-Dec-2011, Rik wrote:
>>
>> | On 12/07/2011 12:41 PM, John W. Eaton wrote:
>> | > I'm not seeing this crash, but I checked in this change as a temporary
>> | > fix for those of you who are.
>> | >
>> | > I don't know that I'll be able to debug this problem unless I can
>> | > find a way to reproduce it myself.
>> |
>> | I've single-stepped through the segfault.  The trouble is not directly in
>> | cleanup_instance().  Rather the code 'delete instance;' triggers the destructor
>> | for the class.  The destructor defined in ov-typeinfo.h is empty, but there are
>> | a number of Array objects in the class and the destructor for the Array class
>> | is called.  It is not the first element of the Array object which triggers the
>> | segfault.  It seems to be the 14th but I don't know if that is the 14th element
>> | of the Array or the 14th Array object.  It also might simply be a red herring.
>> | The relevant part of the trace is below.
>> |
>> | #18 0x00002aaaad757460 in _int_free (av=0x7fffffffd1f0, p=0x0) at malloc.c:5017
>> | #19 0x00002aaaab1059cb in ~octave_value (this=0x63ce70, __in_chrg=<value
>> | optimized out>) at ov.h:311
>> | #20 0x00002aaaab106c8f in ~ArrayRep (this=0x63ce70, __in_chrg=<value optimized
>> | out>) at ../liboctave/Array.h:94
>> | #21 0x00002aaaab106321 in ~Array (this=0x62cfe8, __in_chrg=<value optimized
>> | out>) at ../liboctave/Array.h:235
>> | #22 0x00002aaaab5b3582 in ~octave_value_typeinfo (this=0x62cfc0, __in_chrg=
>> | <value optimized out>) at ov-typeinfo.h:192
>> | #23 0x00002aaaab5b3f67 in octave_value_typeinfo::cleanup_instance () at
>> | ov-typeinfo.h:223
>> | #24 0x00002aaaac3ea2c8 in ~singleton_cleanup_list (this=0x612380, __in_chrg=
>> | <value optimized out>) at singleton-cleanup.cc:39
>> | #25 0x00002aaaab4c02a1 in singleton_cleanup_list::cleanup () at ../liboctave/
>> | singleton-cleanup.h:26
>> | #26 0x00002aaaab4bd280 in clean_up_and_exit (retval=0) at toplev.cc:697
>> | #27 0x00002aaaab46f5d1 in octave_main (argc=11, argv=0x7fffffffd1f8, embedded=
>> | 0) at octave.cc:904
>> | #28 0x0000000000400769 in main (argc=11, argv=0x7fffffffd1f8) at main.c:35
>> |
>> | Also, most of the time I can start 'run-octave' and mess around in the
>> | interpreter without problems.  However, it is always reproducible with 'make
>> | check'.  I did some verification with runtests and the following functions
>> | always cause a segfault when exiting octave if I have used 'test XXX'.
>> |
>> | ./linear-algebra/onenormest.m
>> | ./geometry/griddata3.m
>> | ./geometry/delaunay.m
>> | ./plot/trisurf.m
>> | ./plot/triplot.m
>> | ./plot/trimesh.m
>> | ./sparse/svds.m
>> | ../src/DLD-FUNCTIONS/onCleanup.cc
>> |
>> | The common element (clue?) is that they all use onCleanup within a %!test
>> | block.  If I comment out the onCleanup () call then the segfault disappears.
>> | Actually, on further trolling through the code, these are the only points where
>> | onCleanup is ever used.  I did a quick test with the following in the file
>> | blah.m
>> |
>> | function blah ()
>> |   restore_state = onCleanup (@() disp ("hello"));
>> |   disp ("First");
>> | endfunction
>> |
>> | Calling blah() correctly displays
>> | First
>> | hello
>> |
>> | but this segfaults as well when I exit Octave.  This problem isn't confined to
>> | some weirdness of %!test blocks.
>> |
>> | I'm of the opinion that the whole onCleanup class is broken.  Perhaps you can
>> | see quickly what is wrong.  Otherwise, the %!test blocks can be rewritten to
>> | use unwind_protect blocks to accomplish the same task of restoring the random
>> | seed.
>>
>> I don't see anything really wrong with onCleanup except that it is
>> dynamically loaded.  So I checked in a change to build it into
>> liboctinterp so that clearing it should not be able to cause trouble.
>>
>> I also checked in some changes for gh_manager and reactivated all the
>> singleton cleanup_instance functions.  As part of the gh_manager
>> changes, errors in closerequestfcn callback functions should be
>> handled better than I think they were before.
>>
>> You'll need to be sure to remove the obsolete onCleanup.oct file
>> from your build directory.
>>
>> I'm not seeing any crashes now.  I've run make check multiple times and
>> also ran through all the plot demos without seeing Octave crashing
>> when it exits.
>>
>> If you see failures, please let me know what OS (32 or 64 bit?),
>> compiler version, etc. that you are using so I can try to duplicate
>> the problems you are seeing.
>>
>> jwe
>
> John, I'm getting an error due to missing ov-cleanup.h. Should the #include be ...
>
> diff --git a/src/ov-oncleanup.cc b/src/ov-oncleanup.cc
> --- a/src/ov-oncleanup.cc
> +++ b/src/ov-oncleanup.cc
> @@ -25,7 +25,7 @@
> #endif
>
> #include "defun.h"
> -#include "ov-cleanup.h"
> +#include "ov-oncleanup.h"
> #include "ov-fcn.h"
> #include "ov-usr-fcn.h"
> #include "pt-misc.h"
>
> Ben

There's another in ov.cc

$ hg diff
diff --git a/src/ov-oncleanup.cc b/src/ov-oncleanup.cc
--- a/src/ov-oncleanup.cc
+++ b/src/ov-oncleanup.cc
@@ -25,7 +25,7 @@
 #endif
 
 #include "defun.h"
-#include "ov-cleanup.h"
+#include "ov-oncleanup.h"
 #include "ov-fcn.h"
 #include "ov-usr-fcn.h"
 #include "pt-misc.h"
diff --git a/src/ov.cc b/src/ov.cc
--- a/src/ov.cc
+++ b/src/ov.cc
@@ -65,7 +65,7 @@
 #include "ov-range.h"
 #include "ov-struct.h"
 #include "ov-class.h"
-#include "ov-cleanup.h"
+#include "ov-oncleanup.h"
 #include "ov-cs-list.h"
 #include "ov-colon.h"
 #include "ov-builtin.h"

Ben

Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

bpabbott
Administrator

On Dec 8, 2011, at 10:20 AM, Ben Abbott wrote:

>
> On Dec 8, 2011, at 10:12 AM, Ben Abbott wrote:
>
>> On Dec 8, 2011, at 6:59 AM, John W. Eaton wrote:
>>
>>> On  7-Dec-2011, Rik wrote:
>>>
>>> | On 12/07/2011 12:41 PM, John W. Eaton wrote:
>>> | > I'm not seeing this crash, but I checked in this change as a temporary
>>> | > fix for those of you who are.
>>> | >
>>> | > I don't know that I'll be able to debug this problem unless I can
>>> | > find a way to reproduce it myself.
>>> |
>>> | I've single-stepped through the segfault.  The trouble is not directly in
>>> | cleanup_instance().  Rather the code 'delete instance;' triggers the destructor
>>> | for the class.  The destructor defined in ov-typeinfo.h is empty, but there are
>>> | a number of Array objects in the class and the destructor for the Array class
>>> | is called.  It is not the first element of the Array object which triggers the
>>> | segfault.  It seems to be the 14th but I don't know if that is the 14th element
>>> | of the Array or the 14th Array object.  It also might simply be a red herring.
>>> | The relevant part of the trace is below.
>>> |
>>> | #18 0x00002aaaad757460 in _int_free (av=0x7fffffffd1f0, p=0x0) at malloc.c:5017
>>> | #19 0x00002aaaab1059cb in ~octave_value (this=0x63ce70, __in_chrg=<value
>>> | optimized out>) at ov.h:311
>>> | #20 0x00002aaaab106c8f in ~ArrayRep (this=0x63ce70, __in_chrg=<value optimized
>>> | out>) at ../liboctave/Array.h:94
>>> | #21 0x00002aaaab106321 in ~Array (this=0x62cfe8, __in_chrg=<value optimized
>>> | out>) at ../liboctave/Array.h:235
>>> | #22 0x00002aaaab5b3582 in ~octave_value_typeinfo (this=0x62cfc0, __in_chrg=
>>> | <value optimized out>) at ov-typeinfo.h:192
>>> | #23 0x00002aaaab5b3f67 in octave_value_typeinfo::cleanup_instance () at
>>> | ov-typeinfo.h:223
>>> | #24 0x00002aaaac3ea2c8 in ~singleton_cleanup_list (this=0x612380, __in_chrg=
>>> | <value optimized out>) at singleton-cleanup.cc:39
>>> | #25 0x00002aaaab4c02a1 in singleton_cleanup_list::cleanup () at ../liboctave/
>>> | singleton-cleanup.h:26
>>> | #26 0x00002aaaab4bd280 in clean_up_and_exit (retval=0) at toplev.cc:697
>>> | #27 0x00002aaaab46f5d1 in octave_main (argc=11, argv=0x7fffffffd1f8, embedded=
>>> | 0) at octave.cc:904
>>> | #28 0x0000000000400769 in main (argc=11, argv=0x7fffffffd1f8) at main.c:35
>>> |
>>> | Also, most of the time I can start 'run-octave' and mess around in the
>>> | interpreter without problems.  However, it is always reproducible with 'make
>>> | check'.  I did some verification with runtests and the following functions
>>> | always cause a segfault when exiting octave if I have used 'test XXX'.
>>> |
>>> | ./linear-algebra/onenormest.m
>>> | ./geometry/griddata3.m
>>> | ./geometry/delaunay.m
>>> | ./plot/trisurf.m
>>> | ./plot/triplot.m
>>> | ./plot/trimesh.m
>>> | ./sparse/svds.m
>>> | ../src/DLD-FUNCTIONS/onCleanup.cc
>>> |
>>> | The common element (clue?) is that they all use onCleanup within a %!test
>>> | block.  If I comment out the onCleanup () call then the segfault disappears.
>>> | Actually, on further trolling through the code, these are the only points where
>>> | onCleanup is ever used.  I did a quick test with the following in the file
>>> | blah.m
>>> |
>>> | function blah ()
>>> |   restore_state = onCleanup (@() disp ("hello"));
>>> |   disp ("First");
>>> | endfunction
>>> |
>>> | Calling blah() correctly displays
>>> | First
>>> | hello
>>> |
>>> | but this segfaults as well when I exit Octave.  This problem isn't confined to
>>> | some weirdness of %!test blocks.
>>> |
>>> | I'm of the opinion that the whole onCleanup class is broken.  Perhaps you can
>>> | see quickly what is wrong.  Otherwise, the %!test blocks can be rewritten to
>>> | use unwind_protect blocks to accomplish the same task of restoring the random
>>> | seed.
>>>
>>> I don't see anything really wrong with onCleanup except that it is
>>> dynamically loaded.  So I checked in a change to build it into
>>> liboctinterp so that clearing it should not be able to cause trouble.
>>>
>>> I also checked in some changes for gh_manager and reactivated all the
>>> singleton cleanup_instance functions.  As part of the gh_manager
>>> changes, errors in closerequestfcn callback functions should be
>>> handled better than I think they were before.
>>>
>>> You'll need to be sure to remove the obsolete onCleanup.oct file
>>> from your build directory.
>>>
>>> I'm not seeing any crashes now.  I've run make check multiple times and
>>> also ran through all the plot demos without seeing Octave crashing
>>> when it exits.
>>>
>>> If you see failures, please let me know what OS (32 or 64 bit?),
>>> compiler version, etc. that you are using so I can try to duplicate
>>> the problems you are seeing.
>>>
>>> jwe
>>
>> John, I'm getting an error due to missing ov-cleanup.h. Should the #include be ...
>>
>> diff --git a/src/ov-oncleanup.cc b/src/ov-oncleanup.cc
>> --- a/src/ov-oncleanup.cc
>> +++ b/src/ov-oncleanup.cc
>> @@ -25,7 +25,7 @@
>> #endif
>>
>> #include "defun.h"
>> -#include "ov-cleanup.h"
>> +#include "ov-oncleanup.h"
>> #include "ov-fcn.h"
>> #include "ov-usr-fcn.h"
>> #include "pt-misc.h"
>>
>> Ben
>
> There's another in ov.cc
>
> $ hg diff
> diff --git a/src/ov-oncleanup.cc b/src/ov-oncleanup.cc
> --- a/src/ov-oncleanup.cc
> +++ b/src/ov-oncleanup.cc
> @@ -25,7 +25,7 @@
> #endif
>
> #include "defun.h"
> -#include "ov-cleanup.h"
> +#include "ov-oncleanup.h"
> #include "ov-fcn.h"
> #include "ov-usr-fcn.h"
> #include "pt-misc.h"
> diff --git a/src/ov.cc b/src/ov.cc
> --- a/src/ov.cc
> +++ b/src/ov.cc
> @@ -65,7 +65,7 @@
> #include "ov-range.h"
> #include "ov-struct.h"
> #include "ov-class.h"
> -#include "ov-cleanup.h"
> +#include "ov-oncleanup.h"
> #include "ov-cs-list.h"
> #include "ov-colon.h"
> #include "ov-builtin.h"
>
> Ben

With the change above, I still see a segfault.

panic: Segmentation fault: 11 -- stopping myself...
attempting to save variables to `octave-core'...
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_S_create
panic: attempted clean up apparently failed -- aborting...
make[1]: *** [check] Abort trap: 6
make: *** [check] Error 2

I tried (naively?) restoring the patches to ov-typeinfo.cc and graphics.cc, but the segfault persists.

Ben


Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

John W. Eaton
Administrator
In reply to this post by bpabbott
On  8-Dec-2011, Ben Abbott wrote:

| > John, I'm getting an error due to missing ov-cleanup.h. Should the #include be ...
| >

Thanks, I fixed both of them.

It worked for me because I originally started off with that name and I
still had the original file in addition to the new ov-oncleanup.h.
Oops.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

John W. Eaton
Administrator
In reply to this post by bpabbott
On  8-Dec-2011, Ben Abbott wrote:

| With the change above, I still see a segfault.
|
| panic: Segmentation fault: 11 -- stopping myself...
| attempting to save variables to `octave-core'...
| terminate called after throwing an instance of 'std::length_error'
|   what():  basic_string::_S_create
| panic: attempted clean up apparently failed -- aborting...
| make[1]: *** [check] Abort trap: 6
| make: *** [check] Error 2
|
| I tried (naively?) restoring the patches to ov-typeinfo.cc and graphics.cc, but the segfault persists.

Is there an onCleanup.oct file from a previous build still present?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

bpabbott
Administrator

On Dec 8, 2011, at 11:07 AM, John W. Eaton wrote:

> On  8-Dec-2011, Ben Abbott wrote:
>
> | With the change above, I still see a segfault.
> |
> | panic: Segmentation fault: 11 -- stopping myself...
> | attempting to save variables to `octave-core'...
> | terminate called after throwing an instance of 'std::length_error'
> |   what():  basic_string::_S_create
> | panic: attempted clean up apparently failed -- aborting...
> | make[1]: *** [check] Abort trap: 6
> | make: *** [check] Error 2
> |
> | I tried (naively?) restoring the patches to ov-typeinfo.cc and graphics.cc, but the segfault persists.
>
> Is there an onCleanup.oct file from a previous build still present?
>
> jwe

After  (1) deleted everything named onCleanup.*, (2) maintainter-clean, (3) hg pull ; hg update -C, and (4) building octave.  I still see a segfault (a bit different now).

panic: Segmentation fault: 11 -- stopping myself...
attempting to save variables to `octave-core'...
octave(38952,0x7fff72320960) malloc: *** mmap(size=3458773283022905344) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
panic: attempted clean up apparently failed -- aborting...
make[1]: *** [check] Abort trap: 6
make: *** [check] Error 2

From gdb ...

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000111f23118
0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase ()
(gdb) bt
#0  0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase ()
#1  0x00007fff8526c7c8 in __cxa_finalize ()
#2  0x00007fff8526c652 in exit ()
#3  0x00000001003918ff in clean_up_and_exit ()
#4  0x0000000100392420 in main_loop ()
#5  0x0000000100324fdf in octave_main ()
#6  0x0000000100000f44 in start ()

Ben

Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

John W. Eaton
Administrator
On  8-Dec-2011, Ben Abbott wrote:

|
| On Dec 8, 2011, at 11:07 AM, John W. Eaton wrote:
|
| > On  8-Dec-2011, Ben Abbott wrote:
| >
| > | With the change above, I still see a segfault.
| > |
| > | panic: Segmentation fault: 11 -- stopping myself...
| > | attempting to save variables to `octave-core'...
| > | terminate called after throwing an instance of 'std::length_error'
| > |   what():  basic_string::_S_create
| > | panic: attempted clean up apparently failed -- aborting...
| > | make[1]: *** [check] Abort trap: 6
| > | make: *** [check] Error 2
| > |
| > | I tried (naively?) restoring the patches to ov-typeinfo.cc and graphics.cc, but the segfault persists.
| >
| > Is there an onCleanup.oct file from a previous build still present?
| >
| > jwe
|
| After  (1) deleted everything named onCleanup.*, (2) maintainter-clean, (3) hg pull ; hg update -C, and (4) building octave.  I still see a segfault (a bit different now).
|
| panic: Segmentation fault: 11 -- stopping myself...
| attempting to save variables to `octave-core'...
| octave(38952,0x7fff72320960) malloc: *** mmap(size=3458773283022905344) failed (error code=12)
| *** error: can't allocate region
| *** set a breakpoint in malloc_error_break to debug
| terminate called after throwing an instance of 'std::bad_alloc'
|   what():  std::bad_alloc
| panic: attempted clean up apparently failed -- aborting...
| make[1]: *** [check] Abort trap: 6
| make: *** [check] Error 2

Does this happen when starting Octave?  Exiting?  Running tests?

| >From gdb ...
|
| Program received signal EXC_BAD_ACCESS, Could not access memory.
| Reason: KERN_INVALID_ADDRESS at address: 0x0000000111f23118
| 0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase ()
| (gdb) bt
| #0  0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase ()
| #1  0x00007fff8526c7c8 in __cxa_finalize ()
| #2  0x00007fff8526c652 in exit ()
| #3  0x00000001003918ff in clean_up_and_exit ()
| #4  0x0000000100392420 in main_loop ()
| #5  0x0000000100324fdf in octave_main ()
| #6  0x0000000100000f44 in start ()

Are you building without -g?

If this really is a case of an uncaught bad_alloc exception, then we
need to know where it is thrown.  In gdb, do

  (gdb) catch throw

then trigger the bug and gdb should stop at the point where the
exception is thrown.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

bpabbott
Administrator
On Dec 8, 2011, at 1:00 PM, John W. Eaton wrote:

> On  8-Dec-2011, Ben Abbott wrote:
>
> |  On Dec 8, 2011, at 11:07 AM, John W. Eaton wrote:
> |
> | > On  8-Dec-2011, Ben Abbott wrote:
> | >
> | > | With the change above, I still see a segfault.
> | > |
> | > | panic: Segmentation fault: 11 -- stopping myself...
> | > | attempting to save variables to `octave-core'...
> | > | terminate called after throwing an instance of 'std::length_error'
> | > |   what():  basic_string::_S_create
> | > | panic: attempted clean up apparently failed -- aborting...
> | > | make[1]: *** [check] Abort trap: 6
> | > | make: *** [check] Error 2
> | > |
> | > | I tried (naively?) restoring the patches to ov-typeinfo.cc and graphics.cc, but the segfault persists.
> | >
> | > Is there an onCleanup.oct file from a previous build still present?
> | >
> | > jwe
> |
> | After  (1) deleted everything named onCleanup.*, (2) maintainter-clean, (3) hg pull ; hg update -C, and (4) building octave.  I still see a segfault (a bit different now).
> |
> | panic: Segmentation fault: 11 -- stopping myself...
> | attempting to save variables to `octave-core'...
> | octave(38952,0x7fff72320960) malloc: *** mmap(size=3458773283022905344) failed (error code=12)
> | *** error: can't allocate region
> | *** set a breakpoint in malloc_error_break to debug
> | terminate called after throwing an instance of 'std::bad_alloc'
> |   what():  std::bad_alloc
> | panic: attempted clean up apparently failed -- aborting...
> | make[1]: *** [check] Abort trap: 6
> | make: *** [check] Error 2
>
> Does this happen when starting Octave?  Exiting?  Running tests?
>
> | >From gdb ...
> |
> | Program received signal EXC_BAD_ACCESS, Could not access memory.
> | Reason: KERN_INVALID_ADDRESS at address: 0x0000000111f23118
> | 0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase ()
> | (gdb) bt
> | #0  0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase ()
> | #1  0x00007fff8526c7c8 in __cxa_finalize ()
> | #2  0x00007fff8526c652 in exit ()
> | #3  0x00000001003918ff in clean_up_and_exit ()
> | #4  0x0000000100392420 in main_loop ()
> | #5  0x0000000100324fdf in octave_main ()
> | #6  0x0000000100000f44 in start ()
>
> Are you building without -g?
>
> If this really is a case of an uncaught bad_alloc exception, then we
> need to know where it is thrown.  In gdb, do
>
>  (gdb) catch throw
>
> then trigger the bug and gdb should stop at the point where the
> exception is thrown.
>
> jwe

I had noticed that I have a problem with the debug info ... First, "catch throw" gives me ...

>> fntests
Reading symbols for shared libraries . done

Integrated test scripts:

Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
  src/DLD-FUNCTIONS/__contourc__.cc ...................... PASS    1/1  
  src/DLD-FUNCTIONS/__delaunayn__.cc ..................... PASS    1/1  
  src/DLD-FUNCTIONS/__dispatch__.cc ...................... PASS    1/1  
  src/DLD-FUNCTIONS/__dsearchn__.cc ...................... PASS    1/1  
  src/DLD-FUNCTIONS/__fltk_uigetfile__.cc ................ PASS    1/1  
  src/DLD-FUNCTIONS/__glpk__.cc .......................... PASS    1/1  
  src/DLD-FUNCTIONS/__lin_interpn__.cc ................... PASS    1/1  
  src/DLD-FUNCTIONS/__magick_read__.cc ................... PASS    4/4  
  src/DLD-FUNCTIONS/__pchip_deriv__.cc ................... PASS    1/1  
  src/DLD-FUNCTIONS/__qp__.cc ............................ PASS    1/1  
  src/DLD-FUNCTIONS/__voronoi__.cc ....................... PASS    1/1  
  src/DLD-FUNCTIONS/besselj.cc ...........................Reading symbols for shared libraries . done
 PASS  180/180
  src/DLD-FUNCTIONS/betainc.cc ...........................Reading symbols for shared libraries . done
 PASS    6/6  
  src/DLD-FUNCTIONS/bsxfun.cc ............................Reading symbols for shared libraries . done
Reading symbols for shared libraries . done

Catchpoint 1 (exception thrown).
Catchpoint 1 (exception caught), throw location unknown, catch location unknown, exception type octave_execution_exception
0x00000001071c603d in __cxa_throw ()

Second, regarding the debug info, I'm missing something that should be obvious. My configure script is below, can you (someone?) spot what I've done wrong?

export PREFIX=/opt/local
export CC=/opt/local/bin/gcc-mp-4.5
export CXX=/opt/local/bin/g++-mp-4.5
export CXXCPP="/opt/local/bin/g++-mp-4.5 -E"
export F77=/opt/local/bin/gfortran-mp-4.5
export FC=/opt/local/bin/gfortran-mp-4.5
export CXXFLAGS="-pipe -O2 -g -m64 -gstabs"
export FFLAGS="$CXXFLAGS -D_THREAD_SAFE -pthread -gstabs"
export CFLAGS="$FFLAGS -lstdc++"
export LDFLAGS=-L$PREFIX/lib
export CPPFLAGS=-I$PREFIX/include
export BLAS_LIBS="-lcblas -lf77blas -latlas"
export LAPACK_LIBS=-llapack

./configure --prefix="/opt/local" --without-framework-carbon --with-x \
            --with-cholmod="-lcholmod -lmetis"

Ben



Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

John W. Eaton
Administrator
On  8-Dec-2011, Ben Abbott wrote:

| On Dec 8, 2011, at 1:00 PM, John W. Eaton wrote:
|
| > On  8-Dec-2011, Ben Abbott wrote:
| >
| > |  On Dec 8, 2011, at 11:07 AM, John W. Eaton wrote:
| > |
| > | > On  8-Dec-2011, Ben Abbott wrote:
| > | >
| > | > | With the change above, I still see a segfault.
| > | > |
| > | > | panic: Segmentation fault: 11 -- stopping myself...
| > | > | attempting to save variables to `octave-core'...
| > | > | terminate called after throwing an instance of 'std::length_error'
| > | > |   what():  basic_string::_S_create
| > | > | panic: attempted clean up apparently failed -- aborting...
| > | > | make[1]: *** [check] Abort trap: 6
| > | > | make: *** [check] Error 2
| > | > |
| > | > | I tried (naively?) restoring the patches to ov-typeinfo.cc and graphics.cc, but the segfault persists.
| > | >
| > | > Is there an onCleanup.oct file from a previous build still present?
| > | >
| > | > jwe
| > |
| > | After  (1) deleted everything named onCleanup.*, (2) maintainter-clean, (3) hg pull ; hg update -C, and (4) building octave.  I still see a segfault (a bit different now).
| > |
| > | panic: Segmentation fault: 11 -- stopping myself...
| > | attempting to save variables to `octave-core'...
| > | octave(38952,0x7fff72320960) malloc: *** mmap(size=3458773283022905344) failed (error code=12)
| > | *** error: can't allocate region
| > | *** set a breakpoint in malloc_error_break to debug
| > | terminate called after throwing an instance of 'std::bad_alloc'
| > |   what():  std::bad_alloc
| > | panic: attempted clean up apparently failed -- aborting...
| > | make[1]: *** [check] Abort trap: 6
| > | make: *** [check] Error 2
| >
| > Does this happen when starting Octave?  Exiting?  Running tests?
| >
| > | >From gdb ...
| > |
| > | Program received signal EXC_BAD_ACCESS, Could not access memory.
| > | Reason: KERN_INVALID_ADDRESS at address: 0x0000000111f23118
| > | 0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase ()
| > | (gdb) bt
| > | #0  0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase ()
| > | #1  0x00007fff8526c7c8 in __cxa_finalize ()
| > | #2  0x00007fff8526c652 in exit ()
| > | #3  0x00000001003918ff in clean_up_and_exit ()
| > | #4  0x0000000100392420 in main_loop ()
| > | #5  0x0000000100324fdf in octave_main ()
| > | #6  0x0000000100000f44 in start ()
| >
| > Are you building without -g?
| >
| > If this really is a case of an uncaught bad_alloc exception, then we
| > need to know where it is thrown.  In gdb, do
| >
| >  (gdb) catch throw
| >
| > then trigger the bug and gdb should stop at the point where the
| > exception is thrown.
| >
| > jwe
|
| I had noticed that I have a problem with the debug info ... First, "catch throw" gives me ...
|
| >> fntests
| Reading symbols for shared libraries . done
|
| Integrated test scripts:
|
| Reading symbols for shared libraries . done
| Reading symbols for shared libraries . done
| Reading symbols for shared libraries . done
| Reading symbols for shared libraries . done
| Reading symbols for shared libraries . done
|   src/DLD-FUNCTIONS/__contourc__.cc ...................... PASS    1/1  
|   src/DLD-FUNCTIONS/__delaunayn__.cc ..................... PASS    1/1  
|   src/DLD-FUNCTIONS/__dispatch__.cc ...................... PASS    1/1  
|   src/DLD-FUNCTIONS/__dsearchn__.cc ...................... PASS    1/1  
|   src/DLD-FUNCTIONS/__fltk_uigetfile__.cc ................ PASS    1/1  
|   src/DLD-FUNCTIONS/__glpk__.cc .......................... PASS    1/1  
|   src/DLD-FUNCTIONS/__lin_interpn__.cc ................... PASS    1/1  
|   src/DLD-FUNCTIONS/__magick_read__.cc ................... PASS    4/4  
|   src/DLD-FUNCTIONS/__pchip_deriv__.cc ................... PASS    1/1  
|   src/DLD-FUNCTIONS/__qp__.cc ............................ PASS    1/1  
|   src/DLD-FUNCTIONS/__voronoi__.cc ....................... PASS    1/1  
|   src/DLD-FUNCTIONS/besselj.cc ...........................Reading symbols for shared libraries . done
|  PASS  180/180
|   src/DLD-FUNCTIONS/betainc.cc ...........................Reading symbols for shared libraries . done
|  PASS    6/6  
|   src/DLD-FUNCTIONS/bsxfun.cc ............................Reading symbols for shared libraries . done
| Reading symbols for shared libraries . done
|
| Catchpoint 1 (exception thrown).
| Catchpoint 1 (exception caught), throw location unknown, catch location unknown, exception type octave_execution_exception
| 0x00000001071c603d in __cxa_throw ()

So this crash is happening because an exception is thrown somewhere
and isn't caught, not when quit is called explicitly?  So maybe this
is not related to my recent changes since I would expect a problem due
to that to only happen when quit is called to exit Octave.

| Second, regarding the debug info, I'm missing something that should be obvious. My configure script is below, can you (someone?) spot what I've done wrong?
|
| export PREFIX=/opt/local
| export CC=/opt/local/bin/gcc-mp-4.5
| export CXX=/opt/local/bin/g++-mp-4.5
| export CXXCPP="/opt/local/bin/g++-mp-4.5 -E"
| export F77=/opt/local/bin/gfortran-mp-4.5
| export FC=/opt/local/bin/gfortran-mp-4.5
| export CXXFLAGS="-pipe -O2 -g -m64 -gstabs"
| export FFLAGS="$CXXFLAGS -D_THREAD_SAFE -pthread -gstabs"
| export CFLAGS="$FFLAGS -lstdc++"
| export LDFLAGS=-L$PREFIX/lib
| export CPPFLAGS=-I$PREFIX/include
| export BLAS_LIBS="-lcblas -lf77blas -latlas"
| export LAPACK_LIBS=-llapack
|
| ./configure --prefix="/opt/local" --without-framework-carbon --with-x \
|             --with-cholmod="-lcholmod -lmetis"

Why did you choose -gstabs?  I don't know what is best for your
system, but I always use -ggdb3:

`-ggdb'
     Produce debugging information for use by GDB.  This means to use
     the most expressive format available (DWARF 2, stabs, or the
     native format if neither of those are supported), including GDB
     extensions if at all possible.

`-gstabs'
     Produce debugging information in stabs format (if that is
     supported), without GDB extensions.  This is the format used by
     DBX on most BSD systems.  On MIPS, Alpha and System V Release 4
     systems this option produces stabs debugging output which is not
     understood by DBX or SDB.  On System V Release 4 systems this
     option requires the GNU assembler.

`-gLEVEL'
`-ggdbLEVEL'
`-gstabsLEVEL'
`-gcoffLEVEL'
`-gxcoffLEVEL'
`-gvmsLEVEL'
     Request debugging information and also use LEVEL to specify how
     much information.  The default level is 2.

     Level 0 produces no debug information at all.  Thus, `-g0' negates
     `-g'.

     Level 1 produces minimal information, enough for making backtraces
     in parts of the program that you don't plan to debug.  This
     includes descriptions of functions and external variables, but no
     information about local variables and no line numbers.

     Level 3 includes extra information, such as all the macro
     definitions present in the program.  Some debuggers support macro
     expansion when you use `-g3'.

     `-gdwarf-2' does not accept a concatenated debug level, because
     GCC used to support an option `-gdwarf' that meant to generate
     debug information in version 1 of the DWARF format (which is very
     different from version 2), and it would have been too confusing.
     That debug format is long obsolete, but the option cannot be
     changed now.  Instead use an additional `-gLEVEL' option to change
     the debug level for DWARF2.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

Rik-4
I'm now seeing the same segfault as Ben.  Using 'catch throw' and the
following code which just starts and stops the interpreter I get a new
backtrace.

sh> run-octave -g
octave> exit

#0  0x00007ffff34acde0 in __cxa_throw () from /usr/lib/libstdc++.so.6
#1  0x00007ffff595690c in octave_throw_interrupt_exception () at
misc/quit.cc:57
#2  0x00007ffff73bc5ab in Fquit (args=...) at toplev.cc:723
#3  0x00007ffff741e673 in octave_builtin::do_multi_index_op (this=0x6d9d80,
nargout=0, args=..., lvalue_list=0x0)
    at ov-builtin.cc:131
#4  0x00007ffff741e4db in octave_builtin::do_multi_index_op (this=0x6d9d80,
nargout=0, args=...) at ov-builtin.cc:99
#5  0x00007ffff74c49e0 in octave_value::do_multi_index_op
(this=0x7fffffffcdd0, nargout=0, idx=...) at ov.cc:1268
#6  0x00007ffff7554517 in tree_identifier::rvalue (this=0xc3abf0,
nargout=0) at pt-id.cc:85
#7  0x00007ffff755472e in tree_identifier::rvalue1 (this=0xc3abf0,
nargout=0) at pt-id.cc:106
#8  0x00007ffff7550bf7 in tree_evaluator::visit_statement
(this=0x7ffff7ddbc98, stmt=...) at pt-eval.cc:739
#9  0x00007ffff756f59a in tree_statement::accept (this=0xc6ff40, tw=...) at
pt-stmt.cc:151
#10 0x00007ffff7550de2 in tree_evaluator::visit_statement_list
(this=0x7ffff7ddbc98, lst=...) at pt-eval.cc:775
#11 0x00007ffff756f948 in tree_statement_list::accept (this=0xc79a60,
tw=...) at pt-stmt.cc:215
#12 0x00007ffff73bb5e6 in main_loop () at toplev.cc:595
#13 0x00007ffff736e1dc in octave_main (argc=6, argv=0x7fffffffd2c8,
embedded=0) at octave.cc:938
#14 0x0000000000400769 in main (argc=6, argv=0x7fffffffd2c8) at main.c:35

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

Rik-5
In reply to this post by John W. Eaton
On 12/08/2011 10:16 AM, John W. Eaton wrote:
> So this crash is happening because an exception is thrown somewhere
> and isn't caught, not when quit is called explicitly?  So maybe this
> is not related to my recent changes since I would expect a problem due
> to that to only happen when quit is called to exit Octave.
If I go back one version from the tip to 14013:1734ebe27134 then the
segfault disappears.  So, it seems that the segfault associated with
onCleanup was cleared by moving it to liboctinterp.  However, there is
still a problem with the graphics stuff and gh_manager which became exposed
again in 14014.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

bpabbott
Administrator
In reply to this post by John W. Eaton

On Dec 8, 2011, at 1:16 PM, John W. Eaton wrote:

> On  8-Dec-2011, Ben Abbott wrote:
>
> | On Dec 8, 2011, at 1:00 PM, John W. Eaton wrote:
> |
> | > On  8-Dec-2011, Ben Abbott wrote:
> | >
> | > |  On Dec 8, 2011, at 11:07 AM, John W. Eaton wrote:
> | > |
> | > | > On  8-Dec-2011, Ben Abbott wrote:
> | > | >
> | > | > | With the change above, I still see a segfault.
> | > | > |
> | > | > | panic: Segmentation fault: 11 -- stopping myself...
> | > | > | attempting to save variables to `octave-core'...
> | > | > | terminate called after throwing an instance of 'std::length_error'
> | > | > |   what():  basic_string::_S_create
> | > | > | panic: attempted clean up apparently failed -- aborting...
> | > | > | make[1]: *** [check] Abort trap: 6
> | > | > | make: *** [check] Error 2
> | > | > |
> | > | > | I tried (naively?) restoring the patches to ov-typeinfo.cc and graphics.cc, but the segfault persists.
> | > | >
> | > | > Is there an onCleanup.oct file from a previous build still present?
> | > | >
> | > | > jwe
> | > |
> | > | After  (1) deleted everything named onCleanup.*, (2) maintainter-clean, (3) hg pull ; hg update -C, and (4) building octave.  I still see a segfault (a bit different now).
> | > |
> | > | panic: Segmentation fault: 11 -- stopping myself...
> | > | attempting to save variables to `octave-core'...
> | > | octave(38952,0x7fff72320960) malloc: *** mmap(size=3458773283022905344) failed (error code=12)
> | > | *** error: can't allocate region
> | > | *** set a breakpoint in malloc_error_break to debug
> | > | terminate called after throwing an instance of 'std::bad_alloc'
> | > |   what():  std::bad_alloc
> | > | panic: attempted clean up apparently failed -- aborting...
> | > | make[1]: *** [check] Abort trap: 6
> | > | make: *** [check] Error 2
> | >
> | > Does this happen when starting Octave?  Exiting?  Running tests?
> | >
> | > | >From gdb ...
> | > |
> | > | Program received signal EXC_BAD_ACCESS, Could not access memory.
> | > | Reason: KERN_INVALID_ADDRESS at address: 0x0000000111f23118
> | > | 0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase ()
> | > | (gdb) bt
> | > | #0  0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase ()
> | > | #1  0x00007fff8526c7c8 in __cxa_finalize ()
> | > | #2  0x00007fff8526c652 in exit ()
> | > | #3  0x00000001003918ff in clean_up_and_exit ()
> | > | #4  0x0000000100392420 in main_loop ()
> | > | #5  0x0000000100324fdf in octave_main ()
> | > | #6  0x0000000100000f44 in start ()
> | >
> | > Are you building without -g?
> | >
> | > If this really is a case of an uncaught bad_alloc exception, then we
> | > need to know where it is thrown.  In gdb, do
> | >
> | >  (gdb) catch throw
> | >
> | > then trigger the bug and gdb should stop at the point where the
> | > exception is thrown.
> | >
> | > jwe
> |
> | I had noticed that I have a problem with the debug info ... First, "catch throw" gives me ...
> |
> | >> fntests
> | Reading symbols for shared libraries . done
> |
> | Integrated test scripts:
> |
> | Reading symbols for shared libraries . done
> | Reading symbols for shared libraries . done
> | Reading symbols for shared libraries . done
> | Reading symbols for shared libraries . done
> | Reading symbols for shared libraries . done
> |   src/DLD-FUNCTIONS/__contourc__.cc ...................... PASS    1/1  
> |   src/DLD-FUNCTIONS/__delaunayn__.cc ..................... PASS    1/1  
> |   src/DLD-FUNCTIONS/__dispatch__.cc ...................... PASS    1/1  
> |   src/DLD-FUNCTIONS/__dsearchn__.cc ...................... PASS    1/1  
> |   src/DLD-FUNCTIONS/__fltk_uigetfile__.cc ................ PASS    1/1  
> |   src/DLD-FUNCTIONS/__glpk__.cc .......................... PASS    1/1  
> |   src/DLD-FUNCTIONS/__lin_interpn__.cc ................... PASS    1/1  
> |   src/DLD-FUNCTIONS/__magick_read__.cc ................... PASS    4/4  
> |   src/DLD-FUNCTIONS/__pchip_deriv__.cc ................... PASS    1/1  
> |   src/DLD-FUNCTIONS/__qp__.cc ............................ PASS    1/1  
> |   src/DLD-FUNCTIONS/__voronoi__.cc ....................... PASS    1/1  
> |   src/DLD-FUNCTIONS/besselj.cc ...........................Reading symbols for shared libraries . done
> |  PASS  180/180
> |   src/DLD-FUNCTIONS/betainc.cc ...........................Reading symbols for shared libraries . done
> |  PASS    6/6  
> |   src/DLD-FUNCTIONS/bsxfun.cc ............................Reading symbols for shared libraries . done
> | Reading symbols for shared libraries . done
> |
> | Catchpoint 1 (exception thrown).
> | Catchpoint 1 (exception caught), throw location unknown, catch location unknown, exception type octave_execution_exception
> | 0x00000001071c603d in __cxa_throw ()
>
> So this crash is happening because an exception is thrown somewhere
> and isn't caught, not when quit is called explicitly?  So maybe this
> is not related to my recent changes since I would expect a problem due
> to that to only happen when quit is called to exit Octave.
>
> | Second, regarding the debug info, I'm missing something that should be obvious. My configure script is below, can you (someone?) spot what I've done wrong?
> |
> | export PREFIX=/opt/local
> | export CC=/opt/local/bin/gcc-mp-4.5
> | export CXX=/opt/local/bin/g++-mp-4.5
> | export CXXCPP="/opt/local/bin/g++-mp-4.5 -E"
> | export F77=/opt/local/bin/gfortran-mp-4.5
> | export FC=/opt/local/bin/gfortran-mp-4.5
> | export CXXFLAGS="-pipe -O2 -g -m64 -gstabs"
> | export FFLAGS="$CXXFLAGS -D_THREAD_SAFE -pthread -gstabs"
> | export CFLAGS="$FFLAGS -lstdc++"
> | export LDFLAGS=-L$PREFIX/lib
> | export CPPFLAGS=-I$PREFIX/include
> | export BLAS_LIBS="-lcblas -lf77blas -latlas"
> | export LAPACK_LIBS=-llapack
> |
> | ./configure --prefix="/opt/local" --without-framework-carbon --with-x \
> |             --with-cholmod="-lcholmod -lmetis"
>
> Why did you choose -gstabs?  I don't know what is best for your
> system, but I always use -ggdb3:

Ok. Thanks!

I now see a seg-fault without needing to run the tests.

./run-octave -g
<snip>
(gdb) catch throw
<snip>
(gdb) run
<snip>
quit

Catchpoint 1 (exception thrown).
Catchpoint 1 (exception caught), throw location misc/quit.cc:57, catch location unknown, exception type octave_interrupt_exception
0x000000010362c03d in __cxa_throw ()
(gdb) bt
#0  0x000000010362c03d in __cxa_throw ()
#1  0x0000000102f37d5d in octave_throw_interrupt_exception () at misc/quit.cc:57
#2  0x000000010038f453 in Fquit (args=@0x7fff5fbfdac0) at toplev.cc:723
#3  0x000000010040a4cc in octave_builtin::do_multi_index_op (this=0x104784940, nargout=0, args=@0x7fff5fbfdac0, lvalue_list=0x7fff5fbfd870) at ov-builtin.cc:131
#4  0x000000010040abc4 in octave_builtin::do_multi_index_op (this=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at ov-builtin.cc:99
#5  0x00000001004f07d9 in octave_value::do_multi_index_op (this=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>) at ov.cc:1268
#6  0x00000001005a871d in tree_identifier::rvalue (this=0x1051469f0, nargout=0) at pt-id.cc:85
#7  0x00000001005a4d49 in tree_identifier::rvalue1 (this=0x1051469f0, nargout=0) at pt-id.cc:106
#8  0x0000000100597d3b in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:739
#9  0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x105146a20) at pt-eval.cc:775
#10 0x000000010039213e in main_loop () at toplev.cc:595
#11 0x0000000100324fdf in octave_main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>, embedded=0) at octave.cc:938
#12 0x0000000100000f44 in start ()
(gdb)

When try to run the tests ...

<snip>
  src/DLD-FUNCTIONS/bsxfun.cc ............................Reading symbols for shared libraries . done
Reading symbols for shared libraries . done

Catchpoint 1 (exception thrown).
Catchpoint 1 (exception caught), throw location misc/quit.cc:67, catch location unknown, exception type octave_execution_exception
0x000000010362c03d in __cxa_throw ()
(gdb) bt
#0  0x000000010362c03d in __cxa_throw ()
#1  0x0000000102f37dbc in octave_throw_execution_exception () at misc/quit.cc:67
#2  0x000000010031c0d7 in lo_error_handler (fmt=<value temporarily unavailable, due to optimizations>) at octave.cc:575
#3  0x0000000100061e94 in do_bsxfun_op<double, double, double> (x=@0x7fff5fbf7f40, y=@0x7fff5fbf7f20, op_vv=0x10153b8d0 <mx_inline_sub<double, double, double>>, op_sv=0x10153b810 <mx_inline_sub<double, double, double>>, op_vs=0x10153b750 <mx_inline_sub<double, double, double>>) at bsxfun-defs.cc:58
#4  0x000000010173001f in bsxfun_sub (x=<value temporarily unavailable, due to optimizations>, y=<value temporarily unavailable, due to optimizations>) at dNDArray.cc:929
#5  0x0000000105f8121c in bsxfun_forward_op<NDArray, bsxfun_sub> (x=<value temporarily unavailable, due to optimizations>, y=<value temporarily unavailable, due to optimizations>) at DLD-FUNCTIONS/bsxfun.cc:103
#6  0x0000000105f8cdd9 in Fbsxfun (args=<value temporarily unavailable, due to optimizations>) at DLD-FUNCTIONS/bsxfun.cc:216
#7  0x000000010040a4cc in octave_builtin::do_multi_index_op (this=0x10a300420, nargout=0, args=@0x1059589b0, lvalue_list=0x7fff5fbf8d50) at ov-builtin.cc:131
#8  0x0000000100409329 in octave_builtin::subsref (this=0x10a300420, type=@0x7fff5fbf92f0, idx=@0x7fff5fbf92a0, nargout=0, lvalue_list=0x0) at ov-builtin.cc:64
#9  0x000000010040a124 in octave_builtin::subsref (this=<value temporarily unavailable, due to optimizations>, type=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>) at ov-builtin.cc:47
#10 0x00000001004fa00e in octave_value::subsref (this=<value temporarily unavailable, due to optimizations>, type=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>) at ov.cc:1203
#11 0x00000001004fa0a5 in octave_value::subsref (this=<value temporarily unavailable, due to optimizations>, type=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>, lvalue_list=<value temporarily unavailable, due to optimizations>) at ov.cc:1214
#12 0x00000001005b4054 in tree_index_expression::rvalue (this=<value temporarily unavailable, due to optimizations>, nargout=0, lvalue_list=0x0) at pt-idx.cc:414
#13 0x00000001005b5793 in tree_index_expression::rvalue (this=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>) at pt-idx.cc:284
#14 0x00000001005ad429 in tree_index_expression::rvalue1 (this=0x105957640, nargout=0) at pt-idx.cc:425
#15 0x0000000100597d3b in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:739
#16 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x1059577b0) at pt-eval.cc:775
#17 0x00000001004eb083 in octave_user_function::do_multi_index_op (this=0x105957910, nargout=0, args=<value temporarily unavailable, due to optimizations>, lvalue_list=0x0) at ov-usr-fcn.cc:475
#18 0x00000001004e5d42 in octave_user_function::subsref (this=0x105957910, type=@0x7fff5fbf9bc0, idx=@0x7fff5fbf9b70, nargout=0, lvalue_list=0x0) at ov-usr-fcn.cc:327
#19 0x00000001004e6284 in octave_user_function::subsref (this=<value temporarily unavailable, due to optimizations>, type=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>) at ov-usr-fcn.cc:310
#20 0x00000001004fa00e in octave_value::subsref (this=<value temporarily unavailable, due to optimizations>, type=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>) at ov.cc:1203
#21 0x00000001004fa0a5 in octave_value::subsref (this=<value temporarily unavailable, due to optimizations>, type=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>, lvalue_list=<value temporarily unavailable, due to optimizations>) at ov.cc:1214
#22 0x00000001005b4054 in tree_index_expression::rvalue (this=<value temporarily unavailable, due to optimizations>, nargout=0, lvalue_list=0x0) at pt-idx.cc:414
#23 0x00000001005b5793 in tree_index_expression::rvalue (this=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>) at pt-idx.cc:284
#24 0x00000001002ae618 in eval_string (s=@0x7fff5fbf9c90, silent=false, parse_status=@0x7fff5fbf9e7c, nargout=0) at oct-parse.yy:4383
#25 0x00000001002ae8c5 in eval_string (silent=false, parse_status=@0x7fff5fbf9e7c, nargout=0) at oct-parse.yy:4436
#26 0x00000001002aedea in Feval (args=@0x105956a50, nargout=0) at oct-parse.yy:4494
#27 0x000000010040a4cc in octave_builtin::do_multi_index_op (this=0x10476c1e0, nargout=0, args=@0x105956a50, lvalue_list=0x7fff5fbf9ee0) at ov-builtin.cc:131
#28 0x0000000100409329 in octave_builtin::subsref (this=0x10476c1e0, type=@0x7fff5fbfa480, idx=@0x7fff5fbfa430, nargout=0, lvalue_list=0x0) at ov-builtin.cc:64
#29 0x000000010040a124 in octave_builtin::subsref (this=<value temporarily unavailable, due to optimizations>, type=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>) at ov-builtin.cc:47
#30 0x00000001004fa00e in octave_value::subsref (this=<value temporarily unavailable, due to optimizations>, type=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>) at ov.cc:1203
#31 0x00000001004fa0a5 in octave_value::subsref (this=<value temporarily unavailable, due to optimizations>, type=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>, lvalue_list=<value temporarily unavailable, due to optimizations>) at ov.cc:1214
#32 0x00000001005b4054 in tree_index_expression::rvalue (this=<value temporarily unavailable, due to optimizations>, nargout=0, lvalue_list=0x0) at pt-idx.cc:414
#33 0x00000001005b5793 in tree_index_expression::rvalue (this=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>) at pt-idx.cc:284
#34 0x00000001005ad429 in tree_index_expression::rvalue1 (this=0x106a28e00, nargout=0) at pt-idx.cc:425
#35 0x0000000100597d3b in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:739
#36 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106b60330) at pt-eval.cc:775
#37 0x00000001005967f8 in tree_evaluator::visit_try_catch_command (this=0x100c79780, cmd=@0x106ab96b0) at pt-eval.cc:891
#38 0x0000000100597c61 in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:709
#39 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106c21470) at pt-eval.cc:775
#40 0x0000000100597c61 in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:709
#41 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106cb49b0) at pt-eval.cc:775
#42 0x0000000100597c61 in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:709
#43 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106beea60) at pt-eval.cc:775
#44 0x0000000100598f5d in tree_evaluator::visit_simple_for_command (this=0x100c79780, cmd=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:344
#45 0x0000000100597c61 in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:709
#46 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106c0fee0) at pt-eval.cc:775
#47 0x00000001004eb083 in octave_user_function::do_multi_index_op (this=0x106a150a0, nargout=4, args=<value temporarily unavailable, due to optimizations>, lvalue_list=0x7fff5fbfb500) at ov-usr-fcn.cc:475
#48 0x00000001004e5d42 in octave_user_function::subsref (this=0x106a150a0, type=@0x7fff5fbfb200, idx=@0x7fff5fbfb1b0, nargout=4, lvalue_list=0x7fff5fbfb500) at ov-usr-fcn.cc:327
#49 0x00000001004fa08e in octave_value::subsref (this=<value temporarily unavailable, due to optimizations>, type=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>, lvalue_list=<value temporarily unavailable, due to optimizations>) at ov.cc:1212
#50 0x00000001005b4054 in tree_index_expression::rvalue (this=<value temporarily unavailable, due to optimizations>, nargout=4, lvalue_list=0x7fff5fbfb500) at pt-idx.cc:414
#51 0x0000000100585474 in tree_multi_assignment::rvalue (this=0x106d9f160) at pt-assign.cc:369
#52 0x00000001005842e9 in tree_multi_assignment::rvalue1 (this=0x106d9f160, nargout=0) at pt-assign.cc:324
#53 0x0000000100597d3b in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:739
#54 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106d9c9f0) at pt-eval.cc:775
#55 0x0000000100597c61 in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:709
#56 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106d9b930) at pt-eval.cc:775
#57 0x0000000100597c61 in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:709
#58 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106d985c0) at pt-eval.cc:775
#59 0x0000000100598f5d in tree_evaluator::visit_simple_for_command (this=0x100c79780, cmd=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:344
#60 0x0000000100597c61 in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:709
#61 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106d90f10) at pt-eval.cc:775
#62 0x00000001004eb083 in octave_user_function::do_multi_index_op (this=0x106da1a70, nargout=4, args=<value temporarily unavailable, due to optimizations>, lvalue_list=0x7fff5fbfc400) at ov-usr-fcn.cc:475
#63 0x00000001004e5d42 in octave_user_function::subsref (this=0x106da1a70, type=@0x7fff5fbfc180, idx=@0x7fff5fbfc130, nargout=4, lvalue_list=0x7fff5fbfc480) at ov-usr-fcn.cc:327
#64 0x00000001004fa08e in octave_value::subsref (this=<value temporarily unavailable, due to optimizations>, type=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>, lvalue_list=<value temporarily unavailable, due to optimizations>) at ov.cc:1212
#65 0x00000001005b4054 in tree_index_expression::rvalue (this=<value temporarily unavailable, due to optimizations>, nargout=4, lvalue_list=0x7fff5fbfc480) at pt-idx.cc:414
#66 0x0000000100585474 in tree_multi_assignment::rvalue (this=0x106d97300) at pt-assign.cc:369
#67 0x00000001005842e9 in tree_multi_assignment::rvalue1 (this=0x106d97300, nargout=0) at pt-assign.cc:324
#68 0x0000000100597d3b in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:739
#69 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106d97360) at pt-eval.cc:775
#70 0x0000000100597c61 in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:709
#71 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106d93ed0) at pt-eval.cc:775
#72 0x0000000100598f5d in tree_evaluator::visit_simple_for_command (this=0x100c79780, cmd=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:344
#73 0x0000000100597c61 in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:709
#74 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106d90f10) at pt-eval.cc:775
#75 0x00000001004eb083 in octave_user_function::do_multi_index_op (this=0x106da1a70, nargout=4, args=<value temporarily unavailable, due to optimizations>, lvalue_list=0x7fff5fbfd300) at ov-usr-fcn.cc:475
#76 0x00000001004e5d42 in octave_user_function::subsref (this=0x106da1a70, type=@0x7fff5fbfd050, idx=@0x7fff5fbfd000, nargout=4, lvalue_list=0x7fff5fbfd350) at ov-usr-fcn.cc:327
#77 0x00000001004fa08e in octave_value::subsref (this=<value temporarily unavailable, due to optimizations>, type=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>, lvalue_list=<value temporarily unavailable, due to optimizations>) at ov.cc:1212
#78 0x00000001005b4054 in tree_index_expression::rvalue (this=<value temporarily unavailable, due to optimizations>, nargout=4, lvalue_list=0x7fff5fbfd350) at pt-idx.cc:414
#79 0x0000000100585474 in tree_multi_assignment::rvalue (this=0x106db83f0) at pt-assign.cc:369
#80 0x00000001005842e9 in tree_multi_assignment::rvalue1 (this=0x106db83f0, nargout=0) at pt-assign.cc:324
#81 0x0000000100597d3b in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:739
#82 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106db8450) at pt-eval.cc:775
#83 0x0000000100598f5d in tree_evaluator::visit_simple_for_command (this=0x100c79780, cmd=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:344
#84 0x0000000100597c61 in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:709
#85 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106db18a0) at pt-eval.cc:775
#86 0x00000001005967f8 in tree_evaluator::visit_try_catch_command (this=0x100c79780, cmd=@0x106dc7a70) at pt-eval.cc:891
#87 0x0000000100597c61 in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:709
#88 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106d5bd60) at pt-eval.cc:775
#89 0x00000001004e9fe0 in octave_user_script::do_multi_index_op (this=0x106dc7bd0, nargout=0, args=<value temporarily unavailable, due to optimizations>) at ov-usr-fcn.cc:138
#90 0x00000001004f07d9 in octave_value::do_multi_index_op (this=<value temporarily unavailable, due to optimizations>, nargout=<value temporarily unavailable, due to optimizations>, idx=<value temporarily unavailable, due to optimizations>) at ov.cc:1268
#91 0x00000001005a871d in tree_identifier::rvalue (this=0x106d5b030, nargout=0) at pt-id.cc:85
#92 0x00000001005a4d49 in tree_identifier::rvalue1 (this=0x106d5b030, nargout=0) at pt-id.cc:106
#93 0x0000000100597d3b in tree_evaluator::visit_statement (this=<value temporarily unavailable, due to optimizations>, stmt=<value temporarily unavailable, due to optimizations>) at pt-eval.cc:739
#94 0x0000000100596f43 in tree_evaluator::visit_statement_list (this=0x100c79780, lst=@0x106d5b060) at pt-eval.cc:775
#95 0x000000010039213e in main_loop () at toplev.cc:595
#96 0x0000000100324fdf in octave_main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>, embedded=0) at octave.cc:938
#97 0x0000000100000f44 in start ()
(gdb)

Ben


Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

John W. Eaton
Administrator
In reply to this post by Rik-4
On  8-Dec-2011, Rik wrote:

| I'm now seeing the same segfault as Ben.  Using 'catch throw' and the
| following code which just starts and stops the interpreter I get a new
| backtrace.
|
| sh> run-octave -g
| octave> exit
|
| #0  0x00007ffff34acde0 in __cxa_throw () from /usr/lib/libstdc++.so.6
| #1  0x00007ffff595690c in octave_throw_interrupt_exception () at
| misc/quit.cc:57
| #2  0x00007ffff73bc5ab in Fquit (args=...) at toplev.cc:723
| #3  0x00007ffff741e673 in octave_builtin::do_multi_index_op (this=0x6d9d80,
| nargout=0, args=..., lvalue_list=0x0)
|     at ov-builtin.cc:131
| #4  0x00007ffff741e4db in octave_builtin::do_multi_index_op (this=0x6d9d80,
| nargout=0, args=...) at ov-builtin.cc:99
| #5  0x00007ffff74c49e0 in octave_value::do_multi_index_op
| (this=0x7fffffffcdd0, nargout=0, idx=...) at ov.cc:1268
| #6  0x00007ffff7554517 in tree_identifier::rvalue (this=0xc3abf0,
| nargout=0) at pt-id.cc:85
| #7  0x00007ffff755472e in tree_identifier::rvalue1 (this=0xc3abf0,
| nargout=0) at pt-id.cc:106
| #8  0x00007ffff7550bf7 in tree_evaluator::visit_statement
| (this=0x7ffff7ddbc98, stmt=...) at pt-eval.cc:739
| #9  0x00007ffff756f59a in tree_statement::accept (this=0xc6ff40, tw=...) at
| pt-stmt.cc:151
| #10 0x00007ffff7550de2 in tree_evaluator::visit_statement_list
| (this=0x7ffff7ddbc98, lst=...) at pt-eval.cc:775
| #11 0x00007ffff756f948 in tree_statement_list::accept (this=0xc79a60,
| tw=...) at pt-stmt.cc:215
| #12 0x00007ffff73bb5e6 in main_loop () at toplev.cc:595
| #13 0x00007ffff736e1dc in octave_main (argc=6, argv=0x7fffffffd2c8,
| embedded=0) at octave.cc:938
| #14 0x0000000000400769 in main (argc=6, argv=0x7fffffffd2c8) at main.c:35

Maybe I'm missing something, but that doesn't look like a segfault.
The quit function works by throwing an interrupt exception.  It is
supposed to be caught in main_loop in toplev.cc.  If that is not
happening, then you would see an abort on the uncaught exception.
Then the question is why isn't this exception being caught since
toplev.cc:595 is inside the try/catch block in main_loop.

If you do "catch catch" instead, is this exception caught?  If so,
does the segfault happen after this?  Is there a later exception that
is thrown and not caught?  If so, where is that one thrown?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

John W. Eaton
Administrator
In reply to this post by bpabbott
On  8-Dec-2011, Ben Abbott wrote:

| Catchpoint 1 (exception thrown).
| Catchpoint 1 (exception caught), throw location misc/quit.cc:67, catch location unknown, exception type octave_execution_exception
| 0x000000010362c03d in __cxa_throw ()
| (gdb) bt
| #0  0x000000010362c03d in __cxa_throw ()
| #1  0x0000000102f37dbc in octave_throw_execution_exception () at misc/quit.cc:67
| #2  0x000000010031c0d7 in lo_error_handler (fmt=<value temporarily unavailable, due to optimizations>) at octave.cc:575
| #3  0x0000000100061e94 in do_bsxfun_op<double, double, double> (x=@0x7fff5fbf7f40, y=@0x7fff5fbf7f20, op_vv=0x10153b8d0 <mx_inline_sub<double, double, double>>, op_sv=0x10153b810 <mx_inline_sub<double, double, double>>, op_vs=0x10153b750 <mx_inline_sub<double, double, double>>) at bsxfun-defs.cc:58
| ...
| #95 0x000000010039213e in main_loop () at toplev.cc:595
| #96 0x0000000100324fdf in octave_main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>, embedded=0) at octave.cc:938
| #97 0x0000000100000f44 in start ()

The code in main_loop is also supposed to catch execution exceptions.
Is that not happening for you in this case?  If you also use the gdb
command "catch catch" to stop when the exception is caught, does it
show you that this exception is caught somewhere?  If you continue on
from there, do you generate a segfault at some point?  Is there an
exception that is thrown but not caught?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

bpabbott
Administrator

On Dec 8, 2011, at 2:30 PM, John W. Eaton wrote:

> On  8-Dec-2011, Ben Abbott wrote:
>
> | Catchpoint 1 (exception thrown).
> | Catchpoint 1 (exception caught), throw location misc/quit.cc:67, catch location unknown, exception type octave_execution_exception
> | 0x000000010362c03d in __cxa_throw ()
> | (gdb) bt
> | #0  0x000000010362c03d in __cxa_throw ()
> | #1  0x0000000102f37dbc in octave_throw_execution_exception () at misc/quit.cc:67
> | #2  0x000000010031c0d7 in lo_error_handler (fmt=<value temporarily unavailable, due to optimizations>) at octave.cc:575
> | #3  0x0000000100061e94 in do_bsxfun_op<double, double, double> (x=@0x7fff5fbf7f40, y=@0x7fff5fbf7f20, op_vv=0x10153b8d0 <mx_inline_sub<double, double, double>>, op_sv=0x10153b810 <mx_inline_sub<double, double, double>>, op_vs=0x10153b750 <mx_inline_sub<double, double, double>>) at bsxfun-defs.cc:58
> | ...
> | #95 0x000000010039213e in main_loop () at toplev.cc:595
> | #96 0x0000000100324fdf in octave_main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>, embedded=0) at octave.cc:938
> | #97 0x0000000100000f44 in start ()
>
> The code in main_loop is also supposed to catch execution exceptions.
> Is that not happening for you in this case?  If you also use the gdb
> command "catch catch" to stop when the exception is caught, does it
> show you that this exception is caught somewhere?  If you continue on
> from there, do you generate a segfault at some point?  Is there an
> exception that is thrown but not caught?
>
> jwe


First, I tried starting and then quiting.

(gdb) catch catch
(gdb) run
quit

Catchpoint 1 (exception caught).
Catchpoint 1 (exception caught), throw location unknown, catch location toplev.cc:635, exception type octave_interrupt_exception
0x000000010362acbc in __cxa_begin_catch ()
(gdb) bt
#0  0x000000010362acbc in __cxa_begin_catch ()
#1  0x000000010039233c in main_loop () at toplev.cc:635
#2  0x0000000100324fdf in octave_main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>, embedded=0) at octave.cc:938
#3  0x0000000100000f44 in start ()
(gdb) continue
Continuing.
Program exited normally.
(gdb)

Next, I tried running fntests

(gdb) catch catch
(gdb) run
cd test/
fntests
Reading symbols for shared libraries . done

Integrated test scripts:

Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
  src/DLD-FUNCTIONS/__contourc__.cc ...................... PASS    1/1  
  src/DLD-FUNCTIONS/__delaunayn__.cc ..................... PASS    1/1  
  src/DLD-FUNCTIONS/__dispatch__.cc ...................... PASS    1/1  
  src/DLD-FUNCTIONS/__dsearchn__.cc ...................... PASS    1/1  
  src/DLD-FUNCTIONS/__fltk_uigetfile__.cc ................ PASS    1/1  
  src/DLD-FUNCTIONS/__glpk__.cc .......................... PASS    1/1  
  src/DLD-FUNCTIONS/__lin_interpn__.cc ................... PASS    1/1  
  src/DLD-FUNCTIONS/__magick_read__.cc ................... PASS    4/4  
  src/DLD-FUNCTIONS/__pchip_deriv__.cc ................... PASS    1/1  
  src/DLD-FUNCTIONS/__qp__.cc ............................ PASS    1/1  
  src/DLD-FUNCTIONS/__voronoi__.cc ....................... PASS    1/1  
  src/DLD-FUNCTIONS/besselj.cc ...........................Reading symbols for shared libraries . done
 PASS  180/180
  src/DLD-FUNCTIONS/betainc.cc ...........................Reading symbols for shared libraries . done
 PASS    6/6  
  src/DLD-FUNCTIONS/bsxfun.cc ............................Reading symbols for shared libraries . done
Reading symbols for shared libraries . done

Catchpoint 1 (exception caught).
Catchpoint 1 (exception caught), throw location unknown, catch location ov-builtin.cc:146, exception type octave_execution_exception
0x000000010362acbc in __cxa_begin_catch ()
(gdb) continue
Continuing.

Catchpoint 1 (exception caught).
Catchpoint 1 (exception caught), throw location unknown, catch location ov-builtin.cc:146, exception type octave_execution_exception
0x000000010362acbc in __cxa_begin_catch ()
(gdb) continue
Continuing.

Catchpoint 1 (exception caught).
Catchpoint 1 (exception caught), throw location unknown, catch location ov-builtin.cc:146, exception type octave_execution_exception
0x000000010362acbc in __cxa_begin_catch ()
(gdb) continue
Continuing.

Catchpoint 1 (exception caught).
Catchpoint 1 (exception caught), throw location unknown, catch location ov-builtin.cc:146, exception type octave_execution_exception
0x000000010362acbc in __cxa_begin_catch ()
(gdb) continue
Continuing.

Catchpoint 1 (exception caught).
Catchpoint 1 (exception caught), throw location unknown, catch location ov-builtin.cc:146, exception type octave_execution_exception
0x000000010362acbc in __cxa_begin_catch ()
(gdb) continue
Continuing.
 PASS   73/73  
  src/DLD-FUNCTIONS/cellfun.cc ........................... PASS  121/121
  src/DLD-FUNCTIONS/chol.cc ..............................Reading symbols for shared libraries . done

Catchpoint 1 (exception caught).
Catchpoint 1 (exception caught), throw location unknown, catch location ov-builtin.cc:146, exception type octave_execution_exception
0x000000010362acbc in __cxa_begin_catch ()

Many more exceptions are caught. Most of them at ov-builtin.cc:146. Others are ...

Catchpoint 1 (exception caught), throw location unknown, catch location utils.cc:1324, exception type octave_execution_exception

Catchpoint 1 (exception caught), throw location unknown, catch location pt-eval.cc:748, exception type octave_execution_exception

Catchpoint 1 (exception caught), throw location unknown, catch location DLD-FUNCTIONS/__magick_read__.cc:1195, exception type Magick::ErrorOption

Catchpoint 1 (exception caught), throw location unknown, catch location ov.cc:1905, exception type octave_execution_exception

When the tests complete and I "quit" ...

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000010cf9e118
0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase (this=0x100c37720, __x=<value temporarily unavailable, due to optimizations>) at graphics.h:2177
2177        delete rep;
(gdb) bt
#0  0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase (this=0x100c37720, __x=<value temporarily unavailable, due to optimizations>) at graphics.h:2177
#1  0x00007fff8526c7c8 in __cxa_finalize ()
#2  0x00007fff8526c652 in exit ()
#3  0x00000001003918ff in clean_up_and_exit (retval=<value temporarily unavailable, due to optimizations>) at toplev.cc:685
#4  0x0000000100392420 in main_loop () at toplev.cc:641
#5  0x0000000100324fdf in octave_main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>, embedded=0) at octave.cc:938
#6  0x0000000100000f44 in start ()
Current language:  auto; currently c++

Ben

Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

Rik-5
In reply to this post by John W. Eaton
On 12/08/2011 11:26 AM, John W. Eaton wrote:
> ks by throwing an interrupt exception. It is
> supposed to be caught in main_loop in toplev.cc. If that is not
> happening, then you would see an abort on the uncaught exception.
> Then the question is why isn't this exception being caught since
> toplev.cc:595 is inside the try/catch block in main_loop.
>
> If you do "catch catch"


Running the following code:
sh> run-octave -g
gdb> catch catch
gdb> run
octave> exit
 
I get

Catchpoint 1 (exception caught), 0x00007ffff34abcd0 in __cxa_begin_catch () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0x00007ffff34abcd0 in __cxa_begin_catch () from /usr/lib/libstdc++.so.6
#1  0x00007ffff73bb967 in main_loop () at toplev.cc:635                                                                         
#2  0x00007ffff736e3dc in octave_main (argc=6, argv=0x7fffffffd2c8, embedded=0) at octave.cc:938                                
#3  0x0000000000400769 in main (argc=6, argv=0x7fffffffd2c8) at main.c:35

From there I can single step through the code.  The relevant lines from toplev.cc are

637               recover_from_exception ();
638               octave_stdout << "\n";
639               if (quitting_gracefully)
640                 {
641                   clean_up_and_exit (exit_status);

I single step to the function call clean_up_and_exit which then generates a segfault.  The backtrace is

#0  0x00007ffff70be340 in ~graphics_toolkit (this=0xc73c88, __in_chrg=<value optimized out>) at graphics.h:2177
#1  0x00007ffff7244a7f in ~pair (this=0xc73c80, __in_chrg=<value optimized out>) at /usr/include/c++/4.4/bits/stl_pair.h:68
#2  0x00007ffff72544f4 in __gnu_cxx::new_allocator<std::pair<std::string const, graphics_toolkit> >::destroy(std::pair<std::string const, graphics_toolkit>*) () from /home/rik/wip/Projects_Mine/octave-dbg/src/.libs/liboctinterp.so.0
#3  0x00007ffff724ff53 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_destroy_node(std::_Rb_tree_node<std::pair<std::string const, graphics_toolkit> >*) ()
   from /home/rik/wip/Projects_Mine/octave-dbg/src/.libs/liboctinterp.so.0
#4  0x00007ffff7250093 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase(std::_Rb_tree_node<std::pair<std::string const, graphics_toolkit> >*) ()
   from /home/rik/wip/Projects_Mine/octave-dbg/src/.libs/liboctinterp.so.0
#5  0x00007ffff724a5a5 in ~_Rb_tree (this=0x7ffff7dd5860, __in_chrg=<value optimized out>)
    at /usr/include/c++/4.4/bits/stl_tree.h:614
#6  0x00007ffff7257c80 in std::map<std::string, graphics_toolkit, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::~map() () from /home/rik/wip/Projects_Mine/octave-dbg/src/.libs/liboctinterp.so.0
#7  0x00007ffff50a8630 in __cxa_finalize (d=0x7ffff7da3fe0) at cxa_finalize.c:56
#8  0x00007ffff7001756 in __do_global_dtors_aux () from /home/rik/wip/Projects_Mine/octave-dbg/src/.libs/liboctinterp.so.0
#9  0x0000000000000000 in ?? ()

Further single-stepping shows that it is this call in toplev.cc at line 685 that causes the problem.

    (*octave_exit) (retval == EOF ? 0 : retval);

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

John W. Eaton
Administrator
In reply to this post by bpabbott
On  8-Dec-2011, Ben Abbott wrote:

| When the tests complete and I "quit" ...
|
| Program received signal EXC_BAD_ACCESS, Could not access memory.
| Reason: KERN_INVALID_ADDRESS at address: 0x000000010cf9e118
| 0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase (this=0x100c37720, __x=<value temporarily unavailable, due to optimizations>) at graphics.h:2177
| 2177        delete rep;
| (gdb) bt
| #0  0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase (this=0x100c37720, __x=<value temporarily unavailable, due to optimizations>) at graphics.h:2177
| #1  0x00007fff8526c7c8 in __cxa_finalize ()
| #2  0x00007fff8526c652 in exit ()
| #3  0x00000001003918ff in clean_up_and_exit (retval=<value temporarily unavailable, due to optimizations>) at toplev.cc:685
| #4  0x0000000100392420 in main_loop () at toplev.cc:641
| #5  0x0000000100324fdf in octave_main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>, embedded=0) at octave.cc:938
| #6  0x0000000100000f44 in start ()
| Current language:  auto; currently c++

OK, line 2177 in graphics.h is inside the destructor for the
graphics_toolkit object, and that is being called by exit.  I
intended to explicitly close and delete toolkit objects before this
point.  Does the following patch work for you?  If so, I think I will
take some time to try to fix this bug report:

  https://savannah.gnu.org/bugs/?31583

by making it possible for toolkits to be registered without being
loaded.

jwe


diff --git a/src/graphics.cc b/src/graphics.cc
--- a/src/graphics.cc
+++ b/src/graphics.cc
@@ -2890,19 +2890,6 @@
   return available_toolkits["gnuplot"];
 }
 
-void
-graphics_toolkit::close_all_toolkits (void)
-{
-  while (! available_toolkits.empty ())
-    {
-      available_toolkits_iterator p = available_toolkits.begin ();
-
-      p->second.close ();
-
-      available_toolkits.erase (p);
-    }
-}
-
 std::map<std::string, graphics_toolkit> graphics_toolkit::available_toolkits;
 
 // ---------------------------------------------------------------------
diff --git a/src/graphics.h.in b/src/graphics.h.in
--- a/src/graphics.h.in
+++ b/src/graphics.h.in
@@ -2236,8 +2236,6 @@
   // Close the graphics toolkit.
   void close (void) { rep->close (); }
 
-  void close_all_toolkits (void);
-
   OCTINTERP_API static graphics_toolkit default_toolkit (void);
 
   static void register_toolkit (const graphics_toolkit& b)
@@ -2269,6 +2267,23 @@
     return m;
   }
 
+  static void close_all_toolkits (void)
+  {
+    while (! available_toolkits.empty ())
+      {
+        available_toolkits_iterator p = available_toolkits.begin ();
+
+        std::string name = p->first;
+
+        p->second.close ();
+
+        // The toolkit may have unregistered itself.  If not, we'll do
+        // it here.
+        if (available_toolkits.find (name) != available_toolkits.end ())
+          unregister_toolkit (name);
+      }
+  }
+
 private:
   base_graphics_toolkit *rep;
 
diff --git a/src/toplev.cc b/src/toplev.cc
--- a/src/toplev.cc
+++ b/src/toplev.cc
@@ -671,6 +671,8 @@
 
   OCTAVE_SAFE_CALL (gh_manager::close_all_figures, ());
 
+  OCTAVE_SAFE_CALL (graphics_toolkit::close_all_toolkits, ());
+
   OCTAVE_SAFE_CALL (symbol_table::cleanup, ());
 
   OCTAVE_SAFE_CALL (cleanup_parser, ());
Reply | Threaded
Open this post in threaded view
|

Re: segfault and onCleanup()

Rik-5
On 12/08/2011 12:37 PM, John W. Eaton wrote:

> On  8-Dec-2011, Ben Abbott wrote:
>
> | When the tests complete and I "quit" ...
> |
> | Program received signal EXC_BAD_ACCESS, Could not access memory.
> | Reason: KERN_INVALID_ADDRESS at address: 0x000000010cf9e118
> | 0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase (this=0x100c37720, __x=<value temporarily unavailable, due to optimizations>) at graphics.h:2177
> | 2177        delete rep;
> | (gdb) bt
> | #0  0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, graphics_toolkit> >, std::less<std::string>, std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase (this=0x100c37720, __x=<value temporarily unavailable, due to optimizations>) at graphics.h:2177
> | #1  0x00007fff8526c7c8 in __cxa_finalize ()
> | #2  0x00007fff8526c652 in exit ()
> | #3  0x00000001003918ff in clean_up_and_exit (retval=<value temporarily unavailable, due to optimizations>) at toplev.cc:685
> | #4  0x0000000100392420 in main_loop () at toplev.cc:641
> | #5  0x0000000100324fdf in octave_main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>, embedded=0) at octave.cc:938
> | #6  0x0000000100000f44 in start ()
> | Current language:  auto; currently c++
>
> OK, line 2177 in graphics.h is inside the destructor for the
> graphics_toolkit object, and that is being called by exit.  I
> intended to explicitly close and delete toolkit objects before this
> point.  Does the following patch work for you?  If so, I think I will
> take some time to try to fix this bug report:
>
>   https://savannah.gnu.org/bugs/?31583
>
> by making it possible for toolkits to be registered without being
> loaded.
>
> jwe
Okay, this final patch works for me and 'make check' passes cleanly.  Can
you also push the changes for ov-oncleanup.h to the repository?  I made
them by hand to get Octave to compile.

--Rik
12