SIGSEGV bug in 2.6.0.15

[brazi...@gmail.com]

After almost three weeks of running on 2.6.0.15, Firan hit a SIGSEGV:

2006.1124:014711 FiranMUX SIG/CATCH: Caught signal SIGSEGV
2006.1124:014711 FiranMUX BUG/INFO : Command: 'think setq(6,
create(Storage Object, 10))'

Somewhat before this, @list allocations gave:

Buffer Stats Size InUse Total Allocs Lost
Lbufs 16000 24 397 108980528769 0
Sbufs 64 0 180 35158658 0
Mbufs 400 19 20 50017 0
Bools 16 0 9 857051148 0
Descs 400 75 78 14520 0
Qentries 232 7 1890 47800069 0
Pcaches 24 77 77 280054 0
Lbufref 8 12 26 12757418 0
Regref 16 21 93 2416689929 0

There's no indication of leaks of lbufs, lbufrefs, or regrefs. The
setq() suggests the reference-counting may be the place to look, but
the three weeks suggest that the bug is subtle.

I've re-studied the applicable code without finding anything. There are
places where it might be appropriately paranoid to set a freed pointer
to NULL, but the structure containing the pointer is freed immediately
after.

My only hope of finding the bug at the moment is to run Firan for three
weeks under the debugger and wait, or hope that a sharp pair of eyes
can see something in the code that I can't.

[brazi...@gmail.com]

Also ran the following for several hours on a separate box without a
repro:

&TRIG-FOO me=think
iter(lnum(1000),setq(0,repeat(a,rand(1,3)))[setq(1,repeat(a,rand(1,3)))][setq(2,repeat(a,rand(1,3)))][null(regmatch(cookies=30,(.+)=(\[0-9\]*),0
1 2))]);@trig me/trig-foo

[Robby Griffin]

Well, I haven't spotted the actual bug yet, but I'm pretty sure that's
a demonstration of how not to use regmatch(). After the mux parser gets
done with it, the actual regexp seen by the regexp parser is:

#-1 FUNCTION () NOT FOUND

I'll note that the following returns 1, but only if the square brackets
are included:

think [regmatch(#-1 FUNCTION %bNOT FOUND,(.+)=(\[0-9\]*))]

I suspect you meant to use %(.+%)=%(%[0-9%]*%) for the regexp argument,
but, eww.

I just said this elsewhere, and I'll repeat it here:

Please, for the sake of sanity, don't try to put an actual regexp
directly in the regmatch() call. You'll need ridiculous amounts of
escaping for commonly used regexp characters like brackets, parens, and
backslashes, and that will make it hard to tell what it does and
whether it's right. Instead, store the regexp in a separate attribute
and avoid passing it
through the mux parser:

@va me=(.+)=([0-9]*)

&trig-foo me= ... regmatch(cookies=30,%va,0 1 2) ...

--Alierak