Re: [9front] APE stddef.h ptrdiff_t should it be 8? [Tcl memory problem]

[Trevor Higgins <plan9fullfrontal@qs.co.nz>]

On 03/09/2020 05:06 PM, ori@eigenstate.org wrote:
>
> I'd really like to know what went wrong with tcl, and how
> to reproduce it.
>
Ok, but you need to understand the tcl code to follow along.
Compile with amd64 and run.  It generates a TclPanic due to a pointer 
passed to the StackFree routine not matching the value expected.
This is caused by the macro OFFSET (inline func actually)  in 
TclExecute.c. In tcl8.6 the macro has been renamed wordskip as this is a 
more appropriate name.

At first glance it looks like the macro computes the number of bytes 
needed to align the address to 16 bytes. But it does not. It should 
return either 1 or 2 but it does so only when the address passed in is 
XXXX0 or XXXX8. When an address of XXXC is used, the macro returns 0. 
Any other low order address bit combinations will also be barf.

The zero value causes the Macro MEMSTART to return the wrong address to 
the application. The offset is needed for space to store a marker that 
is used by the StackFree routine. The application writes all over the 
marker and thus the panic.

The second problem is two fold. In TclExcuteByteCodeObj (or therabouts), 
the code keeps track of how much of the stack memory is in use with two 
values that are ptrdiff_t. Except they are pointers to ptrdiff_t.
When the said routine returns the memory back to the stack allocator it 
uses ptr+1 (for some unknown reason). Because ptrdiff* is int* it adds 
four to the address. It needs to add 8 for the code to work properly. 
Why the +1 I do not know, it looks like a "off by 1 hack" but in all 
other cases, the Value returned to StackFree is the same value given by 
StackAlloc.

The second problem is that memory accesses occur outside the allocated 
memory. Without passing properly aligned memory addresses to this 
routine it cannot be investigated further and may go away once the above 
is corrected.

Why tcl needs  the memory to be 128bit aligned I have not looked into. 
But I suspect it is the way the byte code engine converts word to byte 
addresses. In any case, in running some code with some patches in to 
address the above , I still get memory corruptions and 'suicide traps' 
due to the code accessing memory that is not within the application. IE 
the high word of the pointer has become corrupted.

The machine I am using is second hand and I have not used it much for 
anything else, other than installing Linux on one partition , so it 
could be memory problems with this machine. I verified most of the above 
with QEMU but in qemu with the OFFSET fix applied there are no other 
random memory panics. I suspect it just depends on the value of the 
pointers passed from malloc and that under QEMU I am not seeing the ones 
that cause the problem.


-- 
We need another plan