Re: Call for testers on bytecode fix (GCPRO_STACK/freed lrecord crash)

Hrvoje> "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Yes, great catch! Hrvoje> Doesn't set-buffer change the values of all buffer-local Hrvoje> variables? I'm not sure if buffer-local vars can be Hrvoje> dontuse-ed, but if they can, Bset_buffer can GC. It can theoretically call GC, but not in that place. (Look at get_buffer.) I guess the equal methods might GC, or that's what the code assumes, anyway. So I guess we stick a GCPRO_STACK there, too. Do you want me to take this again from now on, Stephen? (Again, many, many thanks.) (Hrvoje is of course, in a roundabout way, alluding to the completely fucked interaction between buffer-local variables, dynamic binding, and assignment. But last I tried, FSFmacs was even worse than we.) Hrvoje> Given how hard GC is to trace, maybe we really should just update Hrvoje> nvars whenever the stack changes. I wonder what the impact on Hrvoje> performance would be. It's not quite so easy. Look at Bcall where it's necessary to do the update *before* the stack pointer changes. The general implementation strategy for the byte-code is kind of brain-dead, anyway. It sure isn't suitable for anything but tectonic performance, that's for sure. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla