segfault on 'make check'

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

segfault on 'make check'

Rik-5
12/4/11

Is anyone else getting a panic after running 'make check'?  I get the following

panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
make[1]: *** [check] Segmentation fault
make[1]: Leaving directory `/home/rik/wip/Projects_Mine/octave-dev/test'
make: *** [check] Error 2

The error first appeared for me with this changeset.

changeset:   13983:7dd7cccf0757
user:        John W. Eaton <[hidden email]>
date:        Sat Dec 03 04:34:17 2011 -0500
summary:     clean up memory allocated for singletons before exit

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

segfault on 'make check'

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

| 12/4/11
|
| Is anyone else getting a panic after running 'make check'?  I get the following
|
| panic: Segmentation fault -- stopping myself...
| attempting to save variables to `octave-core'...
| make[1]: *** [check] Segmentation fault
| make[1]: Leaving directory `/home/rik/wip/Projects_Mine/octave-dev/test'
| make: *** [check] Error 2
|
| The error first appeared for me with this changeset.
|
| changeset:   13983:7dd7cccf0757
| user:        John W. Eaton <[hidden email]>
| date:        Sat Dec 03 04:34:17 2011 -0500
| summary:     clean up memory allocated for singletons before exit

No, I'm not seeing crashes and I've been running make check a lot
while making these changes, including running the tests with valgrind.

Can you run the tests with gdb?  Do do that, either cd to the tests
directory and run make check to see what command is run and paste that
into the shell with "-g" added as an option to run-octave or edit the
generated tests/Makefile to add -g to the run-octave options.  (Maybe
we should make this easier to do...)

jwe
Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

Rik-4
On 12/04/2011 02:03 PM, John W. Eaton wrote:

> On  4-Dec-2011, Rik wrote:
>
> | 12/4/11
> |
> | Is anyone else getting a panic after running 'make check'?  I get the following
> |
> | panic: Segmentation fault -- stopping myself...
> | attempting to save variables to `octave-core'...
> | make[1]: *** [check] Segmentation fault
> | make[1]: Leaving directory `/home/rik/wip/Projects_Mine/octave-dev/test'
> | make: *** [check] Error 2
> |
> | The error first appeared for me with this changeset.
> |
> | changeset:   13983:7dd7cccf0757
> | user:        John W. Eaton <[hidden email]>
> | date:        Sat Dec 03 04:34:17 2011 -0500
> | summary:     clean up memory allocated for singletons before exit
>
> No, I'm not seeing crashes and I've been running make check a lot
> while making these changes, including running the tests with valgrind.
>
> Can you run the tests with gdb?  Do do that, either cd to the tests
> directory and run make check to see what command is run and paste that
> into the shell with "-g" added as an option to run-octave or edit the
> generated tests/Makefile to add -g to the run-octave options.  (Maybe
> we should make this easier to do...)
Here is the backtrace when running under gdb.  This is with tip
13989:b4d399c975de.  My gnulib was last updated 11/22/11.

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe6132e3d in ?? ()
(gdb) bt
#0  0x00007fffe6132e3d in ?? ()
#1  0x0000000000767558 in ?? ()
#2  0x000000000064c3d0 in ?? ()
#3  0x0000000000024cb0 in ?? ()
#4  0x000000000065c330 in ?? ()
#5  0x00007ffff58a9e40 in ?? () from /lib/libc.so.6
#6  0x0000000000014d50 in ?? ()
#7  0x0000000000b6ae50 in ?? ()
#8  0x00007ffff55a5460 in _int_free (av=0x61ca20, p=0x62cfe0) at malloc.c:5017
#9  0x00000000006123f0 in ?? ()
#10 0x00007fffffffd260 in ?? ()
#11 0x0000000000671b90 in ?? ()
#12 0x00007ffff7d8e8a0 in vtable for octave_value () from
/home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
#13 0x000000000062cfe0 in ?? ()
#14 0x0000000000632538 in ?? ()
#15 0x00000000006321e8 in ?? ()
#16 0x000000000061ca20 in ?? ()
#17 0x00007ffff7d8e8a0 in vtable for octave_value () from
/home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
#18 0x00007ffff7d8e8a0 in vtable for octave_value () from
/home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
#19 0x00007ffff75b37f3 in octave_value_typeinfo::~octave_value_typeinfo() ()
   from /home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
#20 0x00007ffff75b38d6 in octave_value_typeinfo::cleanup_instance() ()
   from /home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
#21 0x00007ffff630ef1b in singleton_cleanup_list::~singleton_cleanup_list() ()
   from /home/rik/wip/Projects_Mine/octave-dev/liboctave/.libs/liboctave.so.0
#22 0x00007ffff7498e61 in clean_up_and_exit(int) () from
/home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
#23 0x00007ffff7443669 in octave_main () from
/home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
#24 0x00007ffff5549c4d in __libc_start_main (main=<value optimized out>,
argc=<value optimized out>,
    ubp_av=<value optimized out>, init=<value optimized out>, fini=<value
optimized out>, rtld_fini=<value optimized out>,
    stack_end=0x7fffffffd208) at libc-start.c:226
#25 0x0000000000400689 in _start ()

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

Re: segfault on 'make check'

tmacchant
In reply to this post by John W. Eaton
Hello

I have updated the development source and built the octave.
changeset 13992:e1f76bfe0452
date Sun Dec 04 16:17:45 2011 -0500


At end of the test,

Please help improve Octave by contributing tests forthese files (see the list in the file fntests.log).
panic: Segmentation violation -- stopping myself...attempting to save variables to `octave-core'...

Regards

Tatsuro

--- On Mon, 2011/12/5, John W. Eaton wrote:

> On  4-Dec-2011, Rik wrote:
>
> | 12/4/11
> |
> | Is anyone else getting a panic after running 'make check'?  I get the following
> |
> | panic: Segmentation fault -- stopping myself...
> | attempting to save variables to `octave-core'...
> | make[1]: *** [check] Segmentation fault
> | make[1]: Leaving directory `/home/rik/wip/Projects_Mine/octave-dev/test'
> | make: *** [check] Error 2
> |
> | The error first appeared for me with this changeset.
> |
> | changeset:   13983:7dd7cccf0757
> | user:        John W. Eaton <[hidden email]>
> | date:        Sat Dec 03 04:34:17 2011 -0500
> | summary:     clean up memory allocated for singletons before exit
>
> No, I'm not seeing crashes and I've been running make check a lot
> while making these changes, including running the tests with valgrind.
>
> Can you run the tests with gdb?  Do do that, either cd to the tests
> directory and run make check to see what command is run and paste that
> into the shell with "-g" added as an option to run-octave or edit the
> generated tests/Makefile to add -g to the run-octave options.  (Maybe
> we should make this easier to do...)
>
> jwe
>
Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

