GNU bug report logs - #76180
[feature/igc] Remaining known tracing issues

Previous Next

Full log

Message #26 received at 76180 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: eggert <at> cs.ucla.edu, 76180 <at> debbugs.gnu.org, mattiase <at> acm.org,
 gerd.moellmann <at> gmail.com, stefankangas <at> gmail.com, acorallo <at> gnu.org
Subject: Re: bug#76180: [feature/igc] Remaining known tracing issues
Date: Wed, 12 Feb 2025 14:35:24 +0200

> Date: Tue, 11 Feb 2025 20:27:23 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: 76180 <at> debbugs.gnu.org, gerd.moellmann <at> gmail.com, mattiase <at> acm.org, acorallo <at> gnu.org, eggert <at> cs.ucla.edu, eliz <at> gnu.org
> 
> Pip Cet <pipcet <at> protonmail.com> writes:
> 
> > diff --git a/src/lread.c b/src/lread.c
> > index e8cd689d794..67c1bbe5f7b 100644
> > --- a/src/lread.c
> > +++ b/src/lread.c
> > @@ -3483,6 +3483,11 @@ bytecode_from_rev_list (Lisp_Object elems, Lisp_Object readcharfun)
> >  	            || NILP (vec[CLOSURE_CONSTANTS]))))))
> >      invalid_syntax ("Invalid byte-code object", readcharfun);
> >  
> > +#ifdef HAVE_MPS
> > +  if (XFIXNAT (vec[CLOSURE_STACK_DEPTH]) >= 1022)
> > +    error ("Byte-code object uses too much stack, increase HORRIBLE_ESTIMATE!");
> > +#endif
> > +
> >    if (STRINGP (vec[CLOSURE_CODE]))
> >      {
> >        if (STRING_MULTIBYTE (vec[CLOSURE_CODE]))
> > -- 
> > 2.48.1
> 
> Sorry, this hunk wasn't the one I meant to send.  This one needs to be
> applied after it:
> 
> diff --git a/src/lread.c b/src/lread.c
> index a638b6eec8e..ae312874574 100644
> --- a/src/lread.c
> +++ b/src/lread.c
> @@ -3576,7 +3576,7 @@ bytecode_from_rev_list (Lisp_Object elems, Lisp_Object readcharfun)
>      invalid_syntax ("Invalid byte-code object", readcharfun);
>  
>  #ifdef HAVE_MPS
> -  if (XFIXNAT (vec[CLOSURE_STACK_DEPTH]) >= 1022)
> +  if (size > CLOSURE_STACK_DEPTH && XFIXNAT (vec[CLOSURE_STACK_DEPTH]) >= 1022)
>      error ("Byte-code object uses too much stack, increase HORRIBLE_ESTIMATE!");
>  #endif
>  
> 
> to fix the obvious problem :-)

Can't we figure out how far to scan, instead of using some
more-or-less arbitrary constant?  The comments in scan_bc seem to
imply that figuring out the distance to scan should be possible?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.