[tex-live] Re: [tex-implementors] Re: bug in etex

[Peter Breitenlohner]

On Wed, 14 Jul 2004, Olaf Weber wrote:

> In particular, it looks like the code
>
> if (cur_cmd=toks_register)or(cur_cmd=assign_toks) then
>  begin if cur_cmd=toks_register then
>    if cur_chr=mem_bot then
>      begin scan_register_num;
>      if cur_val<256 then q:=equiv(toks_base+cur_val)
>      else  begin find_sa_element(tok_val,cur_val,false);
>        if cur_ptr=null then q:=null
>        else q:=sa_ptr(cur_ptr);
>        end;
>      end
>    else q:=sa_ptr(cur_ptr)                               { <---1--- }
>  else q:=equiv(cur_chr);
>  if q=null then sa_define(p,null)(p,undefined_cs,null)   { <---2--- }
>  else  begin add_token_ref(q); sa_define(p,q)(p,call,q);
>    end;
>  goto done;
>  end
>
> can get to (1) with cur_ptr=null.  When null==0, the sa_ptr(cur_ptr)
> will read from mem[1], which when I checked it at that point contained
> all zeros, therefore effectively assigning a null to q.  This case is
> then handled at (2).
>
> A common idiom for the use of cur_ptr is like this:
>    if cur_ptr=null then #:=null at +else #:=sa_ptr(cur_ptr);
>
> If I make a similar change (through web2c's etex.fix file, given
> below) then the crashes go away.  Whether this is the _correct_ thing
> to do is another matter...

Hi Olaf,

your analysis of the problem is certainly correct. The proposed change will
indeed avoid the segmentation fault but will NOT yield correct results.

There is something basically wrong with (that part of) the sparse array handling.

The basic idea is that the
 	\toksdef\whatevertoks = 266
should first create that token register (if it doesn't already exist) and
then increase its reference count, such that this register will not
disappear. Thus a later reference to \whatevertoks should work without such
a safeguard.

Somehow the logic of all that is brokem somewhere and I'll have to find out
where.

regards
Peter Breitenlohner <peb at mppmu.mpg.de>