On Tue, Jun 22, 2021 at 8:43 AM Daniel Colascione <dancol@dancol.org> wrote:

> On 6/21/21 6:00 AM, Fejfighter wrote:
>
>
> > code is up here:
> > https://github.com/fejfighter/emacs/tree/feature/newgc
> > <https://github.com/fejfighter/emacs/tree/feature/newgc>
> > I'm hoping now that it's a little closer to master and compiling
> > someone might have a little more luck with the segfault issue I have
> > been facing but I will keep try in the mean time,
>
> FWIW, I find rr [1] to be exceptionally useful for diagnosing segfaults
> like this.
>
>
> [1] https://rr-project.org/
>

While I had no luck with rr, I did trace that particular issue to not
unprotecting memory, which got me through a little further to a point of a
compacting sweep.
This is where I have been spinning my wheels for the last few weeks in the
short bursts of time I get to look at this codebase.

The problem is highlighted by xxx_check_obarray, but will show up in future
reads, where the ob array is not swept and does not get the updated
references.
I feel like it might be a special case where a global vector has
references, because when marking we traverse the array as required, but
this does not occur when sweeping, however, it does not affect other
vector-like things.

I think I will need to update the obarray, but simply calling
`scan_vectorlike(XPNTR(Vobarray), GC_PHASE_SWEEP);`  has bad values at that
point.

I'm hoping that this will either jog your memory and provide some
background or get someone curious that might have a different understanding
of how it all interacts and we can get over this particular hump,

Thanks,
Jeff W