Set MEMAUDIT and 6!:5 to see where the free chain is corrupted. hhr
On Thu, Nov 2, 2023, 3:32 PM Raul Miller <rauldmil...@gmail.com> wrote: > This is turning out to be more difficult than I had anticipated. > > I've modified jtxplus to use mpn_add (and mpn_sub and a macro > workalike for the inlined mpn_neg, which in turn uses mpn_com - > necessary because the mpn_ family of routines works on unsigned limb > sequences). And, it *mostly* works. > > However, when running script/testga.sh, I encounter a double free problem. > > My current best guess is that somewhere I'm relying on a container > test (XNUM/RAT) instead of relying on the ISGMP() test. But I looked > through m.c and I'm not seeing anything there that looks plausible. > > I did notice that the frgmp() macro is not referenced anywhere, and I > used the corresponding fr() macro in my implementation rather than > mf() - but if that's an issue, I need a better understanding of this > part of the internal api. > > So... anyways... before I dig this hole too deep, I figure I should > ask for advice on how to proceed. > > Thoughts? > > Thanks, > > -- > Raul > > > > On Wed, Oct 25, 2023 at 3:12 AM Henry Rich <henryhr...@gmail.com> wrote: > > > > OK, I see now. The implementation using low-level GMP would be more > > parallel with Roger's original version, right? > > > > That would end up being simpler than having reserve memory, as well as > > stabler. > > > > Since you currently mark blocks that are to be freed by GMP, you could > > make this change piecemeal, right? When you rewrite addition to use the > > low-level routines, you mark the blocks allocated by addition as J not > > GMP, and everything else follows automatically. > > > > Tbat's a great idea. > > > > hhr > > > > On 10/24/2023 8:34 PM, Raul Miller wrote: > > > libzahl is not thread safe, and even if it was, it's not clear to me > > > that it adequately supports enough architectures. > > > > > > Meanwhile, libgmp's problems are addressable. I just have to use a > > > different part of its API. > > > > > > (Also, on windows, we're using mpir rather than libgmp.) > > > > > > (J currently uses parts of the libgmp high level API, which performs > > > memory allocations within the libgmp library routines, using callbacks > > > whose implementation I supply. But it also exposes the low level > > > routines used to build those high level routines, and those low level > > > routines do not perform memory allocation, which means that we can > > > manage the memory outside of the API.) > > > > > > ((The problem with libgmp's high level API is that if a memory > > > allocation fails, it exits the program. So we came up with a > > > workaround which reserves a memory pool, and limits arguments to > > > certain routines, so successful memory allocations will succeed even > > > under low memory conditions. That's not ideal, but it has been "good > > > enough, so far". But libgmp supports another approach. It's a little > > > more work, but not an excessive amount of work.)) > > > > > > I hope this makes sense, > > > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
