Ar an dara lá de mí Méan Fómhair, scríobh Mats Lidell:
> Aidan Kehoe writes:
> I still can’t reproduce it, with AMD 64, GCC 6 and most of the configure
> flags of that ebuild.
Yes. Same thing for me.
> That ebuild uses newgc and non-mule, and it is rare that I use either.
> There is no prospect of my switching to non-mule, but I will switch to
> newgc day-to-day for the next few weeks at least, to see if it comes
Thanks. Maybe I should consider deprecating non mule to reduce the number of available
By the way - I have received another similar bug report. This time it is an assertion
that fails: https://bugs.gentoo.org/665106
. I can't reproduce this problem either.
Does the assertion provide any hints to you what is going on?
Yes, as do a few crashes in day-to-day use.
My initial crashes were in part because I set
gc-incremental-traversal-treshold to 10000, under the misunderstanding that
it did what gc-cons-incremental-threshold does. Its default value is 400000,
and with the lower value the kkcc_gc_stack grew uncontrollably large,
realloc fails, and XEmacs crashed. (And then crashed again while crashing,
because memory_full() calls GC recursively.)
But; that shouldn’t have happened. The object that was being traversed as
the realloc failed was a struct display_line that, as far as I can see, was
garbage, all its values were inconsistent. Your documented crash also seems
likely to be from traversal of a garbage object.
I wonder is it just as simple as the redisplay structures being
inconsistently marked as GC roots through the kkcc descriptions? That might
fit with my never seeing the crash on this TTY-only NEWGC build. Though it
should provoke the same crashes on a KKCC non-NEWGC build, which we don’t
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’