tmacchant
In reply to this post by Rik-5
Hello

I have tried to test on gdb.
Program received signal SIGSEGV, Segmentation fault.
0x0f9a1f4f in ?? ()
(gdb) n.

warning: Invalid parameter passed to C runtime function.

warning: Invalid parameter passed to C runtime function.
 :
 :
warning: Invalid parameter passed to C runtime function.
 
Screen was frozen at
'warning: Invalid parameter passed to C runtime function.'
so that further information was not able to be gotten.

Regards

Tatsuro
--- On Mon, 2011/12/5, Tatsuro MATSUOKA  wrote:

> Hello
>
> I have updated the development source and built the octave.
> changeset 13992:e1f76bfe0452
> date    Sun Dec 04 16:17:45 2011 -0500
>
>
> At end of the test,
>
> Please help improve Octave by contributing tests forthese files (see the list in the file fntests.log).
> panic: Segmentation violation -- stopping myself...attempting to save variables to `octave-core'...
>
> Regards
>
> Tatsuro
>
> --- On Mon, 2011/12/5, John W. Eaton wrote:
>
> > On  4-Dec-2011, Rik wrote:
> >
> > | 12/4/11
> > |
> > | Is anyone else getting a panic after running 'make check'?  I get the following
> > |
> > | panic: Segmentation fault -- stopping myself...
> > | attempting to save variables to `octave-core'...
> > | make[1]: *** [check] Segmentation fault
> > | make[1]: Leaving directory `/home/rik/wip/Projects_Mine/octave-dev/test'
> > | make: *** [check] Error 2
> > |
> > | The error first appeared for me with this changeset.
> > |
> > | changeset:   13983:7dd7cccf0757
> > | user:        John W. Eaton <[hidden email]>
> > | date:        Sat Dec 03 04:34:17 2011 -0500
> > | summary:     clean up memory allocated for singletons before exit
> >
> > No, I'm not seeing crashes and I've been running make check a lot
> > while making these changes, including running the tests with valgrind.
> >
> > Can you run the tests with gdb?  Do do that, either cd to the tests
> > directory and run make check to see what command is run and paste that
> > into the shell with "-g" added as an option to run-octave or edit the
> > generated tests/Makefile to add -g to the run-octave options.  (Maybe
> > we should make this easier to do...)
> >
> > jwe
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

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

| Here is the backtrace when running under gdb.  This is with tip
| 13989:b4d399c975de.  My gnulib was last updated 11/22/11.
|
| Program received signal SIGSEGV, Segmentation fault.
| 0x00007fffe6132e3d in ?? ()
| (gdb) bt
| #0  0x00007fffe6132e3d in ?? ()
| #1  0x0000000000767558 in ?? ()
| #2  0x000000000064c3d0 in ?? ()
| #3  0x0000000000024cb0 in ?? ()
| #4  0x000000000065c330 in ?? ()
| #5  0x00007ffff58a9e40 in ?? () from /lib/libc.so.6
| #6  0x0000000000014d50 in ?? ()
| #7  0x0000000000b6ae50 in ?? ()
| #8  0x00007ffff55a5460 in _int_free (av=0x61ca20, p=0x62cfe0) at malloc.c:5017
| #9  0x00000000006123f0 in ?? ()
| #10 0x00007fffffffd260 in ?? ()
| #11 0x0000000000671b90 in ?? ()
| #12 0x00007ffff7d8e8a0 in vtable for octave_value () from
| /home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
| #13 0x000000000062cfe0 in ?? ()
| #14 0x0000000000632538 in ?? ()
| #15 0x00000000006321e8 in ?? ()
| #16 0x000000000061ca20 in ?? ()
| #17 0x00007ffff7d8e8a0 in vtable for octave_value () from
| /home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
| #18 0x00007ffff7d8e8a0 in vtable for octave_value () from
| /home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
| #19 0x00007ffff75b37f3 in octave_value_typeinfo::~octave_value_typeinfo() ()
|    from /home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
| #20 0x00007ffff75b38d6 in octave_value_typeinfo::cleanup_instance() ()
|    from /home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
| #21 0x00007ffff630ef1b in singleton_cleanup_list::~singleton_cleanup_list() ()
|    from /home/rik/wip/Projects_Mine/octave-dev/liboctave/.libs/liboctave.so.0
| #22 0x00007ffff7498e61 in clean_up_and_exit(int) () from
| /home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
| #23 0x00007ffff7443669 in octave_main () from
| /home/rik/wip/Projects_Mine/octave-dev/src/.libs/liboctinterp.so.0
| #24 0x00007ffff5549c4d in __libc_start_main (main=<value optimized out>,
| argc=<value optimized out>,
|     ubp_av=<value optimized out>, init=<value optimized out>, fini=<value
| optimized out>, rtld_fini=<value optimized out>,
|     stack_end=0x7fffffffd208) at libc-start.c:226
| #25 0x0000000000400689 in _start ()

I can't tell what could cause the crash.  Did you compile with -g?  If
not, could you use -g and do this again so we can get more info about
precisely where the crash is happening?  Or could you step through the
singleton_cleanup_list destructor and see whether
octave_value_typeinfo::cleanup_instance is the first cleanup_instance
function that is called, or whether others are called successfully.
The octave_value_typeinfo destructor doesn't even do anything
explicitly.  I don't know what it means that the function called from
there is "vtable".

jwe
Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

marco atzeri-2
In reply to this post by Rik-5
On 12/4/2011 10:40 PM, Rik wrote:

> 12/4/11
>
> Is anyone else getting a panic after running 'make check'?  I get the following
>
> panic: Segmentation fault -- stopping myself...
> attempting to save variables to `octave-core'...
> make[1]: *** [check] Segmentation fault
> make[1]: Leaving directory `/home/rik/wip/Projects_Mine/octave-dev/test'
> make: *** [check] Error 2
>
> The error first appeared for me with this changeset.
>
> changeset:   13983:7dd7cccf0757
> user:        John W. Eaton<[hidden email]>
> date:        Sat Dec 03 04:34:17 2011 -0500
> summary:     clean up memory allocated for singletons before exit
>
> --Rik

I noticed the same on cygwin with gcc-4.5.3
between

changeset:   13984:1126c2907878
user:        John W. Eaton <[hidden email]>
date:        Sat Dec 03 05:23:52 2011 -0500
summary:     avoid accessing tm_gmtoff from struct tm unless it is

and

changeset:   13973:2c664266e9d0
user:        John W. Eaton <[hidden email]>
date:        Fri Dec 02 03:51:37 2011 -0500
summary:     clean up parser memory on exit

In the middle I was planning to test manually due to the tm_gmtoff issue.

Regards
Marco


Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

Rik-4
In reply to this post by John W. Eaton
On 12/04/2011 09:06 PM, John W. Eaton wrote:
> I can't tell what could cause the crash.  Did you compile with -g?  If
> not, could you use -g and do this again so we can get more info about
> precisely where the crash is happening?  Or could you step through the
> singleton_cleanup_list destructor and see whether
> octave_value_typeinfo::cleanup_instance is the first cleanup_instance
> function that is called, or whether others are called successfully.
> The octave_value_typeinfo destructor doesn't even do anything
> explicitly.  I don't know what it means that the function called from
> there is "vtable".
I pulled the latest changes from gnulib today (12/5/11).  I updated to the
latest tip (13998:6e9bf84dec3c).  I ran 'make maintainer-clean' and then a
full build starting with autogen.sh and configuring all compiler flags for
'-g -O0'.  There is still a segfault when exiting, but now it is definitely
related to the FLTK toolkit.

For the following code:
run-octave -g
> graphics_toolkit fltk
> plot (1:10);
> exit

The error and backtrace is

/m: fccache.c:507: FcCacheFini: Assertion `fcCacheChains[i] == ((void *)0)'
failed.

