Re: Branch Version_2_7_0pre
"Kirill A. Korinsky" <[email protected]>
| Newsgroups | gmane.lisp.gcl.devel |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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" <[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
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3/KLNtcfWfLw7JxqmNjZhndZIm4FAmWGKMgACgkQmNjZhndZ Im6HwRAAsRc5LTO2honE/EXKdMPyr97OBVG5hFck9E2ysr0aswyavAd+mDk/gllp eML1HKRbtTwznGDo6LAgAuyMDbDu4s0UQG//yITu3lnnrCYVUYaLvDKMUFRmt0bj nvG6cCUSprLOnGZwpLyszihaYTYUkfLDU5gBz5sZ88jzidx4/2/869SMSgUF8Ajt Jwe1Kk76bvEd1hfYzM7oEFqG/nMdwsLRMe889gn2JxWlpC64Xeqvoh792R9Drv7M gvpgGrIxNsLyjazRulhUbv+JQeaG4Zfq7gv1c5kt7WqeV9O+ZBACuqwJav8Ezrob Rlf8ddnHoOxfCdMAVG1UEnBEzbRDQWUlLXXyK5yE24SH7inzdpBGTRSQW9MICinQ LFrz8cfLT5k0YN86nv/hTigDIGDfH31eb763sBT3RMcP1KttuQw02ux8k5b38pFT yWCqhmhy1R8zz47K8iJ7Kk06RRz8iv7TgbCSYofMNWFKXPpLw8/QhMz8tq11wL+K HknWIOlgvIsunAiV1cMZIqw09CEpwOrczSU9TeU5oX62akOEwPHJAv/dLCTLr5cq 4sS+h+CD6Dgz3EhRNYtcx6LE27QdgYRTdXwg1eor4j/3irRQbLYi2PXUUKSGH7G9 PTUdyfXa42+31HM1Iu2taaY9g0D8ZpaR1RQIFrCccSAFpdRD2fI= =vwer -----END PGP SIGNATURE-----