Greetings, and thanks again!
vfork: from your trace, macosx seems to be calling malloc before exec
in the child, and this is a no no for vfork. signal handling is
irrelevant. I will investigate posix_spawn and let you know.
I take it readline and gprof issues are clear.
I've committed a fix which will hopefully get you beyond the libc
issue. Please keep me informed.
Take care,
"Kirill A. Korinsky" <kir...@korins.ky> writes:
> On 22. Dec 2023, at 17:19, Camm Maguire <c...@maguirefamily.org> wrote:
>
> On 3), after reading up on vfork, and examining your logs, it is indeed
> deprecated. This has been in use in 2.6 for many years -- have you been
> applying a patch there as well?
>
> This patch was introduced by me at MacPorts when I upgraded GCL from 2.6.12
> to 2.6.14. Both 2.6.13 and 2.6.14 doesn't work without this patch.
>
> If I recall right I've used git bisect to find when it was broken to start my
> investigation to figure out this changes.
>
> And the GCL code in question here is (o/unixsys.c):
>
> if (!(pid=pvfork())) {
> errno=0;
> execvp(*p1,(void *)p1);
> _exit(128|(errno&0x7f));
> }
>
> I'm guessing macosx is mallocing the environment. Or perhaps it is the
> profile timer blocking. You might want to try replacing pvfork above
> with vfork. If this works it is a simple fix confining the signal
> handling to the parent.
>
> I've applied the patch:
>
> - if (!(pid=pvfork())) {
> + if (!(pid=vfork())) {
> errno=0;
> execvp(*p1,(void *)p1);
> _exit(128|(errno&0x7f));
>
> and it crashed as before with stack trace (I've disabled GCL's signals to get
> it):
>
> Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
> Terminating Process: exc handler [93250]
>
> VM Region Info: 0x28 is not in any region. Bytes before following region:
> 140737488199640
> REGION TYPE START - END [ VSIZE] PRT/MAX
> SHRMOD REGION DETAIL
> UNUSED SPACE AT START
> --->
> VM_ALLOCATE 7ffffffda000-7ffffffdb000 [ 4K] r-x/r-x
> SM=ALI
>
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0 libsystem_malloc.dylib 0x7ff817d3772c _malloc_fork_prepare + 80
> 1 libSystem.B.dylib 0x7ff822d06759 libSystem_atfork_prepare
> + 55
> 2 libsystem_c.dylib 0x7ff817e1b8a8 vfork + 27
>
> On 5) if you could please do the following at the stopped part of the
> build:
>
> cd unixport
> ./saved_pre_gcl
> (in-package :si)
> (trace dlopen dlsym)
> (mdlsym "memcmp")
>
> Sure,
>
>>(in-package :si)
>
> #<"SYSTEM" package>
>
> SYSTEM>(trace dlopen dlsym)
>
> (DLOPEN DLSYM)
>
> SYSTEM>(mdlsym "memcmp")
>
> 1> (DLSYM 0 "memcmp")
> <1 (DLSYM 140703530381538)
> |libsystem_platform|:|memcmp|
>
> SYSTEM>
>
> On 4), as I had indicated, the current bootstrap process is needlessly
> slow and is there just to check all modes of operation. saved_pre_gcl
> operates from evaluated lisp source, saved_gcl0 from compiled at safety
> 3. saved_gcl is fully optimized. Until we address this at final
> release, may I suggest keeping a build around, and when testing a
> change, do
>
> cd unixport
> ./saved_gcl
>
> (time (load "boot.lisp"))
>
> make saved_gcl
>
> For me this takes 240 seconds.
>
> Let's back to it when we fix building.
--
Camm Maguire c...@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
