Re: Branch Version_2_7_0pre

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" <[email protected]> writes:

>  On 22. Dec 2023, at 17:19, Camm Maguire <[email protected]> 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			     		    [email protected]
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah