Re: Problem using llx/urx in PS_LinkDest

[KHMan]

Jeff Kingston wrote:
> What Lout source file are you using to test for this problem?
> I sort of gather it's the expert's guide, and that the link
> to "yunit" is going wrong.  But in file outfile.ps of the
> current distribution, "yunit" seems OK:
> 
>     [ /Rect [720 3109 8346 3363] /Border [0 0 0] /View [ /XYZ null null null ]
>     /Subtype /Link /Dest /LOUTyunit /ANN pdfmark
> 
> I'm happy to look at it now but I need a test where something
> goes wrong.

Sorry for the delay, my DSL line was down for a few days.

Anyway, I have pinpointed the memory allocator problem in a post
to the list dated 2008-05-02 1856. As for the above:

Yes, it is w.r.t. the expert's guide. There are some failures in
user's guide also, but it is of course easier and faster to run
the former repeatedly. The /LOUTyunit output I mentioned is not in
the canonical distribution. I was testing my patch for link
targeting, which modifies z49.c. The patched z49.c was attached in
the posting dated 2008-04-29 1544. Please let me know if you want
it sent to you directly.

In order to target links properly, there is a current transform
matrix (CTM) which transforms the coordinates passed onto
PS_LinkDest() so that we can write a /View object that has target
coordinates expressed in absolute page coordinates. An example of
the target that the patched z49.c generates is thus:

Unpatched:

    [ /Dest /LOUTyunit /DEST pdfmark

Patched:

    [ /Dest /LOUTyunit /View [ /XYZ 737773.05 622.80 null ]
    /DEST pdfmark

The above is an example of the anomalous x-coord values. Prior to
this, PS_LinkDest() never uses the box coordinates, so this has
never been noticed.

The issue is due to bad values passed in llx and urx. The direct
cause of this is bad values of save_mark(x) coming from
FixAndPrintObject() in z23.c. These values looked like pointer
values. During testing, changing that part of the data struct from
union to struct makes large pointer values disappear, but a diff
still shows up anomalous values.

Tracing the history backwards, I found the problem in z07.c. It
looks to me like save_mark(x) is never explicitly zeroed at object
creation. A newly allocated object is okay, since calloc is used.
But since the memory allocator reuses objects by manipulating
pointers only, sometimes save_mark(x) will have a pointer value or
an old save_mark(x) value in place for a new object. This causes
the messed-up llx, urx values.

I have confirmed the problem by following the history of one
pointer value from its assignment in an old object and its
subsequent use in a later LINK_DEST_* object. Once save_mark(x) is
zeroed explicitly, the /View coordinates generates seems more
correct and all extra-large values are gone.

So, since it is a memory allocation problem, I think I will leave
it to the principal author to fix it. Of course, I can send in a
one-line patch to zero save_mark(x), but I think somebody has to
audit the memory allocator to make sure there aren't any similar
object initialization errors.

Please let me know if you want it described in more detail.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia