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
|