Program received signal SIGABRT, Aborted.
0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
        in ../nptl/sysdeps/unix/sysv/linux/raise.c

#0  0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff50aa5c0 in *__GI_abort () at abort.c:92
#2  0x00007ffff509f941 in *__GI___assert_fail (assertion=0x7ffff3f427c8
"fcCacheChains[i] == ((void *)0)",
    file=<value optimized out>, line=507, function=0x7ffff3f42830
"FcCacheFini") at assert.c:81
#3  0x00007ffff3f2a4e5 in ?? () from /usr/lib/libfontconfig.so.1
#4  0x00007ffff3f35d6f in FcFini () from /usr/lib/libfontconfig.so.1
#5  0x00007ffff73c94b5 in ~ft_manager (this=0xd835a0, __in_chrg=<value
optimized out>) at txt-eng-ft.cc:140
#6  0x00007ffff73c93b7 in ft_manager::cleanup_instance () at txt-eng-ft.cc:94
#7  0x00007ffff60d72c8 in ~singleton_cleanup_list (this=0x60e350,
__in_chrg=<value optimized out>) at singleton-cleanup.cc:39
#8  0x00007ffff73c54a9 in singleton_cleanup_list::cleanup () at
../liboctave/singleton-cleanup.h:26
#9  0x00007ffff73c2488 in clean_up_and_exit (retval=0) at toplev.cc:697
#10 0x00007ffff73c1ef6 in main_loop () at toplev.cc:640
#11 0x00007ffff7374934 in octave_main (argc=6, argv=0x7fffffffd2c8,
embedded=0) at octave.cc:938
#12 0x0000000000400769 in main (argc=6, argv=0x7fffffffd2c8) at main.c:35

I set a breakpoint in ~singleton_cleanup and most of the ::cleanup_instance
() routines seem to work fine.  I had to step through about 15 before
triggering the segfault in ft_manager::cleanup_instance.  There is no
segfault if gnuplot is used as the toolkit.

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

Re: segfault on 'make check'

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

