KERN_INVALID_ADDRESS error when running ppc-boot on 10.6.8

[snunez1]

After building a ppc-boot, running it produces:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000fe021a70
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   LaunchCFMApp                   0xb80c0057 0xb8000000 + 786519
1   LaunchCFMApp                   0xb80dd8e8 0xb8000000 + 907496
2   LaunchCFMApp                   0xb8145397 spin_lock_wrapper + 1791
3   LaunchCFMApp                   0xb801ceb7 0xb8000000 + 118455

...

Thread 3: Crashed (0xb7fffa10, 0xb80c0057)
0x02024820: /Users/nunez/Desktop/MCL-BingHe/pmcl-OSX-kernel : toplevel_loop + 56 
0x020248d4: /Users/nunez/Desktop/MCL-BingHe/pmcl-OSX-kernel : _start_lisp + 156 
0x02002e04: /Users/nunez/Desktop/MCL-BingHe/pmcl-OSX-kernel : _main + 2080 
0x0200c9d0: /Users/nunez/Desktop/MCL-BingHe/pmcl-OSX-kernel : _set_nil_and_start + 84 
0x7f54987c: No symbol
0x976bb7e0: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore : _CCFM_LaunchApplication + 872 
0x0000274c: /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp : _main + 1256 
0x00002230: /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp : start + 68 
0x78f8ffbf: No symbol

Probably thread 3 crashing somehow rolled up to Thread 0. After reading rmcl-notes.pdf, a theory is that the ppc-boot file which jumps into pmcl-OSX-kernel is somehow out of sync or different between 10.5 and 10.6. That is nothing more than a guess. Here is the hardware spec:

Model: Macmini2,1, BootROM MM21.009A.B00, 2 processors, Intel Core 2 Duo, 2.33 GHz, 4 GB, SMC 1.3f4
Graphics: Intel GMA 950, GMA 950, Built-In, spdisplays_integrated_vram
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x86), Atheros 5424: 2.1.14.6
Bluetooth: Version 2.4.5f3, 2 service, 19 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Serial ATA Device: KINGSTON SA400S37240G, 223.57 GB
Parallel ATA Device: MATSHITACD-RW  CW-8124
USB Device: USB2.0 Hub, 0x2109  (VIA Labs, Inc.), 0x2812, 0xfd100000 / 2
USB Device: Das Keyboard, 0x24f0, 0x0140, 0xfd140000 / 3
USB Device: Bluetooth USB Host Controller, 0x05ac  (Apple Inc.), 0x8205, 0x7d100000 / 2
USB Device: IR Receiver, 0x05ac  (Apple Inc.), 0x8240, 0x7d200000 / 3
USB Device: Razer DeathAdder, 0x1532, 0x0016, 0x5d200000 / 2

[binghe]

Hi, I suggest you try to rebuild pmcl-OSX-kernel on your Mac OS X 10.6. I can't do this, because my only Mac OS X 10.6 machine is with Xcode 4.2, which cannot generate PPC binary. The current pmcl-OSX-kernel, according to Git commit log, was rebuilt by Terje Anderson on 10.6.x, however we don't know the compiler and exact OS version. Now I tend to think the existing pmcl-OSX-kernel binary has some problems and should never work.

The procedure is not mentioned in the Wiki, but it's mentioned in the rmcl-notes.pdf (by Gary Bayer). All you need to do is go to pmcl/OSX directory and execute make there, than copy the newly built pmcl-OSX-kernel file back to MCL's top directory. This procedure is confirmed working on Mac OS X 10.5 with Xcode 3.2.

[snunez1]

I tried that. I rebuilt pmcl-OSX-kernel, but it had no effect. I also turned on -Wall to see if it caught anything. -Wall is always a bit noisy, but sometimes useful; sadly, not in this case. I think to get to the bottom of this will take running it in a debugger, which I unfortunately can't do right now.

On Thu, Nov 22, 2018 at 4:52 PM Chun Tian notifications@github.com wrote:

Hi, I suggest you try to rebuild pmcl-OSX-kernel on your Mac OS X 10.6. I can't do this, because my only Mac OS X 10.6 machine is with Xcode 4.2, which cannot generate PPC binary. The current pmcl-OSX-kernel, according to Git commit log, was rebuilt by Terje Anderson on 10.6.x, however we don't know the compiler and exact OS version. Now I tend to think the existing pmcl-OSX-kernel binary has some problems and should never work.

The procedure is not mentioned in the Wiki, but it's mentioned in the rmcl-notes.pdf (by Gary Bayer). All you need to do is go to pmcl/OSX directory and execute make there, than copy the newly built pmcl-OSX-kernel file back to MCL's top directory. This procedure is confirmed working on Mac OS X 10.5 with Xcode 3.2.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/binghe/MCL/issues/2#issuecomment-440956823, or mute the thread https://github.com/notifications/unsubscribe-auth/AHak8BDAGGwWyb7VmBcI3caMfW5EHis_ks5uxmXpgaJpZM4YuvNP .

[binghe]

I'll also downgrade my Xcode to get to the same page with you. I believe this issue could be finally resolved by understanding and modifying those C and assembly code in pmcl/OSX directory. Good luck, both us.

[snunez1]

I thought about this some more, and I do not think it is pmcl-OSX-kernel after all. Doesn't PPCCL use this kernel? PPCCL works fine except for an occasional crash or so. If PPCCL is working with pmcl-OSX-kernel, then the problem likely lies with ppc-boot. Gary Byers writes in rmcl-notes (edited for clarity):

On OSX, CFM applications are loaded into memory by a native helper application "LaunchCFMApp" ... that tries to find external CFM libraries that the CFM application is linked against and resolve references to symbols defined in those libraries; if it's successful, it transfers control to initialization and startup routines in the CFM executable.

MCL refers to a CFM library named "pmcl-kernel", and its initialization and startup routines call functions that are defined in that library. On traditional MacOS, this file was "the kernel" and provided image loading and saving, exception handling, and other services for the MCL application. On OSX, a separate copy of the C kernel sources were compiled into a "native" kernel (compiled and linked as a native Mach-O object file and named "pmcl-OSX-kernel"

So, if PPCCL works, but the ppc-boot that is generate by the rebuild process does not, it seems reasonable that the jump point to "transfer control to initialization and startup routines" might be incorrectly set somewhere in the lisp code. The question is: how to find out where in lisp this is done before the call to generate-application.