Since MEMAUDIT has been working after you added gmp, I don't think it
needs changing.
Threading doesn't look at internals of blocks. The only change to
allocation is (1) each thread has its own allocator; (2) if a thread
frees a block that was allocated in another thread, it passes the block
back to the original allocating thread for freeing.
Each A block has a 16-bit field reserved for use by m.c. This field
indicates the size of the block (as a power of 2) and, for blocks of
size <= 1024, the offset of the block in the original 16384-byte
allocation. This is used only for garbage collection.
IIUC you have changed the XNUM code to allocate blocks using GA rather
than malloc, but you have a crash. You are wondering whether a block is
being freed more than once. You have put in an audit to verify that all
X blocks are allocated by GA not gmp, and you are finding that in
12345x
one is not.
Doesn't it appear that the value 12345x is being allocated through gmp,
or perhaps an internal block in jtthorn*()?
hhr
On 11/11/2023 10:21 AM, Raul Miller wrote:
Ok, you are correct. I had missed that, hmm...
I guess a next question is whether any of the other memory audit
mechanisms need to be moved to be before or after that line 1485 test
(or whether they need to be changed to account for the fact that the
memory they are inspecting might not be J allocated memory).
But I guess I also need to be thinking about other possible causes of
the error I'm trying to track down. (For example: is it possible that
something in the threading code assumes something about
representations for extended integers? This seems incredibly unlikely,
but gmp memory might not be following the rules for allocation sizes,
and I'm not sure I understand that aspect of the implementation.)
Anyways, it's clear that I need to do more work on tracking down this issue.
Thanks,
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