| On 12/04/2011 09:06 PM, John W. Eaton wrote:
| > I can't tell what could cause the crash.  Did you compile with -g?  If
| > not, could you use -g and do this again so we can get more info about
| > precisely where the crash is happening?  Or could you step through the
| > singleton_cleanup_list destructor and see whether
| > octave_value_typeinfo::cleanup_instance is the first cleanup_instance
| > function that is called, or whether others are called successfully.
| > The octave_value_typeinfo destructor doesn't even do anything
| > explicitly.  I don't know what it means that the function called from
| > there is "vtable".
| I pulled the latest changes from gnulib today (12/5/11).  I updated to the
| latest tip (13998:6e9bf84dec3c).  I ran 'make maintainer-clean' and then a
| full build starting with autogen.sh and configuring all compiler flags for
| '-g -O0'.  There is still a segfault when exiting, but now it is definitely
| related to the FLTK toolkit.
|
| For the following code:
| run-octave -g
| > graphics_toolkit fltk
| > plot (1:10);
| > exit
|
| The error and backtrace is
|
| /m: fccache.c:507: FcCacheFini: Assertion `fcCacheChains[i] == ((void *)0)'
| failed.
|
| Program received signal SIGABRT, Aborted.
| 0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
| ../nptl/sysdeps/unix/sysv/linux/raise.c:64
| 64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
|         in ../nptl/sysdeps/unix/sysv/linux/raise.c
|
| #0  0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
| ../nptl/sysdeps/unix/sysv/linux/raise.c:64
| #1  0x00007ffff50aa5c0 in *__GI_abort () at abort.c:92
| #2  0x00007ffff509f941 in *__GI___assert_fail (assertion=0x7ffff3f427c8
| "fcCacheChains[i] == ((void *)0)",
|     file=<value optimized out>, line=507, function=0x7ffff3f42830
| "FcCacheFini") at assert.c:81
| #3  0x00007ffff3f2a4e5 in ?? () from /usr/lib/libfontconfig.so.1
| #4  0x00007ffff3f35d6f in FcFini () from /usr/lib/libfontconfig.so.1
| #5  0x00007ffff73c94b5 in ~ft_manager (this=0xd835a0, __in_chrg=<value
| optimized out>) at txt-eng-ft.cc:140
| #6  0x00007ffff73c93b7 in ft_manager::cleanup_instance () at txt-eng-ft.cc:94
| #7  0x00007ffff60d72c8 in ~singleton_cleanup_list (this=0x60e350,
| __in_chrg=<value optimized out>) at singleton-cleanup.cc:39
| #8  0x00007ffff73c54a9 in singleton_cleanup_list::cleanup () at
| ../liboctave/singleton-cleanup.h:26
| #9  0x00007ffff73c2488 in clean_up_and_exit (retval=0) at toplev.cc:697
| #10 0x00007ffff73c1ef6 in main_loop () at toplev.cc:640
| #11 0x00007ffff7374934 in octave_main (argc=6, argv=0x7fffffffd2c8,
| embedded=0) at octave.cc:938
| #12 0x0000000000400769 in main (argc=6, argv=0x7fffffffd2c8) at main.c:35
|
| I set a breakpoint in ~singleton_cleanup and most of the ::cleanup_instance
| () routines seem to work fine.  I had to step through about 15 before
| triggering the segfault in ft_manager::cleanup_instance.  There is no
| segfault if gnuplot is used as the toolkit.

Thanks, I'm able to duplicate that problem.

For now, I checked in the following change:

  http://hg.savannah.gnu.org/hgweb/octave/rev/1221086f1ba5

I don't claim that this is a proper fix, but it avoids the problem for
me.  Does it also prevent the segfault for you?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

Rik-4
On 12/05/2011 01:10 PM, John W. Eaton wrote:

> On  5-Dec-2011, Rik wrote:
>
> | On 12/04/2011 09:06 PM, John W. Eaton wrote:
> | > I can't tell what could cause the crash.  Did you compile with -g?  If
> | > not, could you use -g and do this again so we can get more info about
> | > precisely where the crash is happening?  Or could you step through the
> | > singleton_cleanup_list destructor and see whether
> | > octave_value_typeinfo::cleanup_instance is the first cleanup_instance
> | > function that is called, or whether others are called successfully.
> | > The octave_value_typeinfo destructor doesn't even do anything
> | > explicitly.  I don't know what it means that the function called from
> | > there is "vtable".
> | I pulled the latest changes from gnulib today (12/5/11).  I updated to the
> | latest tip (13998:6e9bf84dec3c).  I ran 'make maintainer-clean' and then a
> | full build starting with autogen.sh and configuring all compiler flags for
> | '-g -O0'.  There is still a segfault when exiting, but now it is definitely
> | related to the FLTK toolkit.
> |
> | For the following code:
> | run-octave -g
> | > graphics_toolkit fltk
> | > plot (1:10);
> | > exit
> |
> | The error and backtrace is
> |
> | /m: fccache.c:507: FcCacheFini: Assertion `fcCacheChains[i] == ((void *)0)'
> | failed.
> |
> | Program received signal SIGABRT, Aborted.
> | 0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
> | ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> | 64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> |         in ../nptl/sysdeps/unix/sysv/linux/raise.c
> |
> | #0  0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
> | ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> | #1  0x00007ffff50aa5c0 in *__GI_abort () at abort.c:92
> | #2  0x00007ffff509f941 in *__GI___assert_fail (assertion=0x7ffff3f427c8
> | "fcCacheChains[i] == ((void *)0)",
> |     file=<value optimized out>, line=507, function=0x7ffff3f42830
> | "FcCacheFini") at assert.c:81
> | #3  0x00007ffff3f2a4e5 in ?? () from /usr/lib/libfontconfig.so.1
> | #4  0x00007ffff3f35d6f in FcFini () from /usr/lib/libfontconfig.so.1
> | #5  0x00007ffff73c94b5 in ~ft_manager (this=0xd835a0, __in_chrg=<value
> | optimized out>) at txt-eng-ft.cc:140
> | #6  0x00007ffff73c93b7 in ft_manager::cleanup_instance () at txt-eng-ft.cc:94
> | #7  0x00007ffff60d72c8 in ~singleton_cleanup_list (this=0x60e350,
> | __in_chrg=<value optimized out>) at singleton-cleanup.cc:39
> | #8  0x00007ffff73c54a9 in singleton_cleanup_list::cleanup () at
> | ../liboctave/singleton-cleanup.h:26
> | #9  0x00007ffff73c2488 in clean_up_and_exit (retval=0) at toplev.cc:697
> | #10 0x00007ffff73c1ef6 in main_loop () at toplev.cc:640
> | #11 0x00007ffff7374934 in octave_main (argc=6, argv=0x7fffffffd2c8,
> | embedded=0) at octave.cc:938
> | #12 0x0000000000400769 in main (argc=6, argv=0x7fffffffd2c8) at main.c:35
> |
> | I set a breakpoint in ~singleton_cleanup and most of the ::cleanup_instance
> | () routines seem to work fine.  I had to step through about 15 before
> | triggering the segfault in ft_manager::cleanup_instance.  There is no
> | segfault if gnuplot is used as the toolkit.
>
> Thanks, I'm able to duplicate that problem.
>
> For now, I checked in the following change:
>
>   http://hg.savannah.gnu.org/hgweb/octave/rev/1221086f1ba5
>
> I don't claim that this is a proper fix, but it avoids the problem for
> me.  Does it also prevent the segfault for you?
It prevents one segfault.  I get another when trying to create the images
for the documentation in doc/interpreter.  For example, the following code
segfaults.

cd doc/interpreter
rm voronoi.txt
make all

I can work around this one by using the same fix you did but for
gh_manager.  See the attached patch.

After that everything finally builds.  But I still get a segfault while
running 'make check'.  The backtrace is just two hex addresses and no
indication of source files or anything else.  However, when I
single-stepped through the cleanup routine it was octave_value_typeinfo
that was the problem.  So if I also apply segfault2.patch then everything
works.

--Rik

segfault.patch (304 bytes) Download Attachment
segfault2.patch (363 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

Michael Godfrey
In reply to this post by John W. Eaton
I now, with your latest fix,( txt-eng-ft.cc) get a different seg fault when ./run-octave
is used in the make build script.  But, I can do ./run-octave and ./run-octave -f
OK .  But, running the command:
../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'txt');"
from doc/interpreter always faults as attached.


