I'd like to confirm that I successfully build gcl from commit 01ed2e0b2f540031171d2258ddccb951735827e7 on macOS 12 x86_64 with using only one series of patches: https://github.com/macports/macports-ports/blob/master/lang/gcl/files/fix-memory-corruption-on-macOS.patch <https://github.com/macports/macports-ports/blob/master/lang/gcl/files/fix-memory-corruption-on-macOS.patch>
Now I'm trying i386 and arm64, stay tuned!
--
wbr, Kirill
> On 22. Dec 2023, at 22:17, Camm Maguire <c...@maguirefamily.org> wrote:
>
> 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
signature.asc
Description: Message signed with OpenPGP
