The value 12345x is being allocated through gmp. The c char sequence 12345\0" is also being allocated through gmp.
But this is no longer an interesting example, because - as you pointed out - it's being freed properly. So that brings me back to the new problem introduced by having the result of 1x+1x being allocated using J's memory allocator. It's this failure mode that potentially implicates something in the MEMAUDIT infrastructure. That said, this is also slow going - both reviewing the code and running tests to exhibit the failure mode take quite a lot of time. So, at this point, I'm trying to focus on issues which might reduce some of that time. Thanks, -- Raul On Sat, Nov 11, 2023 at 11:16 AM Henry Rich <henryhr...@gmail.com> wrote: > > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
