masinter
commented
3 years ago Closed masinter closed 3 years ago
masinter
commented
3 years ago 
nbriggs
commented
3 years ago OK, what that tells me is that the SYSTEM package probably doesn't exist in the image at the time that the code in build_lisp_map in initsout.c:306 is trying to look up SI::*CLOSURE-CACHE-ENABLED*
masinter
commented
3 years ago undoubtedly there's a lisp problem. but URAID can't be used to help debug the problem if it faults
nbriggs
commented
3 years ago I can probably fix URAID so that it doesn't segfault -- but if *PACKAGE-FROM-INDEX* is not an array in the Lisp memory that it can access to get the package names it's not clear what it can do to print the names of packaged atoms.
On the system that fails, can you recompile just initsout.c (touch it, makeright init, then copy the compile line so you can do it with extra options) and add -DDEBUG (then redo the makeright init to relink the new object). I'd like to know what it prints for
DBPRINT(("Package_from_Index_word = 0x%x.\n", Package_from_Index_word));
DBPRINT(("Package_from_Name_word = 0x%x.\n", Package_from_Name_word));when you start up the code that fails.
nbriggs
commented
3 years ago In initsout.c, if it's running ldeinit then it fakes out the closure-cache-enabled setting (set to NIL) and the Lisp code doesn't need to set it explicitly. It also sets to NIL *CLOSURE-CACHE*, and *DELETED-IMPLICIT-HASH-SLOT*.
The fact that it ended up at line 306 in build_lisp_map says that you're NOT running an ldeinit (it may be called that, but it wasn't compiled with the -DINIT flag and the variable for_makeinit must be 0 instead of the 1 we'd expect.
You must have created your own makefile-init.aarch64, right? What does it look like?
masinter
commented
3 years ago larry@Mac-mini medley % lldb ../maiko/darwin.aarch64/ldeinit
(lldb) target create "../maiko/darwin.aarch64/ldeinit"
Current executable set to '/Users/larry/maiko/darwin.aarch64/ldeinit' (arm64).
(lldb) run loadups/init.dlinit
Process 3947 launched: '/Users/larry/maiko/darwin.aarch64/ldeinit' (arm64)
Failed to find UNIXCOMM file handles; no processes
Stackspace = 0x1020000.
AtomHT = 0x12a0000.
Package_from_Index_word = 0x159529c.
Package_from_Name_word = 0x1599400.
16908288 17170432 19406848 19922944 19529728Invalid index in GC's AREF1: 0x1
Array size limit: 0x0
Array ptr: 0x1
Array 68K ptr: 0x101000002
base: 0x0
offset: 0x0
type #: 0x0
fill ptr: 0x0
*Error* index out of range in GC's AREF1.
Enter the URaid
#:CL::NIL
< l
Process 3947 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xfffffffffffffff0)
frame #0: 0x000000010004343c ldeinit`bt1(startFX=0xffffffffffffffec) at dbgtool.c:588:28
585 URaid_FXarray[fnum] = fx;
586 printf("%3d : ", fnum++);
587 #ifdef BIGVM
-> 588 fnobj = (struct fnhead *)Addr68k_from_LADDR(fx->fnheader);
589 #else
590 fnobj = (struct fnhead *)Addr68k_from_LADDR(((int)fx->hi2fnheader << 16) | fx->lofnheader);
591 #endif /* BIGVM */
Target 0: (ldeinit) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xfffffffffffffff0)
* frame #0: 0x000000010004343c ldeinit`bt1(startFX=0xffffffffffffffec) at dbgtool.c:588:28
frame #1: 0x0000000100043874 ldeinit`bt at dbgtool.c:639:17
frame #2: 0x000000010003b05c ldeinit`uraid_commands at uraid.c:428:9
frame #3: 0x0000000100019ee4 ldeinit`error(cp="index out of range in GC's AREF1.") at common.c:115:9
frame #4: 0x000000010006bbf4 ldeinit`aref1(array=1, index=1) at gcarray.c:121:5
frame #5: 0x000000010004439c ldeinit`find_package_from_name(packname="SYSTEM", len=6) at testtool.c:119:26
frame #6: 0x000000010006c18c ldeinit`get_package_atom(char_base="*CLOSURE-CACHE-ENABLED*", charlen=23, packname="SI", packlen=2, externalp=0) at gcarray.c:268:17
frame #7: 0x0000000100048f1c ldeinit`build_lisp_map at initsout.c:306:13
frame #8: 0x0000000100047f24 ldeinit`main(argc=2, argv=0x000000016fdff928) at main.c:500:3
frame #9: 0x00000001a2e39f34 libdyld.dylib`start + 4
(lldb) OK, so at least the Package_from_Index_word isn't NULL.
But, it still looks as though your ldeinit was not compiled with the -DINIT flag. Can you post your makefile-init.aarch64
masinter
commented
3 years ago I tried adding -DINIT to compile flags and got
../src/bitblt.c:89:5: error: implicit declaration of function 'init_keyboard' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
init_keyboard(0);
^
1 error generated.# Options for MacOS, aarch64 processor, X windows, for INIT processing
CC = clang $(CLANG_CFLAGS)
XFILES = $(OBJECTDIR)xmkicon.o \
$(OBJECTDIR)xbbt.o \
$(OBJECTDIR)dspif.o \
$(OBJECTDIR)xinit.o \
$(OBJECTDIR)xscroll.o \
$(OBJECTDIR)xcursor.o \
$(OBJECTDIR)xlspwin.o \
$(OBJECTDIR)xrdopt.o \
$(OBJECTDIR)xwinman.o
XFLAGS = -I/opt/X11/include -DXWINDOW
# OPTFLAGS is normally -O2.
OPTFLAGS = -O0 -g3
DEBUGFLAGS = # -DDEBUG -DOPTRACE
DFLAGS = $(DEBUGFLAGS) $(XFLAGS) -DRELEASE=351 -DINIT
LDFLAGS = -L/opt/X11/lib -lX11 -lm
LDELDFLAGS = -L/opt/X11/lib -lX11 -lm
OBJECTDIR = ../$(RELEASENAME)/
default : ../$(OSARCHNAME)/ldeI'll fix the missing prototypes for -DINIT. When I compile on my older macos it doesn't use -Werror, you might be able to just add -Wno-error (or -Wno-error=implicit-function-declaration) until I get the fix/PR through.
masinter
commented
3 years ago not sure what was going on here, but in any case, the problem isn't showing up any more