I dont think its related to shared vs static - rather two gc running concurrently. Try commenting out GC_init call in ecl and see what happens.
Do you need sigchld for anything? Run-program was rewritten and sigchld handling wasnt viable option anymore for it. Im on phone, will be avail after the weekend. Regards, D. Dnia 1 września 2017 14:47:57 CEST, Dima Pasechnik <dimpase+...@gmail.com> napisał(a): >Hi Daniel, >Thanks for the message. The scenario you talk about only happens if GC >is a shared library, right? > >I've rebuilt GC disabling shared libs, and ECL doing static linking to >GC. >And I still get very similar segfaults: > >;;; ECL C Backtrace >;;; 0 ecl_internal_error (0x87d79b375) >;;; 1 init_unixint (0x87d7c17e0) >;;; 2 init_unixint (0x87d7c1582) >;;; 3 pthread_sigmask (0x80103779d) >;;; 4 pthread_getspecific (0x801036d6f) >;;; 5 unknown (0x7ffffffff193) >;;; 6 GC_push_current_stack (0x87d7ef7c3) >;;; 7 GC_with_callee_saves_pushed (0x87d7f7360) >;;; 8 GC_push_roots (0x87d7ef9c2) >;;; 9 GC_mark_some (0x87d7ec97c) >;;; 10 GC_stopped_mark (0x87d7e6b7a) >;;; 11 GC_try_to_collect_inner (0x87d7e6a75) >;;; 12 GC_init (0x87d7f08ea) >;;; 13 init_alloc (0x87d7d5669) >;;; 14 cl_boot (0x87d69f66b) >... > >And a very similar picture on the develop branch of ECL - although >I had to change our code, as in particular >ECL_OPT_TRAP_SIGCHLD is gone... > >So, what can it be? Some signals issue? > >Thanks, >Dima > >On Fri, Sep 1, 2017 at 7:38 AM, Daniel Kochmański ><dan...@turtleware.eu> wrote: >> Hey Dima, >> >> this looks like the issue with having GC initialized before ECL kicks >in. >> See https://gitlab.com/embeddable-common-lisp/ecl/issues/371 for a >> discussion about this problem. Basically some other component already >called >> GC_init and ECL calls it once more. It's arguably not a bug. >> >> Best regards, >> >> Daniel >> >> >> On 31.08.2017 15:29, Dima Pasechnik wrote: >>> >>> 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 >>> >> -- Wysłane za pomocą K-9 Mail.
