Re: [Bug-apl] erlang APL NIF

[Dr . Jürgen Sauermann]

Hi again, one more info: running your _expression_ in test_libapl reproduces the fault and gdb indicates that the address of the function is 0: (gdb) p Macro::Z__LO_REDUCE_X4_B $4 = (Macro *) 0x0 (gdb) That suggests that the linking of libapl and test_libapl has failed for some reason, and that the fault is more likely in the linker commands than in the .cc source files. BR, Jürgen On 6/4/19 10:32 PM, Dr. Jürgen Sauermann wrote: Hi Rowan, see below. BR, Jürgen On 6/4/19 5:00 PM, Rowan Cannaday wrote: Hello again, Trying out the erlang/APL interface (its building now!), running into a few issues. BTW I'm pretty new to FOSS mailing lists so if in the future you'd prefer I'd start these as different threads, or use a different syntax for distinguishing shell output just let me know. Don't worry, everything is just fine. First issue: ``` ldd /usr/local/lib/apl/erlang_APL_nif.so libapl.so => not found ``` I fixed by adding "/usr/local/lib/apl" to my LD_LIBRARY_PATH. 2nd issue: ``` 1> apl:init(). load called. Executable /usr/lib/erlang/erts-10.2.4/bin/APs/APserver not found. This could means that 'apl' was not installed ('make install') or that it was started in a non-standard way. The expected location of APserver is either the same directory as the binary 'apl' or the subdirectory 'APs' of that directory (the directory should also be in $PATH). libapl initialized. ok 2> ``` I have added a note at the end of erlang/README regarding this. This seems related to the following previous bug report: SVN 595 https://lists.gnu.org/archive/html/bug-apl/2015-04/msg00032.html The function still returns 'OK'. Third Issue (including entire session for context): ``` PATH=$PATH:/usr/local/bin:/usr/local/lib/apl LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/apl erl Erlang/OTP 21 [erts-10.2.4] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] Eshell V10.2.4 (abort with ^G) 1> c("/usr/local/lib/apl/apl"). {ok,apl} 2> apl:init(). load called. Executable /usr/lib/erlang/erts-10.2.4/bin/APs/APserver not found. This could means that 'apl' was not installed ('make install') or that it was started in a non-standard way. The expected location of APserver is either the same directory as the binary 'apl' or the subdirectory 'APs' of that directory (the directory should also be in $PATH). libapl initialized. ok 3> apl:statement("1 2 3 + 4 5 6"). 5 7 9 [{value,[3],[5,7,9]}] 4> apl:statement("(1 2 3)∘.+(1 2 3)"). 2 3 4 3 4 5 4 5 6 [{value,[3,3],[2,3,4,3,4,5,4,5,6]}] 5> apl:statement("∘.,/(1 2)(1 2)"). Segmentation fault ``` Yes. I can confirm the segfault. It also happens on my machine. It looks like The erlang interface as such is working, but fails in this particular case. The same statement entered directly in APL works as expected. The real problem is this: When I published the Erlang interface back in 2017, the feedback that I received from different communities was ranging from total lack of interest (Erlang community) to derogative (Elixir community). For that reason I am inclined to remove the Erlang interface from GNU APL in the next GNU APL release 1.8. On the other hand I suspect that the problem with the statement above is not related to the Erlang interface in the first place, but to libapl. In that case removing the Erlang Interface would not help. The way Erlang works makes it quite complicated to troubleshoot the case. If the problem is in libapl, however, one can replace Erlang by a simple C/C++ main() program that initializes libapl and then calls the same functions in libapl that Erlang calls in erlang_APL_nif.c. I was able to track down the segfault to occur in Prefix.cc line 935: Token result = at0().get_function()->eval_B(at1().get_apl_val()); This line calls a user-defined Function (probably Macro Z__LO_REDUCE_X4_B in Macro.def line 147). If you would like to help, then please try your luck troubleshooting this. I can help you with the details that you may need. I have attached a file test_libapl.c that I use to test libapl. You can use your failing apl _expression_ instead of ⎕←2 3⍴⍳6 in that file. And the output of `strings apl.beam`: ``` FOR1 pBEAMAtU8 init erlang load_nif command_utf8 command_utf8__not_loaded exit command_ucs command_ucs__not_loaded statement_utf8 statement_utf8__not_loaded statement_ucs statement_ucs__not_loaded fix_function_ucs fix_function_ucs__not_loaded set_variable set_variable___not_loaded eval_mux eval_mux__not_loaded eval_ eval_B eval_AB eval_XB eval_AXB eval_LB eval_ALB eval_LXB eval_ALXB eval_LRB eval_ALRB eval_LRXB eval_ALRXB true false length value lists foldl reverse error Invalid eterm command statement module_info get_module_info -e2a/1-fun-0- Code @#3@!C@ @#3@ @1C@ @QC@ @#3@aC@ @#3@ @qC@ &@#3@ (@#3@ F0#G 5@G F0#G StrT ImpT ExpT FunT ]LitT c```f``Pm `Na`-K LocT BAttr vsnl C3jjCInf versionk 7.3.1h optionsjh sourcek /usr/local/lib/apl/apl.erljDbgi debug_info_v1d erl_abstract_codeh nonej Line ' + , - . / 0 1 56 7 8 9 : ; < = > ?@ A E I O T W X S /usr/local/lib/apl/apl.erl ``` It doesn't seem to be producing a core dump, haven't figured out why yet. Thanks y'all. Let me know how I can help! - Rowan