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?