Re: [Bug-apl] OpenBSD + GNU APL 1.8: Segfault immediately on apl startup

[Dr . Jürgen Sauermann]

Hi Brian, that explains it. I am getting this: ++ constructing DynamicObject::all_values ++ constructing DynamicObject::all_index_exprs ++ constructing Workspace::the_workspace ++ constructing StateIndicator::top_level_error ++ constructing Quad_CR::fun ++ constructing Quad_EC::fun ++ constructing Quad_ES::fun ++ constructing Parallel::all_CPUs ++ constructing Macro::all_macros What happens here is that some macro (actually Macro::Z__LO_RANK_X5_B) uses ⎕CR before it was initialized. I have hand-crafted the initialization order according to my version of the C++ standard in such a way that ⎕CR, ⎕EC, and ⎕ES (the quad functions that occur in Macros) were explicitly initialized according to the rules in Chapter  3.6.2 "Initialization of non-local variables" of (my version of) the C++ standard. Since I was suspecting an initialization order problem, I browsed the web about this topic and learned that different C++ versions differ in the way they handle the initialization of static class variables. This is what we see here. The three Quad_XXX functions are uninitialized when Macro::all_macros needs them. There are a number of ways to deal with this: 1. It could simply be a compiler fault (which one are you using?). In that case the compiler should be fixed. 2. The compiler is correct and the problem is caused by different C++ versions. In that case you should nail down the C++ version to be used. For example with (try different versions, the older the better): CXXFLAGS=-std=c++11 ./configure 3. I find a different way to control the initialization order in a different, C++ version independent, way. That may take a while though. The fact that  you get a segfault remains disturbing. I can't quite see how cerr << endl could fail. However, the reason might be the same (CERR not initialized before it is used). I will look into fixing this. Best Regards, Jürgen Sauermann On 7/21/19 4:09 PM, Dr. Brian Callahan wrote: Hi Jürgen -- Sure. This is the output: ++ constructing DynamicObject::all_values ++ constructing DynamicObject::all_index_exprs ++ constructing Workspace::the_workspace ++ constructing StateIndicator::top_level_error ++ constructing Parallel::all_CPUs ++ constructing Macro::all_macros Segmentation fault (core dumped) ~Brian On 7/21/19 6:45 AM, Dr. Jürgen Sauermann wrote: Hi Brian, thanks for reporting this. It looks like something goes wrong in the order of initialization of static class members. Could you please change line 35 of file src/static_Objects to read: bool static_Objects::show_constructors = true; and recompile and run GNU APL again? It will crash again but the output before that is relevant (no stackdump needed). The segfault is somewhat obscure because cerr << endl fails, but this happens inside an assertion that should not trigger in the first place. Best Regards, Jürgen On 7/21/19 3:07 AM, Dr. Brian Callahan wrote: Hi list -- I am in the process of updating the OpenBSD package of GNU APL to 1.8. It builds ok, but segfaults immediately upon running the apl binary. There is a (unfortunately very large) gdb backtrace attached to this email. It seems to be a problem with the custom COUT/CERR handling but I'm not well-versed in GNU APL internals. Happy to test out any patches. ~Brian