[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fix to long-standing crashes in GC
From: |
Kim F. Storm |
Subject: |
Re: Fix to long-standing crashes in GC |
Date: |
20 May 2004 00:04:34 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
Stefan Monnier <address@hidden> writes:
> >> Please try finding out *precisely* which stack slot
> >> mark_memory is currently examining. Which stack frame is it in?
> >> What variable is it?
> >>
>
> > Found another case where a stack pointer points to bogus data,
> > this time in Flet, variable *temps:
>
> What do you mean by "found"? Did you inspect the code looking for
> suspicious things, or did GDB lead you there?
I removed my hack to accept Lisp_Misc_Free objects (to better
understand where the problem originated), and then emacs crashed
there... so GDB lead me there.
>
> > Here we call Feval, which -- at some point in time will trigger GC --
> > and "temps" is filled with random data, some of which are bogus Lisp
> > object pointers.
>
> If gcpros are used, it seems safe: the gcpro2.nvars is initially set to 0 so
> none of the random values in the uninitialized `temps' array are considered
> and then as the array gets filled gcpro2.nvars is incremented accordingly.
> Looks fine.
Yes, that works fine.
>
> If gcpros are not used (i.e. we use conservative stack scanning), it
> shouldn't be a problem either because the conservative scan goes through
> some trouble to ensure that it ignores words pointing to non-GC-managed
> (or non-live) objects.
I have now found two different cases where a pointer on the stack
points to GC-managed memory (mem_find finds it), to a cons cell with a
Lisp_Misc_Free in the car and a bogus list in the cdr. I suspect there
are many more such cases.
I included one such list in my previous mail. So even if we accepted
the Lisp_Misc_Free object (as I said, I reverted that change locally to
understand the problem), following the cdr would lead to a bad Misc
object anyway.
>
> So I think w need to look further.
Looking for what?
More proff that current functionality is broken, or ways to fix it?
--
Kim F. Storm <address@hidden> http://www.cua.dk
- Re: Fix to long-standing crashes in GC, (continued)
Re: Fix to long-standing crashes in GC, Robert Marshall, 2004/05/15
Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/17
- Re: Fix to long-standing crashes in GC, Luc Teirlinck, 2004/05/17
- Re: Fix to long-standing crashes in GC, Richard Stallman, 2004/05/18
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/19
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/19
- Re: Fix to long-standing crashes in GC,
Kim F. Storm <=
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/19
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/19
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/19
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/19
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/22
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/23
- Re: Fix to long-standing crashes in GC, Richard Stallman, 2004/05/23
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/24
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/28
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/29