Why does segmentation fault happen in lisp in general ?
Is it due to memory leak ?
Can this be cured by invoking the garbage colllector frequently ?
~ roark
roark wrote:
> Why does segmentation fault happen in lisp in general ?
Generally, by speaking to C across an FFI.
>
> Is it due to memory leak ?
That would be an implementation specific bug, but you are asking for a
general cause and not even mentioning a particular implementation. That
might be due to a logic leak.
>
> Can this be cured by invoking the garbage colllector frequently ?
No, you probably have gone into infinite recursion or some other
innocent programming error that happens to strain one lisp
implementation to a point where it bugs out. You will have to painfully
reload everything and try to see what is going wrong in your application
that is tripping up your lisp, and try to get a detector in thhere that
stops the carnage before you lose your lisp. ie, before making the
deadly call do:
(let ((*dbg-depth* 0))
(deadly-call))
..and in deadly-call increment *dbg-depth* and when it gets to some
unreasonable value throw in a (break) so you do not lose your lisp.
If it comes from calling C, you just gots to stare at the FFI
delcarations and what you are passing until you get it right. if you
have the C code, could you try building sanity checks and graceful
handling into the C code so it does not take out your lisp.
hth,kzo
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
roark <········@gmail.com> writes:
> Why does segmentation fault happen in lisp in general ?
It's not clear what you're asking about: do you find your
implementation notifying you of segmentation faults, either by
entering the debugger, or by crashing? Or are you watching some Lisp
run under a debugger or system call tracer, and seeing segmentation
faults arise?
If your program is producing "visible" segmentation faults, then there
may be bugs in the implementation, or bugs in the program (e.g.,
passing invalid things to foreign functions, or exhausting stack
space).
However, some Lisp implementations use memory protection and
segmentation fault handlers as part of the memory management scheme,
by marking a page at the "end" of the current allocation area as
read-only and arranging to invoke the garbage collector when a
segmentation fault occurs with an address one of these read-only
pages. Watching such implementations under a debugger will perhaps
mislead you.
--
RmK
On Fri, 20 Apr 2007 01:15:46 -0700, roark wrote:
> Why does segmentation fault happen in lisp in general ?
It does?
--
Lars Rune Nøstdal
http://nostdal.org/
lispolos <····@myteam-software.com> writes:
> On Apr 20, 9:15 am, roark <········@gmail.com> wrote:
> > Why does segmentation fault happen in lisp in general ? [...]
>
> Before segfaulting, a decent Lisp may show you a message like this:
>
> "Sorry, this is a bug. Please inform [...]."
>
> Otherwise, it is the OS which will tell you the segfault; in this case
> (if the OS isn't written in Lisp), it will simply kill your program
> (due to lack of intelligence), and you'd rather have to blame the
> (anonymous) OS instead...
It's not the choice of implementation language that makes for poor
error handling. Any operating system that wanted better behavior
for applications could do better.
Lisp isn't better than many other languages because it can do things
other languages can do. It's better than many other languages because
it chooses to do things other languages don't choose to do.
And a Lisp-based OS is only a likely statement about the mindset of
the person making the operating system because it suggests the person
thought hard enough to want certain features, concepts, capabilities
made easily accessible in some way, so they could be used and passed
along. The choice to build on another language hints that those
capabilities and features won't get used, so why bother.