BUG: lisp.run constantly crashes

[james.sumners@…]

This occurs a LOT when building clisp and at least once when running maxima, usually at the beginning of the session. It will also crash when TeXmacs is started if clisp is installed. Here is a copy of the crash report:

Date/Time: 2006-03-02 14:27:28.225 -0500 OS Version: 10.4.5 (Build 8H14) Report Version: 4

Command: lisp.run Path: ./lisp.run Parent: make [19804]

Version: ??? (???)

PID: 21195 Thread: 0

Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x1a9571b4

Thread 0 Crashed: 0 lisp.run 0x00056fb0 closed_buffered + 48 (crt.c:355) 1 lisp.run 0x0005f978 closed_all_files + 108 (crt.c:355) 2 lisp.run 0x0000f61c loadmem_from_handle + 3168 (crt.c:355) 3 lisp.run 0x0000f8dc loadmem + 132 (crt.c:355) 4 lisp.run 0x0000fcd4 init_memory + 880 (crt.c:355) 5 lisp.run 0x0001230c main + 3924 (crt.c:355) 6 lisp.run 0x00002158 _start + 340 (crt.c:272) 7 lisp.run 0x00002000 start + 60

Thread 0 crashed with PPC Thread State 64:

srr0: 0x0000000000056fb0 srr1: 0x000000000000d030 vrsave: 0x0000000000000000

cr: 0x42000248 xer: 0x0000000020000004 lr: 0x000000000005f978 ctr: 0x0000000000000001 r0: 0x000000000005f978 r1: 0x00000000bffff730 r2: 0x0000000000000000 r3: 0x0000000000000000 r4: 0x0000000001100eb0 r5: 0x00000000bffff698 r6: 0x0000000000000000 r7: 0x0000000000056f88 r8: 0x00000000001857c9 r9: 0x000000001a9571c0 r10: 0x000000001a957160 r11: 0x0000000000000000

r12: 0x00000000900066c0 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 r16: 0x0000000000193dfc r17: 0x0000000000193dd0 r18: 0x0000000000000001 r19: 0x0000000000193dd0 r20: 0x00000000bffff770 r21: 0x00000000bffff790 r22: 0x0000000000000001 r23: 0x0000000001100ebc r24: 0x00000000001857c9 r25: 0x000000000018f914 r26: 0x000000000018f914 r27: 0x00000000fffffff6 r28: 0x0000000066752cc0 r29: 0x000000001a957161 r30: 0x000000001a957160 r31: 0x000000000005f914

Binary Images Description:

0x1000 - 0x17dfff lisp.run /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_clisp/work/clisp-2.38/src/lisp.run

0x1c9000 - 0x1d0fff libintl.3.dylib /opt/local/lib/libintl.3.dylib 0x305000 - 0x326fff libreadline.5.0.dylib /opt/local/lib/libreadline.5.0.dylib 0x505000 - 0x5dbfff libiconv.2.dylib /opt/local/lib/libiconv.2.dylib

0x8fe00000 - 0x8fe54fff dyld 44.2 /usr/lib/dyld 0x90000000 - 0x901b3fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x9020b000 - 0x9020ffff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x9073a000 - 0x90813fff com.apple.CoreFoundation 6.4.4 (368.25) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x9085e000 - 0x90960fff libicucore.A.dylib /usr/lib/libicucore.A.dylib 0x909ba000 - 0x90a3efff libobjc.A.dylib /usr/lib/libobjc.A.dylib 0x90aed000 - 0x90afffff libauto.dylib /usr/lib/libauto.dylib 0x913af000 - 0x913b7fff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib 0x964f8000 - 0x96526fff libncurses.5.4.dylib /usr/lib/libncurses.5.4.dylib

Model: PowerBook5,6, BootROM 4.9.1f1, 1 processors, PowerPC G4 (1.2), 1.67 GHz, 1 GB Graphics: ATI Mobility Radeon 9700, ATY,RV360M11, AGP, 128 MB Memory Module: SODIMM0/J25LOWER, 512 MB, DDR SDRAM, PC2700U-25330 Memory Module: SODIMM1/J25UPPER, 512 MB, DDR SDRAM, PC2700U-25330 AirPort: AirPort Extreme, 404.2 (3.90.34.0.p16) Modem: Jump, , V.92, Version 1.0, Bluetooth: Version 1.7.0f18, 2 service, 0 devices, 1 incoming serial ports Network Service: AirPort, AirPort, en1 PCI Card: TXN,PCIXXXX-00, cardbus, PC Card Parallel ATA Device: MATSHITADVD-R UJ-835E, Parallel ATA Device: FUJITSU MHT2080AH, 74.53 GB USB Device: Bluetooth HCI, , Up to 12 Mb/sec, 500 mA USB Device: Apple Internal Keyboard/Trackpad, Apple Computer, Up to 12 Mb/sec, 500 mA

