- ecl-devel - mailman3.common-lisp.net

"Got signal before environment was installed on our thread"
by Dima Pasechnik 26 Sep '17

26 Sep '17

Dear all, I'm struggling to understand strange segfaults coming from ECL(+Maxima) on FreeBSD embedded into Python; they typically look as follows: Got signal before environment was installed on our thread [2: No such file or directory] ;;; ECL C Backtrace ;;; 0 ecl_internal_error (0x87d790765) ;;; 1 init_unixint (0x87d7b6bd0) ;;; 2 init_unixint (0x87d7b6972) ;;; 3 pthread_sigmask (0x80103779d) ;;; 4 pthread_getspecific (0x801036d6f) ;;; 5 unknown (0x7ffffffff193) ;;; 6 GC_push_all_stacks (0x87db1ea2c) ;;; 7 GC_mark_some (0x87db12eec) ;;; 8 GC_stopped_mark (0x87db09baa) ;;; 9 GC_try_to_collect_inner (0x87db09a75) ;;; 10 GC_init (0x87db16f4f) ;;; 11 init_alloc (0x87d7caa59) ;;; 12 cl_boot (0x87d694a5b) ;;; 13 initecl (0x87d218340) ;;; 14 initecl (0x87d20a43f) ;;; 15 initecl (0x87d207e28) ;;; 16 _PyImport_LoadDynamicModule (0x800b3ed1c) ;;; 17 PyImport_AppendInittab (0x800b3d71f) ;;; 18 PyImport_AppendInittab (0x800b3d1a8) ;;; 19 PyImport_ImportModuleLevel (0x800b3c2ce) ;;; 20 _PyBuiltin_Init (0x800b162d7) ;;; 21 PyObject_Call (0x800a7d3e3) ;;; 22 PyEval_EvalFrameEx (0x800b2121c) ;;; 23 PyEval_EvalCodeEx (0x800b1b5d4) ;;; 24 PyEval_EvalCode (0x800b1ad96) ;;; 25 PyImport_ExecCodeModuleEx (0x800b3ad11) ;;; 26 PyImport_AppendInittab (0x800b3ddb8) ;;; 27 PyImport_AppendInittab (0x800b3d71f) ;;; 28 PyImport_AppendInittab (0x800b3d1a8) ;;; 29 PyImport_ImportModuleLevel (0x800b3c2ce) ;;; 30 _PyBuiltin_Init (0x800b162d7) ;;; 31 PyEval_EvalFrameEx (0x800b22dd1) Segmentation fault (core dumped) It looks as if ECL (version 16.1.2) is being called before an initialisation is complete, but it it possible to say more without a debugger? More details: is is on FreeBSD 11.0, clang 3.8.0, GC version 7.6.0 with libatomic_ops version 7.4.6. And only reproducible on FreeBSD. ECL is built with --disable-threads; GC is built with or without threads---result is still the same. (so it's unclear to me where pthread_* calls in the trace come from). Thanks, Dima PS. the segfault is at the bottom of https://trac.sagemath.org/ticket/22679#comment:87

3 12

Fwd: ECL + EQL Standalone Binary
by John Mercouris 26 Sep '17

26 Sep '17