Michael






seg_fault (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

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

On Dec 5, 2011, at 4:10 PM, John W. Eaton wrote:

> On  5-Dec-2011, Rik wrote:
>
> | On 12/04/2011 09:06 PM, John W. Eaton wrote:
> | > I can't tell what could cause the crash.  Did you compile with -g?  If
> | > not, could you use -g and do this again so we can get more info about
> | > precisely where the crash is happening?  Or could you step through the
> | > singleton_cleanup_list destructor and see whether
> | > octave_value_typeinfo::cleanup_instance is the first cleanup_instance
> | > function that is called, or whether others are called successfully.
> | > The octave_value_typeinfo destructor doesn't even do anything
> | > explicitly.  I don't know what it means that the function called from
> | > there is "vtable".
> | I pulled the latest changes from gnulib today (12/5/11).  I updated to the
> | latest tip (13998:6e9bf84dec3c).  I ran 'make maintainer-clean' and then a
> | full build starting with autogen.sh and configuring all compiler flags for
> | '-g -O0'.  There is still a segfault when exiting, but now it is definitely
> | related to the FLTK toolkit.
> |
> | For the following code:
> | run-octave -g
> | > graphics_toolkit fltk
> | > plot (1:10);
> | > exit
> |
> | The error and backtrace is
> |
> | /m: fccache.c:507: FcCacheFini: Assertion `fcCacheChains[i] == ((void *)0)'
> | failed.
> |
> | Program received signal SIGABRT, Aborted.
> | 0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
> | ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> | 64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> |         in ../nptl/sysdeps/unix/sysv/linux/raise.c
> |
> | #0  0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
> | ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> | #1  0x00007ffff50aa5c0 in *__GI_abort () at abort.c:92
> | #2  0x00007ffff509f941 in *__GI___assert_fail (assertion=0x7ffff3f427c8
> | "fcCacheChains[i] == ((void *)0)",
> |     file=<value optimized out>, line=507, function=0x7ffff3f42830
> | "FcCacheFini") at assert.c:81
> | #3  0x00007ffff3f2a4e5 in ?? () from /usr/lib/libfontconfig.so.1
> | #4  0x00007ffff3f35d6f in FcFini () from /usr/lib/libfontconfig.so.1
> | #5  0x00007ffff73c94b5 in ~ft_manager (this=0xd835a0, __in_chrg=<value
> | optimized out>) at txt-eng-ft.cc:140
> | #6  0x00007ffff73c93b7 in ft_manager::cleanup_instance () at txt-eng-ft.cc:94
> | #7  0x00007ffff60d72c8 in ~singleton_cleanup_list (this=0x60e350,
> | __in_chrg=<value optimized out>) at singleton-cleanup.cc:39
> | #8  0x00007ffff73c54a9 in singleton_cleanup_list::cleanup () at
> | ../liboctave/singleton-cleanup.h:26
> | #9  0x00007ffff73c2488 in clean_up_and_exit (retval=0) at toplev.cc:697
> | #10 0x00007ffff73c1ef6 in main_loop () at toplev.cc:640
> | #11 0x00007ffff7374934 in octave_main (argc=6, argv=0x7fffffffd2c8,
> | embedded=0) at octave.cc:938
> | #12 0x0000000000400769 in main (argc=6, argv=0x7fffffffd2c8) at main.c:35
> |
> | I set a breakpoint in ~singleton_cleanup and most of the ::cleanup_instance
> | () routines seem to work fine.  I had to step through about 15 before
> | triggering the segfault in ft_manager::cleanup_instance.  There is no
> | segfault if gnuplot is used as the toolkit.
>
> Thanks, I'm able to duplicate that problem.
>
> For now, I checked in the following change:
>
>  http://hg.savannah.gnu.org/hgweb/octave/rev/1221086f1ba5
>
> I don't claim that this is a proper fix, but it avoids the problem for
> me.  Does it also prevent the segfault for you?
>
> jwe

I hadn't seen a seg-fault before, but now "make check" ends with ...

-------------------------- begin cut-n-paste --------------------------
Summary:

  PASS  10156
  FAIL      1

There were 2 expected failures (see fntests.log for details).

Expected failures are known bugs.  Please help improve Octave
by contributing fixes for them.

246 (of 805) .m files have no tests.

37 (of 153) .cc files have no tests.

Please help improve Octave by contributing tests for
these files (see the list in the file fntests.log).


panic: Segmentation fault: 11 -- stopping myself...
attempting to save variables to `octave-core'...
-------------------------- end cut-n-paste  --------------------------

After several minutes the core is still dumping (maybe a hang?)

Ben


Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

tmacchant
In reply to this post by John W. Eaton


--- On Tue, 2011/12/6, John W. Eatonwrote:

> For now, I checked in the following change:
>
>   http://hg.savannah.gnu.org/hgweb/octave/rev/1221086f1ba5
>
> I don't claim that this is a proper fix, but it avoids the problem for
> me.  Does it also prevent the segfault for you?

Using the source (changeset 13999:1221086f1ba5), I have rebuilt octave (MinGW).

The fntests still causes Segmentation violation after test is finished.

*************************************************
Please help improve Octave by contributing tests for
these files (see the list in the file fntests.log).

panic: Segmentation violation -- stopping myself...
attempting to save variables to `octave-core'...
**************************************************

Regards

Tatsuro
Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

Michael Godfrey
In reply to this post by John W. Eaton
John,

I tried make -i  and it runs for most of the ../../octave
calls in doc/interpreter directory.  Maybe about 6 or 8
seg fault.  And, make check   runs through with only the
one fail (svds.m)  which I have been getting for a while.

So, there is something odd going on in the build script...

Michael

Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

bpabbott
Administrator
In reply to this post by bpabbott

On Dec 5, 2011, at 6:00 PM, Ben Abbott wrote:

>
> On Dec 5, 2011, at 4:10 PM, John W. Eaton wrote:
>
>> On  5-Dec-2011, Rik wrote:
>>
>> | On 12/04/2011 09:06 PM, John W. Eaton wrote:
>> | > I can't tell what could cause the crash.  Did you compile with -g?  If
>> | > not, could you use -g and do this again so we can get more info about
>> | > precisely where the crash is happening?  Or could you step through the
>> | > singleton_cleanup_list destructor and see whether
>> | > octave_value_typeinfo::cleanup_instance is the first cleanup_instance
>> | > function that is called, or whether others are called successfully.
>> | > The octave_value_typeinfo destructor doesn't even do anything
>> | > explicitly.  I don't know what it means that the function called from
>> | > there is "vtable".
>> | I pulled the latest changes from gnulib today (12/5/11).  I updated to the
>> | latest tip (13998:6e9bf84dec3c).  I ran 'make maintainer-clean' and then a
>> | full build starting with autogen.sh and configuring all compiler flags for
>> | '-g -O0'.  There is still a segfault when exiting, but now it is definitely
>> | related to the FLTK toolkit.
>> |
>> | For the following code:
>> | run-octave -g
>> | > graphics_toolkit fltk
>> | > plot (1:10);
>> | > exit
>> |
>> | The error and backtrace is
>> |
>> | /m: fccache.c:507: FcCacheFini: Assertion `fcCacheChains[i] == ((void *)0)'
>> | failed.
>> |
>> | Program received signal SIGABRT, Aborted.
>> | 0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
>> | ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> | 64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>> |         in ../nptl/sysdeps/unix/sysv/linux/raise.c
>> |
>> | #0  0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
>> | ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> | #1  0x00007ffff50aa5c0 in *__GI_abort () at abort.c:92
>> | #2  0x00007ffff509f941 in *__GI___assert_fail (assertion=0x7ffff3f427c8
>> | "fcCacheChains[i] == ((void *)0)",
>> |     file=<value optimized out>, line=507, function=0x7ffff3f42830
>> | "FcCacheFini") at assert.c:81
>> | #3  0x00007ffff3f2a4e5 in ?? () from /usr/lib/libfontconfig.so.1
>> | #4  0x00007ffff3f35d6f in FcFini () from /usr/lib/libfontconfig.so.1
>> | #5  0x00007ffff73c94b5 in ~ft_manager (this=0xd835a0, __in_chrg=<value
>> | optimized out>) at txt-eng-ft.cc:140
>> | #6  0x00007ffff73c93b7 in ft_manager::cleanup_instance () at txt-eng-ft.cc:94
>> | #7  0x00007ffff60d72c8 in ~singleton_cleanup_list (this=0x60e350,
>> | __in_chrg=<value optimized out>) at singleton-cleanup.cc:39
>> | #8  0x00007ffff73c54a9 in singleton_cleanup_list::cleanup () at
>> | ../liboctave/singleton-cleanup.h:26
>> | #9  0x00007ffff73c2488 in clean_up_and_exit (retval=0) at toplev.cc:697
>> | #10 0x00007ffff73c1ef6 in main_loop () at toplev.cc:640
>> | #11 0x00007ffff7374934 in octave_main (argc=6, argv=0x7fffffffd2c8,
>> | embedded=0) at octave.cc:938
>> | #12 0x0000000000400769 in main (argc=6, argv=0x7fffffffd2c8) at main.c:35
>> |
>> | I set a breakpoint in ~singleton_cleanup and most of the ::cleanup_instance
>> | () routines seem to work fine.  I had to step through about 15 before
>> | triggering the segfault in ft_manager::cleanup_instance.  There is no
>> | segfault if gnuplot is used as the toolkit.
>>
>> Thanks, I'm able to duplicate that problem.
>>
>> For now, I checked in the following change:
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/1221086f1ba5
>>
>> I don't claim that this is a proper fix, but it avoids the problem for
>> me.  Does it also prevent the segfault for you?
>>
>> jwe
>
> I hadn't seen a seg-fault before, but now "make check" ends with ...
>
> -------------------------- begin cut-n-paste --------------------------
> Summary:
>
>  PASS  10156
>  FAIL      1
>
> There were 2 expected failures (see fntests.log for details).
>
> Expected failures are known bugs.  Please help improve Octave
> by contributing fixes for them.
>
> 246 (of 805) .m files have no tests.
>
> 37 (of 153) .cc files have no tests.
>
> Please help improve Octave by contributing tests for
> these files (see the list in the file fntests.log).
>
>
> panic: Segmentation fault: 11 -- stopping myself...
> attempting to save variables to `octave-core'...
> -------------------------- end cut-n-paste  --------------------------
>
> After several minutes the core is still dumping (maybe a hang?)
>
> Ben

The one failure I had was with svds. I verified that I can reliably produce a seg-fault by  "test svds; quit"

So I tried running "test svds;  quit" from gdb.  I The bt is  below.

PASSES 5 out of 5 tests
>> quit

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000010fcbd912
0x000000010fcbd912 in ?? ()
(gdb) bt
#0  0x000000010fcbd912 in ?? ()
Cannot access memory at address 0x10fcbd912
#1  0x000000010fcbdc81 in ?? ()
#2  0x00000001004e3600 in octave_value_typeinfo::~octave_value_typeinfo ()
#3  0x00000001004e373d in octave_value_typeinfo::cleanup_instance ()
#4  0x00000001052bad93 in singleton_cleanup_list::~singleton_cleanup_list ()
#5  0x0000000100396082 in clean_up_and_exit ()
#6  0x00000001003969c0 in main_loop ()
#7  0x0000000100329c9f in octave_main ()
#8  0x0000000100000f44 in start ()

I'm rebuilding with "-g". I'll add more info tomorrow.

Ben

Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

marco atzeri-2
In reply to this post by Rik-4
On 12/5/2011 11:27 PM, Rik wrote:

> On 12/05/2011 01:10 PM, John W. Eaton wrote:
>> On  5-Dec-2011, Rik wrote:
>>
>> | On 12/04/2011 09:06 PM, John W. Eaton wrote:
>> |>  I can't tell what could cause the crash.  Did you compile with -g?  If
>> |>  not, could you use -g and do this again so we can get more info about
>> |>  precisely where the crash is happening?  Or could you step through the
>> |>  singleton_cleanup_list destructor and see whether
>> |>  octave_value_typeinfo::cleanup_instance is the first cleanup_instance
>> |>  function that is called, or whether others are called successfully.
>> |>  The octave_value_typeinfo destructor doesn't even do anything
>> |>  explicitly.  I don't know what it means that the function called from
>> |>  there is "vtable".
>> | I pulled the latest changes from gnulib today (12/5/11).  I updated to the
>> | latest tip (13998:6e9bf84dec3c).  I ran 'make maintainer-clean' and then a
>> | full build starting with autogen.sh and configuring all compiler flags for
>> | '-g -O0'.  There is still a segfault when exiting, but now it is definitely
>> | related to the FLTK toolkit.
>> |
>> | For the following code:
>> | run-octave -g
>> |>  graphics_toolkit fltk
>> |>  plot (1:10);
>> |>  exit
>> |
>> | The error and backtrace is
>> |
>> | /m: fccache.c:507: FcCacheFini: Assertion `fcCacheChains[i] == ((void *)0)'
>> | failed.
>> |
>> | Program received signal SIGABRT, Aborted.
>> | 0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
>> | ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> | 64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>> |         in ../nptl/sysdeps/unix/sysv/linux/raise.c
>> |
>> | #0  0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
>> | ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> | #1  0x00007ffff50aa5c0 in *__GI_abort () at abort.c:92
>> | #2  0x00007ffff509f941 in *__GI___assert_fail (assertion=0x7ffff3f427c8
>> | "fcCacheChains[i] == ((void *)0)",
>> |     file=<value optimized out>, line=507, function=0x7ffff3f42830
>> | "FcCacheFini") at assert.c:81
>> | #3  0x00007ffff3f2a4e5 in ?? () from /usr/lib/libfontconfig.so.1
>> | #4  0x00007ffff3f35d6f in FcFini () from /usr/lib/libfontconfig.so.1
>> | #5  0x00007ffff73c94b5 in ~ft_manager (this=0xd835a0, __in_chrg=<value
>> | optimized out>) at txt-eng-ft.cc:140
>> | #6  0x00007ffff73c93b7 in ft_manager::cleanup_instance () at txt-eng-ft.cc:94
>> | #7  0x00007ffff60d72c8 in ~singleton_cleanup_list (this=0x60e350,
>> | __in_chrg=<value optimized out>) at singleton-cleanup.cc:39
>> | #8  0x00007ffff73c54a9 in singleton_cleanup_list::cleanup () at
>> | ../liboctave/singleton-cleanup.h:26
>> | #9  0x00007ffff73c2488 in clean_up_and_exit (retval=0) at toplev.cc:697
>> | #10 0x00007ffff73c1ef6 in main_loop () at toplev.cc:640
>> | #11 0x00007ffff7374934 in octave_main (argc=6, argv=0x7fffffffd2c8,
>> | embedded=0) at octave.cc:938
>> | #12 0x0000000000400769 in main (argc=6, argv=0x7fffffffd2c8) at main.c:35
>> |
>> | I set a breakpoint in ~singleton_cleanup and most of the ::cleanup_instance
>> | () routines seem to work fine.  I had to step through about 15 before
>> | triggering the segfault in ft_manager::cleanup_instance.  There is no
>> | segfault if gnuplot is used as the toolkit.
>>
>> Thanks, I'm able to duplicate that problem.
>>
>> For now, I checked in the following change:
>>
>>    http://hg.savannah.gnu.org/hgweb/octave/rev/1221086f1ba5
>>
>> I don't claim that this is a proper fix, but it avoids the problem for
>> me.  Does it also prevent the segfault for you?
> It prevents one segfault.  I get another when trying to create the images
> for the documentation in doc/interpreter.  For example, the following code
> segfaults.
>
> cd doc/interpreter
> rm voronoi.txt
> make all
>
> I can work around this one by using the same fix you did but for
> gh_manager.  See the attached patch.
>
> After that everything finally builds.  But I still get a segfault while
> running 'make check'.  The backtrace is just two hex addresses and no
> indication of source files or anything else.  However, when I
> single-stepped through the cleanup routine it was octave_value_typeinfo
> that was the problem.  So if I also apply segfault2.patch then everything
> works.
>
> --Rik

