Invalid use of Fmember in sigchld_handler

Invalid use of Fmember in sigchld_handler

[Andreas Schwab]

In sigchld_handler Fmember is used to find entries in deleted_pid_list,
but Fmember does not know about mark bits.  Moreover, make_fixnum_or_float
can call malloc, which is also forbidden here.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Invalid use of Fmember in sigchld_handler

[Kim F. Storm]

Andreas Schwab <schwab@suse.de> writes:

> In sigchld_handler Fmember is used to find entries in deleted_pid_list,
> but Fmember does not know about mark bits.  Moreover, make_fixnum_or_float
> can call malloc, which is also forbidden here.

.. and local var `pid' must be pid_t rather than EMACS_INT.

Thank you for proof-reading this code!!

I have installed a fix.  Please take a look!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Invalid use of Fmember in sigchld_handler

[Richard Stallman]

Thanks for fixing this so fast.

Re: Invalid use of Fmember in sigchld_handler

[Stefan Monnier]

> In sigchld_handler Fmember is used to find entries in deleted_pid_list,
> but Fmember does not know about mark bits.

>From lisp.h:

   #ifndef XGCTYPE
   /* The distinction does not exist now that the MARKBIT has been eliminated.  */
   #define XGCTYPE(a) XTYPE (a)
   #endif

The GC_foo macros shouldn't matter any more.  I haven't removed them yet,
because when I installed my "remove markbits" patch I wanted to keep changes
to a minimum to ease acceptance, debugging, and maintenance, and afterwards
it seemed too close to the release.


        Stefan


PS: But of course the make_fixnum_or_float call was problematic, so this
remark doesn't make any difference w.r.t the patch that Kim installed.

Re: Invalid use of Fmember in sigchld_handler

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> In sigchld_handler Fmember is used to find entries in deleted_pid_list,
>> but Fmember does not know about mark bits.
>
>>From lisp.h:
>
>    #ifndef XGCTYPE
>    /* The distinction does not exist now that the MARKBIT has been eliminated.  */
>    #define XGCTYPE(a) XTYPE (a)
>    #endif

That #ifndef seems to indicate that there are cases where GC_ does matter.
At least, it isn't obvious that some other definition of XGCTYPE cannot exist...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Invalid use of Fmember in sigchld_handler

[Stefan Monnier]

>>> In sigchld_handler Fmember is used to find entries in deleted_pid_list,
>>> but Fmember does not know about mark bits.
>> 
>>> From lisp.h:
>> 
>> #ifndef XGCTYPE
>> /* The distinction does not exist now that the MARKBIT has been eliminated.  */
>> #define XGCTYPE(a) XTYPE (a)
>> #endif

> That #ifndef seems to indicate that there are cases where GC_ does matter.
> At least, it isn't obvious that some other definition of XGCTYPE cannot exist...

"grep XGCTYPE" indicates it's not defined anywhere else.


        Stefan

Re: Invalid use of Fmember in sigchld_handler

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> That #ifndef seems to indicate that there are cases where GC_ does
>> matter.  At least, it isn't obvious that some other definition of
>> XGCTYPE cannot exist...
>
> "grep XGCTYPE" indicates it's not defined anywhere else.

It does seem like it would document the situation better if the
definition were simply made unconditional.

-Miles

-- 
.Numeric stability is probably not all that important when you're guessing.

Re: Invalid use of Fmember in sigchld_handler

[Stefan Monnier]

>>> That #ifndef seems to indicate that there are cases where GC_ does
>>> matter.  At least, it isn't obvious that some other definition of
>>> XGCTYPE cannot exist...
>> 
>> "grep XGCTYPE" indicates it's not defined anywhere else.

> It does seem like it would document the situation better if the
> definition were simply made unconditional.

Go ahead and cleanup now if you want.
Me, I never know where to stop, so I'd rather wait post-22 when it can be
done much more calmly.


        Stefan