Due to the unfortunate state of affairs at Lucid, perhaps someone out
there can help us out. Our computer staff recently installed Lucid
4.1.1 for solaris. It seemed to be fine until I tried compiling a
simple program, then I found out it bombs! Does anyone know of any
solution for this problem? Is anyone else out there running lucid
under solaris?
-- Prof. David Chelberg (···@ecn.purdue.edu)
> (compile-file "~/hw2.lisp")
;;; Reading source file "home/dynamo/b/dmc/hw2.lisp"
Not enough foreign stack to handle interrupt: ~
Handling overflow first.
Expanding multitasking main foreign stack due to overflow.
Not enough foreign stack to handle interrupt: ~
Handling overflow first.
Expanding multitasking main foreign stack due to overflow.
Not enough foreign stack to handle interrupt: ~
... much of the same deleted
Expanding multitasking main lisp stack due to overflow.
Expanding multitasking main lisp stack due to overflow.
Expanding multitasking main lisp stack due to overflow.
Expanding multitasking main lisp stack due to overflow.
Expanding multitasking main lisp stack due to overflow.
Expanding multitasking main lisp stack due to overflow.
Stack pointer before interrupt wasn't on any known stack
Stack pointer after interrupt wasn't on any known stack
Attempting to print interrupt data.
Sigstate: 996748
sq (= nil) : 890005
signal : 12
code : 0
sigcontext ptr : 9968C0
siginfo ptr : 0
sigregisters ptr : ABADFACE
sigport ptr : 996730
mask_0 : 0
mask_1 : 0
sp_before : EF7D3F88
sp_after : EF7D3E18
pc_before : 936AF8
pc_to_resume_at : 936AF8
fp_before : EF7D3E18
cp_before : 7
synchronous_p : 0
logical_signal : 0
deferred_signal : 0
deferred_code : 0
foreign_context_p : 0
lisp_will_handle_signal_p : 0
lisp_will_restart_scheduler_p : 0
lisp_status_bits : 0
c_status_bits : 0
lisp_stack_status : WILD-FRONTIER
foreign_stack_status : INSIDE-CURRENT-STACK
stack_params_mask : BFC
lisp_stack_origin : EFF9FFFC
lisp_stack_frame_pointer : EF7D3E18
lisp_stack_frontier : EF7CFE18
lisp_stack_soft_limit : EF7FFFFC
lisp_stack_hard_limit : EF7CFFFC
foreign_stack_origin : EFFFFFFC
foreign_stack_frontier : EF7D3F88
foreign_stack_soft_limit : EF611B96
foreign_stack_hard_limit : ABADFACE
previous_lisp_stack_origin : C9BFFC
previous_lisp_stack_soft_limit : ABADFACE
previous_foreign_stack_origin : ABADFACE
previous_foreign_stack_soft_limit : ABADFACE
lisp_stack_guards_remaining : ABADFACE
foreign_stack_guards_remaining : ABADFACE
misc1 : ABADCAFE
misc2 : ABADCAFE
misc3 : ABADCAFE
misc4 : ABADCAFE
current (multitasking) stack:
stack-group-frame-pointer : EFF9F0C0
stack-group-bottom : EFF9FFFC
stack-group-original-fp : EFF9FFC0
stack-group-soft-top : EF7FFFFC
stack-group-hard-top : EF7CFFFC
stack-group-foreign-bottom : EFFFFFFC
stack-group-foreign-soft-top : EF611B96
stack-group-foreign-hard-top : EFF9FFFC
stack-group-state : ACTIVE
previous (multitasking) stack:
stack-group-frame-pointer : C9BCB0
stack-group-bottom : C9BFFC
stack-group-original-fp : C9BF78
stack-group-soft-top : C6FFFC
stack-group-hard-top : C3FFFC
stack-group-foreign-bottom : CF3FFC
stack-group-foreign-soft-top : CCBFFC
stack-group-foreign-hard-top : C9BFFC
stack-group-state : ACTIVE
Stopping lisp. Type fg to resume.
Stopped (signal)
(wd now: ~)
;;; Typing fg causes it to print this same message again!
In article <··········@mozo.cc.purdue.edu> ···@piccolo.ecn.purdue.edu (David M Chelberg) writes:
> (compile-file "~/hw2.lisp")
;;; Reading source file "home/dynamo/b/dmc/hw2.lisp"
Not enough foreign stack to handle interrupt: ~
Handling overflow first.
Expanding multitasking main foreign stack due to overflow.
Not enough foreign stack to handle interrupt: ~
Handling overflow first.
Expanding multitasking main foreign stack due to overflow.
Not enough foreign stack to handle interrupt: ~
... much of the same deleted
This behaviour is due to a Solaris 2.3 kernel patch. The explanation
I got from a Lucid rep (before they filed) was:
> Not enough foreign stack to handle interrupt: ~
> Handling overflow first.
> Expanding multitasking main foreign stack due to overflow.
This is very likely a known problem which occurs due to conflicts
between Lisp and the Sun mandatory kernal patches (I cannot remember
nor find which exact patch it is). I am including below a patch
that we would like for you to try and that has worked for others
experiencing the same problems. This DBCS patch should work (and
therefore should probably be used) with any DBCS release of
LCL/Solaris 4.1.x.
You need patch bug-7276.
Martin
In article <··········@mozo.cc.purdue.edu>,
David M Chelberg <···@piccolo.ecn.purdue.edu> wrote:
>Due to the unfortunate state of affairs at Lucid, perhaps someone out
>there can help us out. Our computer staff recently installed Lucid
>4.1.1 for solaris.
>
>> (compile-file "~/hw2.lisp")
>;;; Reading source file "home/dynamo/b/dmc/hw2.lisp"
>Not enough foreign stack to handle interrupt: ~
> Handling overflow first.
>Expanding multitasking main foreign stack due to overflow.
>Not enough foreign stack to handle interrupt: ~
> Handling overflow first.
>
>... much of the same deleted
>
>Expanding multitasking main lisp stack due to overflow.
>Stack pointer before interrupt wasn't on any known stack
>Stack pointer after interrupt wasn't on any known stack
>Attempting to print interrupt data.
There was a patch for this. I think this is bug 7276, but it's been a
long while -- like the beginning of the year -- and I've been on a
holiday since then :-).
Don't use a ~ (tilde) in pathnames or LCL:RUN-PROGRAM/LCL:SHELL and
you'll be mostly OK.
Send me e-mail (address below) if you want to try a copy of 7276.
-- Chris.
(··@lks.csi.com)