octave-maintainers
[Top][All Lists]
Advanced

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

Re: segfault on 'make check'


From: Ben Abbott
Subject: Re: segfault on 'make check'
Date: Mon, 05 Dec 2011 21:45:53 -0500

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 via email to

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