Re: Symbol's value as variable is void: region
Well, I've traced through pdump() a bit without becoming terribly
enlightened. I haven't "caught it in the act" of putting the wrong value
in the args field of zmacs-make-extent-for-region. I have noticed that
different builds cause it to be aliased to different values, always the
args array of some other function. First it was perform-replace, then it
was quit-char, then it was no-upper-case-p. But always the args field of
some other bytecode function. I've gotten the general idea of what pdump
does, although I don't fully understand it. I've learned enough to know
that there are some lines like this:
EMACS_INT rdata = pdump_get_entry (elt->obj)->save_offset;
in pdump_dump_rtables that don't make much sense.
'pdump_get_entry(elt->obj)' should always be exactly the same as 'elt',
otherwise something is very wrong, I think. So this line is just doing a
useless indirection and hashtable lookup. I don't think this has
anything to do with the bug I'm trying to track down, but it does look
bogus. At any rate, the bug must be happening somewhere inside pdump,
because the objects are correct in memory before pdump gets called, but
they are incorrect immediately after loading, even before relocation.
Who's maintaining dumper.c these days?
Eric Benson wrote:
Here's what I've got so far:
The 'args' field of the Lisp_Compiled_Function object that is the
function value of zmacs-make-extent-for-region is incorrect. The first
slot, i.e. f->args[0] should be the symbol 'region' but instead it is
the symbol 'from-string'. This seems to be the way it arrives from the
xemacs.dmp file. In fact, the f->args array appears to be exactly the
one that belongs to the function perform-replace, i.e. args[0] is
'from-string', args[1] is replacements, args[2] is query-flag, and so
on. In fact, it turns out that the f->args array in perform-replace
is == to the one in zmacs-make-extent-for-region, i.e. both functions
point to the same args array. This condition seems to have occurred
during dumping, because the two function objects have identical values
before relocation after reading the dump file. The most likely culprit
I can see is the hashing code in dump.c. It seems likely that somehow
these two arrays are getting thrown in the same hash bucket. Why
turning on error checking makes the problem go away is a mystery. I
can only guess that it perturbs the data just enough to avert a rarely
occurring bug. It does happen whether or not it's compiled with
optimization.
I'll try to look at this more tomorrow, but any advice is welcome.
Stephen J. Turnbull wrote:
>>>>>> "Eric" == Eric Benson <eric_a_benson(a)yahoo.com>
writes:
>>>>>>
>>>>>
>
> Eric> Can I assume this was already fixed on those other
> Eric> platforms, but the fix did not make it to Darwin? Can
> Eric> someone fill me in on the fix, so I can apply it to the
> Eric> Darwin version as well?
>
> No. As far as I know this has not been diagnosed.
>
>
>
>