From: Frank G. <fr...@ma...> - 2007-05-19 20:55:34
|
Dear Clispers, being completely new to Clisp (but not to Lisp) I am trying to get Clisp running on HP-UX 11i (HP-UX 11.11) on PA-RISC1.1-based machine. I get a compile done, but when the Makefile calls ./lisp,run ... for the first run I get a memory fault with resulting coredump. Any attempt to get more info from Clisp failed - I assume the coredump is happening quite early after startup... Any idea how I can debug this? Thx for any pointers. Any help really appreciated. Regards Frank -- Frank Goenninger fr...@ma... |
From: Vadim K. <va...@gm...> - 2007-05-20 06:41:34
|
Frank Goenninger wrote: > Dear Clispers, > > being completely new to Clisp (but not to Lisp) I am trying to get > Clisp running on HP-UX 11i (HP-UX 11.11) on PA-RISC1.1-based machine. > I get a compile done, but when the Makefile calls > > ./lisp,run ... > > for the first run I get a memory fault with resulting coredump. > your problem resembles mine when I compiled using MSVC++ in Windors. The fix came into the CVS, but the #ifdef-ed compilers aren't fixed, namely HP-UX one. Look for the following code in lispbibl.d (this is after fixing) # Unspecified length of arrays in structures: # struct { ...; ...; type x[unspecified]; } # Instead of sizeof(..) you'll always have to use offsetof(..,x). #if defined(GNU) || defined(MICROSOFT) /* GNU & MS C are able to work with arrays of length 0 */ #define unspecified 0 #elif 0 # Usually one would omit the array's limit #define unspecified #else # However, HP-UX- and IRIX-compilers will only work with this: #define unspecified 1 #endif Even with comment about HP-UX compilers, it do not justify wrong aligment logic. try modifying this file according to your situation and see how it goes. > Any attempt to get more info from Clisp failed - I assume the > coredump is happening quite early after startup... > > Any idea how I can debug this? > > Thx for any pointers. Any help really appreciated. > > Regards > Frank > Best regards, Vadim. |
From: Frank G. <fr...@ma...> - 2007-05-20 12:41:38
|
Am 20.05.2007 um 08:31 schrieb Vadim Konovalov: > Frank Goenninger wrote: >> Dear Clispers, >> >> being completely new to Clisp (but not to Lisp) I am trying to >> get Clisp running on HP-UX 11i (HP-UX 11.11) on PA-RISC1.1-based >> machine. I get a compile done, but when the Makefile calls >> >> ./lisp,run ... >> >> for the first run I get a memory fault with resulting coredump. >> > > your problem resembles mine when I compiled using MSVC++ in Windors. > The fix came into the CVS, but the #ifdef-ed compilers aren't > fixed, namely HP-UX one. > > Look for the following code in lispbibl.d (this is after fixing) > > # Unspecified length of arrays in structures: > # struct { ...; ...; type x[unspecified]; } > # Instead of sizeof(..) you'll always have to use offsetof(..,x). > #if defined(GNU) || defined(MICROSOFT) /* GNU & MS C are able to > work with arrays of length 0 */ > #define unspecified 0 > #elif 0 > # Usually one would omit the array's limit > #define unspecified > #else > # However, HP-UX- and IRIX-compilers will only work with this: > #define unspecified 1 > #endif > > > Even with comment about HP-UX compilers, it do not justify wrong > aligment logic. > try modifying this file according to your situation and see how it > goes. I forced a specific value for "unspecified" with #define unspecified 1 after the code block you mentioned above. I am still in "monkey mode" - just not really having a glue on what's going on here. I only see that the Makefile tries to execute ./lisp.run -B . -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW - x "(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)" ... hmm ... What does that tell me ? Thx for any further help! Frank |
From: Vadim K. <va...@gm...> - 2007-05-20 12:54:14
|
Frank Goenninger wrote: > Am 20.05.2007 um 08:31 schrieb Vadim Konovalov: > > >> Frank Goenninger wrote: >> >>> Dear Clispers, >>> >>> being completely new to Clisp (but not to Lisp) I am trying to >>> get Clisp running on HP-UX 11i (HP-UX 11.11) on PA-RISC1.1-based >>> machine. I get a compile done, but when the Makefile calls >>> >>> ./lisp,run ... >>> >>> for the first run I get a memory fault with resulting coredump. >>> >>> >> your problem resembles mine when I compiled using MSVC++ in Windors. >> The fix came into the CVS, but the #ifdef-ed compilers aren't >> fixed, namely HP-UX one. >> >> Look for the following code in lispbibl.d (this is after fixing) >> >> # Unspecified length of arrays in structures: >> # struct { ...; ...; type x[unspecified]; } >> # Instead of sizeof(..) you'll always have to use offsetof(..,x). >> #if defined(GNU) || defined(MICROSOFT) /* GNU & MS C are able to >> work with arrays of length 0 */ >> #define unspecified 0 >> #elif 0 >> # Usually one would omit the array's limit >> #define unspecified >> #else >> # However, HP-UX- and IRIX-compilers will only work with this: >> #define unspecified 1 >> #endif >> >> >> Even with comment about HP-UX compilers, it do not justify wrong >> aligment logic. >> try modifying this file according to your situation and see how it >> goes. >> > > I forced a specific value for "unspecified" with > > #define unspecified 1 > this way you didn't change the situation; at least try #define unspecified 0 > after the code block you mentioned above. I am still in "monkey mode" > - just not really having a glue on what's going on here. I only see > that the Makefile tries to execute > > ./lisp.run -B . -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW - > x "(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit)) > (ext::exit t)" > > ... hmm ... What does that tell me ? > can you get a stacktrace out of your coredump? Vadim. |
From: Frank G. <fr...@ma...> - 2007-05-21 06:51:30
|
Hi Vadim - Am 20.05.2007 um 14:43 schrieb Vadim Konovalov: >>> Look for the following code in lispbibl.d (this is after fixing) >>> >>> # Unspecified length of arrays in structures: >>> # struct { ...; ...; type x[unspecified]; } >>> # Instead of sizeof(..) you'll always have to use offsetof(..,x). >>> #if defined(GNU) || defined(MICROSOFT) /* GNU & MS C are able to >>> work with arrays of length 0 */ >>> #define unspecified 0 >>> #elif 0 >>> # Usually one would omit the array's limit >>> #define unspecified >>> #else >>> # However, HP-UX- and IRIX-compilers will only work with this: >>> #define unspecified 1 >>> #endif >>> >>> >>> Even with comment about HP-UX compilers, it do not justify wrong >>> aligment logic. >>> try modifying this file according to your situation and see how >>> it goes. >>> >> >> I forced a specific value for "unspecified" with >> >> #define unspecified 1 >> > > this way you didn't change the situation; > > at least try > > #define unspecified 0 Hm? I am using GCC so I thought the above code defines unspecified as 0 ... Anyway - I tried with #define unspecified 0 - same result. Stacktrace / Call stack: #0 0x36974 in gar_col_normal () at /opt/clisp/clisp-2.41/src/ spvw_garcol.d:148 <-- HERE: SIGSEGV ... #1 0x38250 in do_gar_col_simple () at /opt/clisp/clisp-2.41/src/ spvw_garcol.d:2376 #2 0xddde8 in with_gc_statistics (fun=0x4002d6ba <do_gar_col_simple>) at /opt/clisp/clisp-2.41/src/predtype.d:3137 #3 0x2d8e0 in make_space_gc (need=0, heap_ptr=0x40030598, stack_ptr=0x7f7f09e8) at /opt/clisp/clisp-2.41/src/spvw_garcol.d:2405 #4 0x2eeb0 in allocate_vector (len=2139030890) at /opt/clisp/ clisp-2.41/src/spvw_typealloc.d:89 #5 0x2f048 in initmem () at /opt/clisp/clisp-2.41/src/subrkw.d:7 #6 0x35510 in main (argc=1, argv=0x7f7f0724) at /opt/clisp/ clisp-2.41/src/spvw.d:2922 Code at level 0 (file spvw_garcold.d:148): for_all_threadobjs( gc_mark(*objptr); ); /* threads */ /* The callers in back_trace are mostly already marked: they refer to subrs and closures that are currently being called and therefore cannot possibly be garbage-collected. But a few remain unmarked, so make sure all are really marked: */ for_all_back_traces({ for (; bt != NULL; bt = bt->bt_next) gc_mark(bt->bt_function); }); Hmm - gcc and the debugger must be confused due to the preprocessing step from D to C ... Any ideas? Thx!!!! Frank |
From: Vadim K. <va...@gm...> - 2007-05-21 08:00:07
|
Frank Goenninger wrote: ... > > Hm? I am using GCC so I thought the above code defines unspecified as > 0 ... you didn't mentioned GCC earlier, so I thought you've faced HP-UX #ifdef Indeed, GCC should be with mentioned #ifdef set, so this invalidates my assumption. I don't have HP-UX access, so I hardly be useful. Just for the record, your sympthoms were similar to mine, but now its obvious that exact point of error is different. Best regards, Vadim. > - same result. > > Stacktrace / Call stack: > > #0 0x36974 in gar_col_normal () at > /opt/clisp/clisp-2.41/src/spvw_garcol.d:148 <-- HERE: SIGSEGV ... > #1 0x38250 in do_gar_col_simple () at > /opt/clisp/clisp-2.41/src/spvw_garcol.d:2376 > #2 0xddde8 in with_gc_statistics (fun=0x4002d6ba <do_gar_col_simple>) > at /opt/clisp/clisp-2.41/src/predtype.d:3137 > #3 0x2d8e0 in make_space_gc (need=0, heap_ptr=0x40030598, > stack_ptr=0x7f7f09e8) at /opt/clisp/clisp-2.41/src/spvw_garcol.d:2405 > #4 0x2eeb0 in allocate_vector (len=2139030890) at > /opt/clisp/clisp-2.41/src/spvw_typealloc.d:89 > #5 0x2f048 in initmem () at /opt/clisp/clisp-2.41/src/subrkw.d:7 > #6 0x35510 in main (argc=1, argv=0x7f7f0724) at > /opt/clisp/clisp-2.41/src/spvw.d:2922 > > Code at level 0 (file spvw_garcold.d:148): > > for_all_threadobjs( gc_mark(*objptr); ); /* threads */ > /* The callers in back_trace are mostly already marked: > they refer to subrs and closures that are currently being > called and therefore cannot possibly be garbage-collected. > But a few remain unmarked, so make sure all are really marked: */ > for_all_back_traces({ > for (; bt != NULL; bt = bt->bt_next) > gc_mark(bt->bt_function); > }); > > Hmm - gcc and the debugger must be confused due to the preprocessing > step from D to C ... > > Any ideas? > > Thx!!!! > > Frank > > > > > |
From: larry <la...@li...> - 2007-06-17 10:35:41
|
> Dear Clispers, > I get a compile done, but when the Makefile calls > > ./lisp,run ... > > for the first run I get a memory fault with resulting coredump. > Regards > Frank > This patch should help: http://sourceforge.net/tracker/index.php?func=detail&aid=1607416&group_id=1355&atid=101355 regards, larry liimatainen |