bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#74966: 31.0.50; Crash report (using igc on macOS)


From: Pip Cet
Subject: bug#74966: 31.0.50; Crash report (using igc on macOS)
Date: Fri, 20 Dec 2024 16:20:32 +0000

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

>>> Maybe the problem is in store_doc_string (doc.c:469 here), not sure.
>>> That function does
>>>
>>>   if (SUBRP (fun))
>>>     XSUBR (fun)->doc = offset;
>
> Sounds right.
>
>> That seems to be the cause, indeed. When I
>>
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>> src/doc.c | 5 ++++-
>>
>> modified   src/doc.c
>> @@ -479,7 +479,10 @@ store_function_docstring (Lisp_Object obj, EMACS_INT 
>> offset)
>>      fun = XCDR (fun);
>>    /* Lisp_Subrs have a slot for it.  */
>>    if (SUBRP (fun))
>> -    XSUBR (fun)->doc = offset;
>> +    {
>> +      if (!NATIVE_COMP_FUNCTIONP (fun))
>> +    XSUBR (fun)->doc = offset;
>> +    }
>>    else if (CLOSUREP (fun))
>>      {
>>        /* This bytecode object must have a slot for the docstring, since
>>
>> I don't get the assert anymore.
>
> `offset` here should be fixnum that gives the position of this docstring
> in the DOC file.  And FUN should be a function for which we found

Yes, but the nativecomp code assumes ->doc is an index into a
nativecomp'd subr's constant vector.  So we overwrite it with a docfile
index, access an out-of-bounds index and crash.

I think the best thing to do is to use separate fields for the "offset"
doc and the "index" doc; or at least, the second best thing, after
removing the entire docfile hack.

I've got a patch to do that, but I'm still testing...

Pip






reply via email to

[Prev in Thread] Current Thread [Next in Thread]