Re: Branch Version_2_7_0pre

"Kirill A. Korinsky" <[email protected]> Fri, 22 Dec 2023 20:10:34 +0100
Newsgroups	gmane.lisp.gcl.devel
Message-ID	<[email protected]>
> 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.


--
wbr, Kirill
signature.asc (application/pgp-signature, 833 B)