[gwright@…]

James,

Have you recently run

sudo port selfupdate

to update the ports and infrastructure? The current version of clisp should be 2.38. I've never seen this bug on my powerbook G4/1.5 GHz/1 GB ram machine, nor has anyone else reported a similar problem. If you DP ports and infrastructure are current, you might be seeing a hardware problem.

-Greg

[james.sumners@…]

Yes. My ports are all updated. In fact, I made this bug report when updating clisp from 2.38.0 to 2.38.1. I was having this problem with an upgraded (from prior to 1.2) ports installation so I completely uninstalled Darwin Ports and re-installed. The problem persisted. I am still running that new installation of Darwin Ports, only with the bare minimum packages that I use. Here is a list of what I have installed according to port installed:

clisp @2.38_0+darwin_8 clisp @2.38_1+darwin_8 (active) dejagnu @1.4.4_0 (active) fftw-3 @3.0.1-fma_4 (active) freetype @2.1.10_1 (active) gawk @3.1.5_1 (active) gcc34 @3.4.5_0+darwin_8 (active) gd2 @2.0.33_2 (active) gettext @0.14.5_0 (active) ghostview @1.5_0 (active) glib1 @1.2.10_5 (active) gnuplot @4.0.0_1+darwin_8 (active) gplghostscript @8.15_1 (active) gsed @4.1.4_1 (active) gtk1 @1.2.10_6 (active) guile @1.6.7_0+darwin_8 guile @1.6.7_1+darwin_8 (active) hdf5 @1.6.4_0 (active) ImageMagick @6.2.4-6_0 (active) jpeg @6b_1 (active) libiconv @1.10_1+darwin_8 (active) libpng @1.2.8_2+darwin_8 (active) libsigsegv @2.1_0 (active) maxima @5.9.2_0+test (active) octave @2.1.71_2+test (active) pdflib @6.0.2_1+darwin_8 (active) readline @5.0.005_0+darwin_8 (active) teTeX @3.0_1 (active) texi2html @1.76_3 (active) texinfo @4.8_1 (active) TeXmacs @1.0.6_1 (active) tiff @3.8.0_0+darwin_8 (active) zlib @1.2.3_0 (active)

[gwright@…]

Is this still a problem? Now that I look again at the messages, it looks more and more like a hardware issue.

Your hardware is essentially identical to mine and I have had no trouble building clisp, running maxima or using TeXmacs.

Best Wishes, Greg

[james.sumners@…]

Errors and memtest output.

[gwright@…]

James:

Could you try building with the +nolibsigsegv variant? This may be related to incorrect signal handling in OS X. Using that variant may be a workaround.

[gwright@…]

* Bug 8343 has been marked as a duplicate of this bug. *

[vincent-opdarw@…]

For me, the +nolibsigsegv variant does not solve the problem. I still get the same crashes.

[james.sumners@…]

Some more crash reports.

[wojtekr@…]

I seem to suffer from the same bug. Running clisp in Terminal causes a CrashReporter event stating that lisp.run has died - clisp continues to run though after that. Compiling clisp from DP gives lot of these errors (with different crashdumps it seems). Hardware is PB 12" 1.5GHz, 1.25GB RAM.

Date/Time: 2006-06-15 18:32:05.947 +0200 OS Version: 10.4.6 (Build 8I127) Report Version: 4

Command: lisp.run Path: /opt/local/lib/clisp/base/lisp.run Parent: bash [3577]

Version: ??? (???)

PID: 3578 Thread: 0

Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x19facaa4

Thread 0 Crashed: 0 lisp.run 0x000704c0 closed_buffered + 48 1 lisp.run 0x00078e88 closed_all_files + 108 2 lisp.run 0x00028b2c loadmem_from_handle + 3168 3 lisp.run 0x00028dec loadmem + 132 4 lisp.run 0x000291e4 init_memory + 880 5 lisp.run 0x0002b81c main + 3924 6 lisp.run 0x00001fd8 _start + 340 (crt.c:272) 7 lisp.run 0x00001e80 start + 60

[...]

[wojtekr@…]

