[Bug-apl] gdb and the Emacs mode segfault

[David B. Lamkins]

I was able to get a core dump of the segfault caused by attempting to
)load an APL file with Emacs mode active.

address@hidden ~]$ 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 (
    address@hidden "main.cc", address@hidden)
    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
address@hidden ~]$ 

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 );
}