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
