Re: MPS: hash tables / obarrays

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Helmut Eller <eller.helmut@gmail.com> writes:
>
>>> I'd say a reference we didn't scan :-(.
>>>
>>> The is_mps with a Lisp_Object doesn't work with symbols, BTW, because
>>> the Lisp_Object doesn't contain a pointer, but an offset from lispsym.
>>
>> The function that tries to print is comp--final and the argument is the
>> expr.  When I call safe_debug_print on that it goes on for many pages
>> and ends with this:
>>
>>    #2314# 635 #2194# 636 #2181# 637 #2022# 638 #1949# 639 #1891# 640 
>> #1640#)) #s(comp-data-container nil #s(hash-table test
>>   igc.c:343: Emacs fatal error: assertion failed: h->obj_type != IGC_OBJ_FWD
>>
>>   Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647)
>>       at emacs.c:443
>>   443       signal (sig, SIG_DFL);
>>   The program being debugged stopped while in a function called from GDB.
>>   Evaluation of the expression containing the function
>>   (safe_debug_print) will be abandoned.
>>   When the function is done executing, GDB will silently stop.
>>   (gdb)
>>
>> So it could have something to do with hash tables after all.
>
> Could be, of course.
>
> Maybe you could try the following: In igc_check_fwd, where we find the
> header has IGC_OBJ_FWD,
>
>   void
>   igc_check_fwd (void *client)
>   {
>     if (is_mps (client))
>       {
>         struct igc_header *h = client_to_base (client);
>         igc_assert (h->obj_type != IGC_OBJ_FWD);
>       }
>   }
>
>   struct igc_fwd
>   {
>     struct igc_header header;
>     mps_addr_t new_base_addr;
>   };
>
> When h->obj_type == IGC_OBJ_FWD, then the header is actually an igc_fwd,
> and the new_base_addr points to where the object was forwarded to.
> dflt_fwd does that. Some phantasy debug commands woould look like
>
> (lldb) p *(struct igc_fwd *) h
> => ...new_base_addr = 0x1234
>
> (lldb) p *(struct igc_header *) 0x1234
> (lldb) p base_to_client ((void *) 0x1234)
>
> We could then perhaps, not always, see what the real object looks like.
> For example, if it is a symbol, its name etc. Maybe that gives us a
> clue.

Probably unrelated, but since we're talking native-comp... I've just
removed the special handling of comp units in the dump. This should be
unnecessary now that we traverse the dump, and it's actually against the
MPS rule that roots may not overlap...