Hey everyone, I’m John (the developer of nEXT (https://github.com/neXT-Browser/nEXT/ <https://github.com/neXT-Browser/nEXT/>), I’m trying to produce a standalone binary. I managed to create a “.app” bundle of my application, and then I linked the libraries ecl and eql following this approach (https://stackoverflow.com/questions/2809930/macdeployqt-and-third-party-lib… <https://stackoverflow.com/questions/2809930/macdeployqt-and-third-party-lib…>): > install_name_tool -change libeql5.1.dylib @executable_path/../Frameworks/libeql5.1.dylib next.app/Contents/MacOS/next > install_name_tool -change @libdir@/libecl.16.1.dylib @executable_path/../Frameworks/libecl.16.1.dylib next.app/Contents/MacOS/next otool then reveals that everything was successful: > otool -L next.app/Contents/MacOS/next next.app/Contents/MacOS/next: @executable_path/../Frameworks/libecl.16.1.dylib (compatibility version 16.1.3, current version 0.0.0) @executable_path/../Frameworks/libeql5.1.dylib (compatibility version 1.0.0, current version 1.0.0) Anyways, long story short, I got the following terminal output when I try to launch my new app binary: In order to minimize the possibility of mistakes in my program, misusage of QT etc, I’ve created a branch where I’ve included only 2 lisp files, a package file, and a “base” file: https://github.com/nEXT-Browser/nEXT/tree/compile/next <https://github.com/nEXT-Browser/nEXT/tree/compile/next> Any ideas on how to proceed would be very useful, thank you, -John

4 10

Re: ECL + EQL Standalone Binary
by Pascal Bourguignon 26 Sep '17

26 Sep '17

> On 26 Sep 2017, at 00:41, John Mercouris <jmercouris(a)gmail.com> wrote: > > Hi Pascal, I’ve done exactly as you said and have the following output: > > <output.pdf> (format nil "~x"(+ 1025 #xe70)) —> "1271" Since it looks like the functions around this address are unrelated to file accesses, then we may suppose that we have an error due to the modifications made by install_name_tool to the binary. Try without using this tool. If my hypothesis is correct, you will have to load the libraries explicitely at run-time as we’ve always done with cffi… > Honestly, I’m not sure what to make of it, it looks very similar to your output as well, > > -John >> On Sep 25, 2017, at 16:58, Pascal Bourguignon <pjb(a)informatimago.com <mailto:pjb@informatimago.com>> wrote: >> >> >> >> >>> On 25 Sep 2017, at 22:47, John Mercouris <jmercouris(a)gmail.com <mailto:jmercouris@gmail.com>> wrote: >>> >>> Hi Pascal, >>> >>> Thank you for your email, >>> >>> 1. You’re correct, I had to manually copy the libraries in to the app bundle, I just did something like: >>> >>> > cp /usr/local/lib/libeql5.1.dylib ./next.app/Contents/Frameworks/ >>> >>> 2. I saw the message is within ECL, I found the exact file with the error message, it is located in ecl/src/c/unixint.d >>> >>> I figured my problem was unrelated to the libraries, but I wasn’t 100% sure, just wanted to include all information, >>> >>> 3. I have no idea how to read assembly, I mean I can pick through it, but I won’t be able to really understand what’s going on, nor would I know how to even attach a debugger to the process, are there any other ways that I can examine what’s going on? A source file I can look at? Should I be looking for issues within ECL or EQL? >> >> You don’t need to understand the assembly code; you can just watch the name of the functions around the indicated location. >> >> In the case of my version of libecl, I would find: >> >> [pjb@despina :0.0 documentation]$ otool -t -v -V /opt/local/lib/libecl.dylib|grep -A300 -e '^_cl_boot:' >> _cl_boot: >> 0000000000001d34 movl 0x22ddce(%rip), %eax >> 0000000000001d3a testl %eax, %eax >> >> #x1d34 + 1025 = #x2135 >> >> 00000000000020e2 callq 0x151748 ## symbol stub for: _si_getcwd >> 00000000000020e7 movq %rax, 0x708(%r13) >> 00000000000020ee movl $0x1003, %esi >> 00000000000020f3 movl $0x1, %edx >> 00000000000020f8 movl $0x1, %ecx >> 00000000000020fd movl $0x1, %r8d >> 0000000000002103 movl $0x1, %r9d >> 0000000000002109 movq %r14, %rdi >> 000000000000210c callq 0x151814 ## symbol stub for: _si_make_vector >> 0000000000002111 movq %rax, 0x250(%r15) >> 0000000000002118 movl $0x4, %esi >> 000000000000211d movl $0x3, %edx >> 0000000000002122 movl $0x1, %ecx >> 0000000000002127 movq %rax, %rdi >> 000000000000212a callq 0x15163a ## symbol stub for: _si_fill_array_with_elt >> 000000000000212f movq 0x250(%r15), %rax >> 0000000000002136 movq 0x10(%rax), %rcx >> 000000000000213a movq %rcx, 0x240(%r15) >> 0000000000002141 movq 0x20(%rax), %rax >> 0000000000002145 movq %rax, 0x248(%r15) >> 000000000000214c movq 0x320(%r15), %rax >> 0000000000002153 movq %rax, 0x134b0(%r13) >> 000000000000215a movq 0x22dbef(%rip), %rdx >> 0000000000002161 movq 0x22dbf0(%rip), %rcx >> 0000000000002168 leaq 0x4980(%r13), %rdi >> 000000000000216f movl $0x203, %esi >> 0000000000002174 callq 0x150026 ## symbol stub for: _cl__make_hash_table >> 0000000000002179 movq %rax, %r15 >> 000000000000217c movq %r15, 0x22daad(%rip) >> 0000000000002183 leaq _char_names(%rip), %rbx >> >> we can see that calls to SI:GETCWD, SI:MAKE-VECTOR and SI-FILL-ARRAY-WITH-ELT are made just before that address, and a call to CL:MAKE-HASH-TABLE will be called just after. >> >> So if I had the error at the same cl_boot+1025 offset, I would infer there’s some problem with the allocation of a vector. >> (But this is not consistent with your file not found error, so check your own copy of the library, you may find other functions around the cl_boot+1025 address). >> >> >> -- >> __Pascal J. Bourguignon__ >

3 2

How to build ECL from sources to be able to debug itself?
by PR 07 Sep '17

07 Sep '17

Hi, I need to debug a possible socket bug on android; I've set up everything to be able to use a gdbserver on it, but it doesn't show anything useful (only a disassembly, which is cryptic to me). Is there a simple way to build all of prebuilt ECL (including sockets etc.) in debug mode? I already tried the configure options which mention debug, but this didn't change anything. Thanks, Paul

1 0

Building a real static binary
by Florian Margaine 29 Aug '17

29 Aug '17

Hi, I've been trying to build a real static binary for easy deployment. So far, everything I've tried still links to libecl as a shared library; is it possible to have a static library of it, so that my static binary can bundle it? I guess I kind of want to shy away from building ECL myself, it's kind of a pain to require that for other developers working on this project. Regards, -- Florian Margaine

2 2

Tail self-call optimization in generated C code?
by Eric Brunel 22 Aug '17

22 Aug '17

Hello all, I'm trying to get ECL to optimize tail self-calls in the C code generated from the Lisp files and it looks like I'm missing something, because I can't find a way to do that. Here is the behavior I'm getting for this simple Lisp function: (defun enumerate (l &optional (index 0) (result nil)) (cond ((null l) (reverse result)) (t (enumerate (cdr l) (+ index 1) (cons (list index (car l)) result))) ) ) As far as I can see, this function is properly tail-recursive, so I expected the generated C code to take the into account and generate a goto instead of a recursive call. But what I'm getting is this: static cl_object L1enumerate(cl_narg narg, cl_object v1l, ...) { cl_object T0, T1, T2, T3, T4; cl_object env0; const cl_env_ptr cl_env_copy = ecl_process_env(); cl_object value0; ecl_cs_check(cl_env_copy,value0); if (ecl_unlikely(narg<1)) FEwrong_num_arguments_anonym(); if (ecl_unlikely(narg>3)) FEwrong_num_arguments_anonym(); { cl_object v2index; cl_object v3result; va_list args; va_start(args,v1l); { int i = 1; if (i >= narg) { v2index = ecl_make_fixnum(0); } else { i++; v2index = va_arg(args,cl_object); } if (i >= narg) { v3result = ECL_NIL; } else { i++; v3result = va_arg(args,cl_object); } } va_end(args); if (!(v1l==ECL_NIL)) { goto L3; } value0 = cl_reverse(v3result); return value0; L3:; T0 = ecl_cdr(v1l); T1 = ecl_plus(v2index,ecl_make_fixnum(1)); T2 = ecl_car(v1l); T3 = cl_list(2, v2index, T2); T4 = CONS(T3,v3result); value0 = L1enumerate(3, T0, T1, T4); return value0; } } The recursive call is generated as a recursive call in C too... I'm almost sure I've seen C code generated from ECL that generated self tail calls as goto's, and I know it works when using the bytecode, where you just have to compile the function. But my search for a way to trigger this behavior for the generated C code has been unsuccessful so far. I'm using ECL 16.1.3. I used "ecl -c ... --compile ..." to get the C code, but my main build uses asdf:make-build with an ASD file.

3 5

EQL5-Android (port of EQL5 to the Android platform): a first example
by PR 04 Jul '17

04 Jul '17

For those interested in tablet / mobile development: I finally got a first example of EQL5 to work on Android, see 'tic-tac-toe' example, of course using both QML and Lisp! https://gitlab.com/eql/EQL5-Android Paul

2 2

Re: Android question: does cross-compiling require a 32 bit host ECL?
by Daniel Kochmański 03 Jul '17

03 Jul '17

Ah, there is one more problem with CC. If ECL versions differ (for instance 16.1.2 and 16.1.3), the resulting code will compile, but it won't work. The reason for that lies in fact, that symbols are indexed by positions in the table, and they may differ between versions. That said, if the index is different for the same version but with different features compiled in (i.e unicode and unicode) - all should work fine. If it doesn't, it is a bug. On 04.07.2017 07:31, Daniel Kochmański wrote: > > On 03.07.2017 21:17, Andy Hefner wrote: >> Interesting. Sometime in the past I recall reading that this was by >> design, and the compiler was intended to produce portable C. I'm >> curious to what extent this used to be true, or if the departure from >> this philosophy was deliberate. >> > Well, it depends on what you consider portable C. ECL compiler tries > to get the most from the used C compiler - before build it uses > autotools to detect features it can use. > > Lately we have made C99-compliant C compiler a requirement, so types > like uint64_t should be guaranteed to exist. That said ECL still work > with compilers older than that. The problem is, that if ECL detect > long double and its companianions (sinl, cosl), it produces code using > them, so we long-float type in CL is more accurate. If we > cross-compile with compiler not having sinl/cosl (not c99 conformant, > like in Android), we are busted. Workaround for that is to build host > ECL without long double. Correct solution is to have *target-features* > and long-float feature verified at runtime (not runtime) - something tbd. > > Requirement to set ABI=32 deliberely is for some obscure reason in > GMP. It is a bug to be fixed if possible. > > Interesting fact is that ECL has internal notion of the target > machine, but there is not mechanism currently to select one. When I > understand the compiler well enough I plan to make it configurable at > runtime - right now though cross compilation is rather a mundane task. > > NB: some other types may be used with ECL (namely - sse packs). > > To sum up: ECL produces portable C code, but: > 1) there may be some backward compatibility constraints (long double), > 2) there are some bugs wrt ABI compatibility if cross-compiled against > different libecl.so (caused by gmp), > 3) cross compilation needs more love (easily switching compiler and > flags etc), > 4) most of the architecture for 3) is implemented, it's a matter of > groking it and fixing some issues. > > I hope that answers your questions. > > Best regards, > Daniel

1 0

Android question: does cross-compiling require a 32 bit host ECL?
by PR 01 Jul '17

01 Jul '17

Hi again, In the process of porting EQL5 to Android, I stumbled upon this problem: The app crashes on Android during read_VV(), if the lisp library has been cross-compiled using a 64 bit ECL. To solve this problem, I need to use a 32 bit ECL for cross-compiling: but this would mean that for cross-compiling EQL5 apps we are required to stay with 32 bit ECL for EQL5. Probably not a big deal, but could the Android gurus confirm this? Thanks, Paul

2 2

FEprogram_error vs FEprogram_error_noreturn
by Kris Katterjohn 01 Jul '17

01 Jul '17

Hey, I notice that there is a FEprogram_error and a FEprogram_error_noreturn in src/c/error.d; however, it looks like these functions are identical aside from their names. I copied these to different files and diff'd them: --- test 2017-06-28 15:39:32.199877688 -0500 +++ test2 2017-06-28 15:39:32.199877688 -0500 @@ -1,5 +1,5 @@ void -FEprogram_error(const char *s, int narg, ...) +FEprogram_error_noreturn(const char *s, int narg, ...) { cl_object real_args, text; ecl_va_list args; FEprogram_error_noreturn was added in commit 7d9fb8bb. I think it was added because FEprogram_error didn't have the noreturn attribute, so FEprogram_error_noreturn was introduced with this attribute. However, it looks like FEprogram_error (and others) got this attribute in commit 790d466c. (This all happened in Feb 2010.) Currently in src/h/external.h: extern ECL_API void FEprogram_error(const char *s, int narg, ...) ecl_attr_noreturn; extern ECL_API void FEprogram_error_noreturn(const char *s, int narg, ...) ecl_attr_noreturn; They are both used throughout src/c. It seems like one of these should be removed. If so, I can remove one of them and change all of the calls to it. I would say keep FEprogram_error and remove FEprogram_error_noreturn. If these changes are desired, then I can open up a new Merge Request with these changes after my currently open Merge Request is done (to avoid conflicts). Cheers, Kris Katterjohn

3 3