Re: [Bug-apl] Crash with stack trace

2017-01-18 Thread Elias Mårtenson
Thanks. I think it's clear that the crash happens when Emacs requests information from the APL interpreter. The Emacs mode does that all the time, for example when computing candidates for symbol completion. Is there a way to disable the stack trace stuff so that I can catch the crash in gdb when

Re: [Bug-apl] Crash with stack trace

2017-01-18 Thread Juergen Sauermann
Hi Elias, from the Assert'ions point of view it looks as if you are trying to index an empty UCS_string in  FnCommand::run_command(). I would recommend to check the size() of each UCS_string created in FnCommand::run_command(). I am have seen p

Re: [Bug-apl] Crash with stack trace

2017-01-17 Thread Elias Mårtenson
I wasn't using the SQL stuff. The crash you see is happening in the code for the backend connection to Emacs. This is code that hasn't been changed (at least by me) in a very long time. I could debug this myself, now that I noticed this, but before doing so, do you have an idea? The crash happene

Re: [Bug-apl] Crash with stack trace

2017-01-17 Thread Juergen Sauermann
Hi Elias, do you by chance know if this happens with *⎕SQ**L *or with SQL as native function or both? Looks like the dump is coming from the SQL area. I remember that I replaced *map providers;** * in *apl-squlite.cc* with: *static Simple_string providers;** **static Simple_string connecti