Re: Problem using llx/urx in PS_LinkDest

[KHMan]

Jeff Kingston wrote:
>> someone might have a good idea what went wrong
> 
> I'll look at it if you get completely stuck, but it's
> been a long time and you are probably well ahead of me.
> 
>> Changing oux from union into struct makes the
>> problem go away
> 
> Well, that suggests that some idiot has put two fields
> into a union and used them both.  I'd be tracking down
> all uses of the other fields of that union.  If that
> is the problem, let me know - I had better be the one
> to decide how to change the data layout.

Okay, I've got a candidate bug.

There is a memory allocation problem in that some new objects
aren't all zeroed out. Here is an example for the /LOUTyunit link
destination in the expert's guide document, based on my own trace
printouts.

Somewhere before the yunit tag, an object's oux union gets
assigned when it is used in a completely different object:

% z12:HEAD:has_key:pinpoint(z) = 14754764

This leads to unclean objects returned at later occasions:

% z07:save_mark(res) = 14754764
% z07:type(res) = 99
% z07:save_mark(res) = 14754764
% z07:type(res) = 18
% z07:save_mark(res) = 14754764
% z07:type(res) = 58
% z07:save_mark(res) = 14754764
% z07:type(res) = 58
% z07:save_mark(res) = 14754764
% z07:type(res) = 5

Most of these aren't fatal, but for objects that uses save_mark()
and assumes that save_mark() is initialized, it goes kaboom:

% z08:Manifest:LINK*:type(x) = 106
% z08:Manifest:LINK*:type(x) = 8
% z08:Manifest:LINK*:save_mark(x) = 14754764

Minor modifications to the sources that changes the memory
allocation pattern causes other link destinations to fail, so it
is likely a memory allocation and management problem.

So when Lout finally tries to generate a link destination, it goes:

%% LINK_DEST_NULL
% save_mark(x) = 14754764

Changing the oux union to a struct removes instances of large
pointer values being used for save_mark(), but there are still
some anomalous positions due to old save_mark() values. When
save_mark() is explicitly zeroed after the New() in z07.c, there
is some difference compared to the struct case, and the positions
are more correct, I think.

So the memory allocation routines needs looking into, I think.

As for link destination targeting, I plan to write a few proper
tests to make sure scale/rotate/mirror/etc. works, but for testing
purposes, the current version (needs z49 changes only) is attached.

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

z49.c.gz
Description: GNU Zip compressed data