same on cygwin.
With the 2 patches "make check" completes clean

Regards
Marco

Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

bpabbott
Administrator
In reply to this post by bpabbott
On Dec 5, 2011, at 9:45 PM, Ben Abbott wrote:

> On Dec 5, 2011, at 6:00 PM, Ben Abbott wrote:
>
>> On Dec 5, 2011, at 4:10 PM, John W. Eaton wrote:
>>
>>> On  5-Dec-2011, Rik wrote:
>>>
>>> | On 12/04/2011 09:06 PM, John W. Eaton wrote:
>>> | > I can't tell what could cause the crash.  Did you compile with -g?  If
>>> | > not, could you use -g and do this again so we can get more info about
>>> | > precisely where the crash is happening?  Or could you step through the
>>> | > singleton_cleanup_list destructor and see whether
>>> | > octave_value_typeinfo::cleanup_instance is the first cleanup_instance
>>> | > function that is called, or whether others are called successfully.
>>> | > The octave_value_typeinfo destructor doesn't even do anything
>>> | > explicitly.  I don't know what it means that the function called from
>>> | > there is "vtable".
>>> | I pulled the latest changes from gnulib today (12/5/11).  I updated to the
>>> | latest tip (13998:6e9bf84dec3c).  I ran 'make maintainer-clean' and then a
>>> | full build starting with autogen.sh and configuring all compiler flags for
>>> | '-g -O0'.  There is still a segfault when exiting, but now it is definitely
>>> | related to the FLTK toolkit.
>>> |
>>> | For the following code:
>>> | run-octave -g
>>> | > graphics_toolkit fltk
>>> | > plot (1:10);
>>> | > exit
>>> |
>>> | The error and backtrace is
>>> |
>>> | /m: fccache.c:507: FcCacheFini: Assertion `fcCacheChains[i] == ((void *)0)'
>>> | failed.
>>> |
>>> | Program received signal SIGABRT, Aborted.
>>> | 0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
>>> | ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>>> | 64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>>> |         in ../nptl/sysdeps/unix/sysv/linux/raise.c
>>> |
>>> | #0  0x00007ffff50a6a75 in *__GI_raise (sig=<value optimized out>) at
>>> | ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>>> | #1  0x00007ffff50aa5c0 in *__GI_abort () at abort.c:92
>>> | #2  0x00007ffff509f941 in *__GI___assert_fail (assertion=0x7ffff3f427c8
>>> | "fcCacheChains[i] == ((void *)0)",
>>> |     file=<value optimized out>, line=507, function=0x7ffff3f42830
>>> | "FcCacheFini") at assert.c:81
>>> | #3  0x00007ffff3f2a4e5 in ?? () from /usr/lib/libfontconfig.so.1
>>> | #4  0x00007ffff3f35d6f in FcFini () from /usr/lib/libfontconfig.so.1
>>> | #5  0x00007ffff73c94b5 in ~ft_manager (this=0xd835a0, __in_chrg=<value
>>> | optimized out>) at txt-eng-ft.cc:140
>>> | #6  0x00007ffff73c93b7 in ft_manager::cleanup_instance () at txt-eng-ft.cc:94
>>> | #7  0x00007ffff60d72c8 in ~singleton_cleanup_list (this=0x60e350,
>>> | __in_chrg=<value optimized out>) at singleton-cleanup.cc:39
>>> | #8  0x00007ffff73c54a9 in singleton_cleanup_list::cleanup () at
>>> | ../liboctave/singleton-cleanup.h:26
>>> | #9  0x00007ffff73c2488 in clean_up_and_exit (retval=0) at toplev.cc:697
>>> | #10 0x00007ffff73c1ef6 in main_loop () at toplev.cc:640
>>> | #11 0x00007ffff7374934 in octave_main (argc=6, argv=0x7fffffffd2c8,
>>> | embedded=0) at octave.cc:938
>>> | #12 0x0000000000400769 in main (argc=6, argv=0x7fffffffd2c8) at main.c:35
>>> |
>>> | I set a breakpoint in ~singleton_cleanup and most of the ::cleanup_instance
>>> | () routines seem to work fine.  I had to step through about 15 before
>>> | triggering the segfault in ft_manager::cleanup_instance.  There is no
>>> | segfault if gnuplot is used as the toolkit.
>>>
>>> Thanks, I'm able to duplicate that problem.
>>>
>>> For now, I checked in the following change:
>>>
>>> http://hg.savannah.gnu.org/hgweb/octave/rev/1221086f1ba5
>>>
>>> I don't claim that this is a proper fix, but it avoids the problem for
>>> me.  Does it also prevent the segfault for you?
>>>
>>> jwe
>>
>> I hadn't seen a seg-fault before, but now "make check" ends with ...
>>
>> -------------------------- begin cut-n-paste --------------------------
>> Summary:
>>
>> PASS  10156
>> FAIL      1
>>
>> There were 2 expected failures (see fntests.log for details).
>>
>> Expected failures are known bugs.  Please help improve Octave
>> by contributing fixes for them.
>>
>> 246 (of 805) .m files have no tests.
>>
>> 37 (of 153) .cc files have no tests.
>>
>> Please help improve Octave by contributing tests for
>> these files (see the list in the file fntests.log).
>>
>>
>> panic: Segmentation fault: 11 -- stopping myself...
>> attempting to save variables to `octave-core'...
>> -------------------------- end cut-n-paste  --------------------------
>>
>> After several minutes the core is still dumping (maybe a hang?)
>>
>> Ben
>
> The one failure I had was with svds. I verified that I can reliably produce a seg-fault by  "test svds; quit"
>
> So I tried running "test svds;  quit" from gdb.  I The bt is  below.
>
> PASSES 5 out of 5 tests
>>> quit
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x000000010fcbd912
> 0x000000010fcbd912 in ?? ()
> (gdb) bt
> #0  0x000000010fcbd912 in ?? ()
> Cannot access memory at address 0x10fcbd912
> #1  0x000000010fcbdc81 in ?? ()
> #2  0x00000001004e3600 in octave_value_typeinfo::~octave_value_typeinfo ()
> #3  0x00000001004e373d in octave_value_typeinfo::cleanup_instance ()
> #4  0x00000001052bad93 in singleton_cleanup_list::~singleton_cleanup_list ()
> #5  0x0000000100396082 in clean_up_and_exit ()
> #6  0x00000001003969c0 in main_loop ()
> #7  0x0000000100329c9f in octave_main ()
> #8  0x0000000100000f44 in start ()
>
> I'm rebuilding with "-g". I'll add more info tomorrow.
>
> Ben


