This was just fixed, actually. You might want to try with the latest version. It should work now.
Regards, Elias On 4 May 2014 02:45, "David B. Lamkins" <dlamk...@gmail.com> wrote: > I was able to get a core dump of the segfault caused by attempting to > )load an APL file with Emacs mode active. > > [dlamkins@morganthe ~]$ gdb `which apl` -c core.2134 > GNU gdb (GDB) Fedora 7.6.50.20130731-19.fc20 > Copyright (C) 2013 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word". > .. > Reading symbols from /usr/local/bin/apl...done. > [New LWP 2134] > [New LWP 2138] > [New LWP 2137] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Core was generated by `/usr/local/bin/apl --rawCIN --emacs'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007fd8c85b1098 in ?? () from /lib64/libgcc_s.so.1 > Missing separate debuginfos, use: debuginfo-install > blas-3.4.2-3.fc20.x86_64 glibc-2.18-12.fc20.x86_64 > lapack-3.4.2-3.fc20.x86_64 libgcc-4.8.2-7.fc20.x86_64 > libgfortran-4.8.2-7.fc20.x86_64 libgomp-4.8.2-7.fc20.x86_64 > libquadmath-4.8.2-7.fc20.x86_64 libstdc++-4.8.2-7.fc20.x86_64 > ncurses-libs-5.9-12.20130511.fc20.x86_64 readline-6.2-8.fc20.x86_64 > (gdb) bt > #0 0x00007fd8c85b1098 in ?? () from /lib64/libgcc_s.so.1 > #1 0x00007fd8c85b1f99 in _Unwind_Backtrace () from /lib64/libgcc_s.so.1 > #2 0x00007fd8c82e61e6 in backtrace () from /lib64/libc.so.6 > #3 0x00000000004448a0 in Backtrace::show ( > file=file@entry=0x533480 "main.cc", line=line@entry=122) > at Backtrace.cc:276 > #4 0x000000000047a72a in signal_SEGV_handler () at main.cc:122 > #5 <signal handler called> > #6 0x00007fd8c1547730 in ?? () > #7 0x0000000000476307 in Input::get_user_line ( > prompt=0x80f230 <Workspace::the_workspace+527600>) at Input.cc:223 > #8 0x00000000004765f4 in Input::get_line () at Input.cc:150 > #9 0x0000000000461f2d in Command::process_line () at Command.cc:61 > #10 0x0000000000522e9d in Workspace::immediate_execution > (exit_on_error=false) > at Workspace.cc:129 > #11 0x00000000004352d5 in main (argc=3, _argv=<optimized out>) at > main.cc:466 > (gdb) quit > [dlamkins@morganthe ~]$ > > This is with svn 235. > > Input.cc:223 is the (*start_input)() call: > > const unsigned char * > Input::get_user_line(const UCS_string * prompt) > { > if (start_input) (*start_input)(); > ... > > which, I think (determined by code inspection; not gdb), points to > active_disable in emacs.cc. That, in turn, ultimately invokes > set_active(): > > void set_active( bool v ) > { > pthread_mutex_lock( &apl_main_lock ); > if( !apl_active && !v ) { > std::cerr << "Unlocking while the lock is unlocked" << > std::endl; > abort(); > } > if( v ) { > while( apl_active ) { > pthread_cond_wait( &apl_main_cond, &apl_main_lock ); > } > } > apl_active = v; > pthread_cond_broadcast( &apl_main_cond ); > pthread_mutex_unlock( &apl_main_lock ); > } > > > >
