Looking at the stack, it crashes while creating a nameref, presumably for eqf. That suggests that the error is during the assignment to m. I would put calls around the parser to get an earlier failure.
If the failure is totally repeatable you can turn off the audits until jt->parsercalls gets near the error. hhr On Fri, Nov 17, 2023, 9:21 AM Raul Miller <rauldmil...@gmail.com> wrote: > The test suite under MEMAUDIT=0x2 is quite slow, even with QKTEST=:1. > And, sometimes windows will reboot itself and/or lose configuration > information. (I'm running debian 12.2 under windows wsl2.) > > But, I've found a line that fails the test suite on line 264 of g300. > Unfortunately, it has not been reproducible running g300 in isolation > under the default j64/jconsole instance. > > But, for now at least, I have a live session with the stack at the > point where the fault was detected, in case further inspection of > details might be useful here: > > (-"+/ .* eqf -/ .*) m=: %/1+?2 4 4$200x > trap : file ../../../../jsrc/m.c line 553 > > Thread 1 "jconsole" received signal SIGILL, Illegal instruction. > 0x00007ffff293b2ae in auditsimdelete (jt=0x7ffff1438200, > w=0x555556496d40) at ../../../../jsrc/m.c:553 > 553 if((delct = > ((AFLAG(w)+=AFAUDITUC)>>AFAUDITUCX))>ACUC(w))SEGFAULT; // hang if > too many deletes > > (gdb) where > #0 0x00007ffff293b2ae in auditsimdelete (jt=0x7ffff1438200, > w=0x555556496d40) at ../../../../jsrc/m.c:553 > #1 0x00007ffff293b6da in auditsimdelete (jt=0x7ffff1438200, > w=0x5555556da4c0) at ../../../../jsrc/m.c:570 > #2 0x00007ffff293ab14 in audittstack (jt=0x7ffff1438200) at > ../../../../jsrc/m.c:648 > #3 0x00007ffff2970041 in jtnamerefacv (jt=0x7ffff1438200, > a=0x5555564b8840, val=0x5555564c31d8) > at ../../../../jsrc/sc.c:355 > #4 0x00007ffff2944f9e in jtparsea (jt=0x7ffff1438200, > queue=0x55555598b838, nwds=23) at ../../../../jsrc/p.c:618 > #5 0x00007ffff2944314 in jtparse (jt=0x7ffff1438200, > w=0x55555598b7c0) at ../../../../jsrc/p.c:290 > #6 0x00007ffff2952b35 in jtimmex (jt=0x7ffff1438200, > w=0x55555598b7c0) at ../../../../jsrc/px.c:54 > #7 0x00007ffff2952c23 in jtimmea (jt=0x7ffff1438200, > w=0x55555598b7c0) at ../../../../jsrc/px.c:63 > #8 0x00007ffff2fb7517 in jtline (jt=0x7ffff1438200, w=0x555555b5d300, > si=159, ce=3 '\003', tso=1 '\001') > at ../../../../jsrc/xs.c:87 > #9 0x00007ffff2fb7b2d in jtlinf (jt=0x7ffff1438200, a=0x7ffff3a25e80 > <Bmark>, w=0x7fffffffb6c0, ce=3 '\003', > tso=1 '\001') at ../../../../jsrc/xs.c:142 > #10 0x00007ffff2fb83e6 in jtscy1 (jt=0x7ffff1438200, w=0x7fffffffb6c0, > self=0x5555558f9a00) > at ../../../../jsrc/xs.c:174 > #11 0x00007ffff28a8306 in jtrank1ex0 (jt=0x7ffff1438200, > w=0x555555aaf5c0, fs=0x5555558f9a00, > f1=0x7ffff2fb8290 <jtscy1>) at ../../../../jsrc/cr.c:192 > #12 0x00007ffff2fb8366 in jtscy1 (jt=0x7ffff1438200, w=0x555555aaf5c0, > self=0x5555558f9a00) > at ../../../../jsrc/xs.c:174 > #13 0x00007ffff296e556 in jtunquote (jt=0x7ffff1438200, > a=0x555555aaf5c0, w=0x5555558f9a00, self=0x5555558f3f00) > at ../../../../jsrc/sc.c:163 > #14 0x00007ffff283fbc3 in jtcasei12 (jt=0x7ffff1438200, > a=0x555555aaf5c0, w=0x555555aaf5c0, self=0x5555558f3d80) > at ../../../../jsrc/cg.c:345 > #15 0x00007ffff27f26a6 in on1cell (jt=0x7ffff1438200, > w=0x555555aaf5c1, self=0x5555558f3a80) > at ../../../../jsrc/ca.c:102 > #16 0x00007ffff27f2853 in on1cell (jt=0x7ffff1438200, w=0x0, > self=0x5555558f3a00) at ../../../../jsrc/ca.c:102 > #17 0x00007ffff296e556 in jtunquote (jt=0x7ffff1438200, > a=0x555555aaf5c0, w=0x5555558f3a00, self=0x5555555c9140) > at ../../../../jsrc/sc.c:163 > #18 0x00007ffff2945a3f in jtparsea (jt=0x7ffff1438200, > queue=0x5555555c7688, nwds=5) at ../../../../jsrc/p.c:751 > #19 0x00007ffff2944314 in jtparse (jt=0x7ffff1438200, > w=0x5555555c7640) at ../../../../jsrc/p.c:290 > #20 0x00007ffff2952b35 in jtimmex (jt=0x7ffff1438200, > w=0x5555558d2300) at ../../../../jsrc/px.c:54 > #21 0x00007ffff291d409 in jtimmexexecct (jt=0x7ffff1438200, > x=0x5555558d2300) at ../../../../jsrc/io.c:382 > #22 0x00007ffff291d21a in runiep (jjt=0x7ffff1438000, > jt=0x7ffff1438200, old=0x5555555a1008, savcallstack=0) > at ../../../../jsrc/io.c:395 > ... > > I have some more experiments I could try (for example, maybe setting > LC_ALL=fr_FR.UTF-8 would do something that triggers this error -- it's > not a locale that my machine recognizes...) But I'm running blind here > and some informed guessing would be better than my current guesswork. > > Thanks, > > -- > Raul > > > > On Mon, Nov 13, 2023 at 8:13 AM Henry Rich <henryhr...@gmail.com> wrote: > > > > I think you are saying that you have a double free: you have an argument > > that contains deadbeef, indicating that it has been freed. I don't > > think you need to write any code. > > > > You need to turn on 0x2 in MEMAUDIT, to engage tstack auditing. Remember > > that the tstack contains death warrants for blocks that have been > > allocated. The double free happens when there is an erroneous free that > > frees the block while the death warrant is still active; the application > > of the death warrant is the double free, but the error happened earlier. > > > > tstack auditing goes through the tstack, counting the number of death > > warrants for each block. If that number exceeds the usecount of the > > block, an erroneopus free has occurred and the audit segfaults. You can > > add calls to the tstack auditor in your code to narrow down the source > > of the error. > > > > If you still want to see all allocations, they go through jtgaf() in m.c. > > > > hhr > > > > On 11/13/2023 12:51 AM, Raul Miller wrote: > > > The problem i'm experiencing is that I'm adding two extended precision > > > numbers and I get a segfault because one has a corrupted memory > > > address. I turn on MEMAUDIT=0x1d and I get an ARGCHK failure because > > > one of the arguments is has low bits set in flags (and is 0xdeadbeef). > > > > > > So, I have a memory address which was allocated and I need to "go back > > > in time" to see what's happening with that memory address. (If it > > > changes in response to my code update, it presumably would only change > > > once - not when I only change the numeric value that I'm searching > > > for.) > > > > > > In other words, I want to create a routine deadcheck() which reports > > > when it's being called with an address which matches the failing > > > address, along with a counter. Once I have this information, I can > > > perform a run where I stop when I reach a certain count of the > > > appearance of that memory address (or maybe every time, if the total > > > count is low), and inspect the stack to see what's going on there. I > > > am hoping that with this information I can zero in on what is being > > > corrupted, and when. > > > > > > But, to do this, I need to run deadcheck every time memory gets > > > allocated / handed to J as a new empty array. (I also put in a > > > deadcheck in the gmp memory allocator, of course.) > > > > > > So, ... I'm wondering where I can check all memory allocations. > > > > > > -- > > > Raul > > > > > > On Sun, Nov 12, 2023 at 8:40 PM Henry Rich <henryhr...@gmail.com> > wrote: > > >> I'm not sure I understand what you want to know. The tpop stack holds > > >> the death warrants for recently allocated blocks. > > >> > > >> hhr > > >> > > >> On 11/12/2023 6:56 PM, Raul Miller wrote: > > >>> If I want to test all the addresses of "newly allocated pointers to > > >>> memory" from m.c, where should I do that? > > >>> > > >>> 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 > > > > ---------------------------------------------------------------------- > > 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