After applying the two patches, segfault.patch & segfault2.patch (from Rik's earlier reply), I'm able to build and run "make check".

Ben

Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

tmacchant
Hello
 After applying the two patches, segfault.patch & segfault2.patch (from Rik's earlier reply), I'm able to run "make check".
(MInGW)
Tatsuro
Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

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

| > | The error and backtrace is
| > |
| > | /m: fccache.c:507: FcCacheFini: Assertion `fcCacheChains[i] == ((void *)0)'
| > | failed.
| > |
| > | Program received signal SIGABRT, Aborted.

Are we using fontconfig incorrectly or is it buggy?  I noticed that
valgrind produces some warnings related to fontconfig functions, but I
did not try to fix them.

Also, I don't see the other crashes.  I'm using Debian x86_64.  What
kind of system do you have?

Although we can apparently avoid the crashes by not calling the
cleanup functions, it seems we are just hiding some other problems if
we do that.  Or there is some error in the way the cleanup functions
work that I'm not seeing.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: segfault on 'make check'

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

| On  5-Dec-2011, Rik wrote:
|
| | > | The error and backtrace is
| | > |
| | > | /m: fccache.c:507: FcCacheFini: Assertion `fcCacheChains[i] == ((void *)0)'
| | > | failed.
| | > |
| | > | Program received signal SIGABRT, Aborted.
|
| Are we using fontconfig incorrectly or is it buggy?  I noticed that
| valgrind produces some warnings related to fontconfig functions, but I
| did not try to fix them.
|
| Also, I don't see the other crashes.  I'm using Debian x86_64.  What
| kind of system do you have?
|
| Although we can apparently avoid the crashes by not calling the
| cleanup functions, it seems we are just hiding some other problems if
| we do that.  Or there is some error in the way the cleanup functions
| work that I'm not seeing.

After looking at this for a while, I think the assertion failure in
fontconfig is a bug in fontconfig, but I don't have a simple example
that will cause the failure.

I checked in a few more changes that seem to fix the crashes for me.
For now, I'm skipping the cleanup function for gh_manager.  I intend
to fix it properly but I haven't quite finished the change yet.

jwe
12