Also, for completeness, before trying SVN 1180, I tried 3 different
compilers:
1. OpenBSD's default compiler, clang-8.0.0 (this compiler was the one I
was using when I filed the bug report)
2. g++-8.3.0 available in OpenBSD's packages
3. g++-10.0.0 SVN that I auto-build every day
Compilers 1 and 2 both produced an apl that segfaulted. Compiler 3
produced a working apl.
Not sure what if any conclusions we can draw from that, but that's the data.
~Brian
On 7/21/19 12:51 PM, Brian Callahan wrote:
Hi Jürgen --
Yes, SVN 1180 fixes things for me. Thank you very much for your time
and help.
~Brian
On 7/21/19 12:36 PM, Dr. Jürgen Sauermann wrote:
Hi again,
hopefully fixed in *SVN 1180*. Please let me know if it works for you.
Best Reards,
Jürgen Sauermann
On 7/21/19 5:40 PM, Dr. Jürgen Sauermann wrote:
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