Actually - this is hilarious - I get the same behavior from SBCL port. Launching sbcl in a terminal causes a crashreporter event just after showing it's SBCL free software blurb and before the '*' prompt appears:

Command: sbcl Path: /opt/local/bin/sbcl Parent: bash [14884]

Version: ??? (???)

PID: 9277 Thread: 0

Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x10128424

Thread 0 Crashed: 0 <<00000000>> 0x10073e4c 0 + 268910156 1 sbcl 0x00009afc main + 1116 (runtime.c:399) 2 sbcl 0x00002314 _start + 340 (crt.c:272) 3 sbcl 0x000021bc start + 60

Thread 0 crashed with PPC Thread State 64:

srr0: 0x0000000010073e4c srr1: 0x000000000000f030 vrsave:

0x0000000000000000

cr: 0x22002484 xer: 0x0000000000000005 lr: 0x0000000000009afc ctr:

0x0000000010073e28

r0: 0x0000000000000000 r1: 0x00000000bffff7f0 r2: 0x00000000000196c8 r3:

0x0000000000000000

r4: 0x0000000000705000 r5: 0x0000000000000000 r6: 0x0000000000000000 r7:

0x0000000011730000

r8: 0x0000000000000000 r9: 0x00000000000196d8 r10: 0x0000000010128427 r11:

0x0000000000000000

r12: 0x0000000090005f60 r13: 0x0000000000000000 r14: 0x0000000000905030 r15:

0x0000000000705060

r16: 0x0000000000705100 r17: 0x0000000011730000 r18: 0x000000000800000b r19:

0x0000000010073d9f

r20: 0x0000000000000000 r21: 0x000000001000f2cd r22: 0x0000000000705000 r23:

0x000000001000fd0f

r24: 0x000000000800000b r25: 0x00000000100011b7 r26: 0x0000000000000000 r27:

0x0000000000000000

r28: 0x0000000000000000 r29: 0x0000000000000000 r30: 0x0000000000000000 r31:

0x0000000010073e28

Binary Images Description:

0x1000 - 0x15fff sbcl /opt/local/bin/sbcl

0x8fe00000 - 0x8fe51fff dyld 44.4 /usr/lib/dyld 0x90000000 - 0x901bbfff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x90213000 - 0x90218fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib

I don't seem to suffer from any other random/non-random crashes and everything's fine with my hardware, according to AHT.

[gwright@…]

Hi Wojtek,

Is sbcl _really_ crashing or just generating CrashReporter logs? It is possible tp configure CrashReporter to generate lots of false indications of crashes, since it doesn't understand garbage collection. (The garbage collector may attempt access to invalid memory locations. Sbcl properly catches these exceptions and proceeds normally.)

The sbcl developers have documented the flakey handling of signal under OS X; there is a document somewhere summarizing their findings. You might search through planet.lisp.org to find it.

-Greg

[wojtekr@…]

Oh geez, I had no idea about this SBCL issue with false reporting. After switching CrashReporter to "Basic" mode of operation with CrashReporterPrefs, these logs and CrashReporter backtraces popups went away with sbcl. Sorry for the fuss and being lame. :) Will now check it with CLISP as soon as it gets reinstalled.

[wojtekr@…]

CLISP started to behave normally, too after turning CrashReporter to basic reporting mode. Thanks again.

PS. Would installing it with +nolibsigsegv made these 'fake' crashdumps go away, even with 'Developer' CrashReporter mode?

[vincent-opdarw@…]

(In reply to comment #11)

Is sbcl _really_ crashing or just generating CrashReporter logs? It is possible tp configure CrashReporter to generate lots of false indications of crashes, since it doesn't understand garbage collection. (The garbage collector may attempt access to invalid memory locations. Sbcl properly catches these exceptions and proceeds normally.)

Yes, CrashReporter is buggy: it indicates a crash though the corresponding exception has been caught, as seen on the following program:

#include <unistd.h> #include <signal.h>

void sigbus(int x) {

_exit(0);

}

int main(void) {

char *p = 0; signal(SIGBUS, &sigbus); *p = 0; return 0;

}

[wojtekr@…]

Understood. That wraps it up for me, thanks.

[markd@…]

clisp is at 2.40. Can this be closed?

[vinc17@…]

AFAIK, it was not a bug in clisp, but in the Crash Reporter, as the signals were expected and trapped.

[markd@…]

Well I'm going to close it. If someone sees fit to reopen it, please update the summary line so it makes sense as the problem is understood now.