Stack trashing with 2.5-NTLM?

I'm doing some pre-production tests with squid-2.5-NTLM. I have it
set up as main proxy for a few hundred users (maybe as many as
a thousand), and I'm catching crashes as they happen for debugging.
Currently it works fine (exceptionally well, actually) for a few
hundred thousand requests.
After that, weird things happen, such as this one (Segmentation Violation):

(gdb) bt
#0 0x400a7d21 in __sigprocmask (how=6, set=0xf, oset=0x0)
    at ../sysdeps/unix/sysv/linux/sigprocmask.c:61
#1 0x400a90b8 in abort () at ../sysdeps/generic/abort.c:85
#2 0x808ebf9 in death () at ../../squid-ntlm/src/tools.c:301
#3 0x400a7c48 in __sigaction (sig=0, act=0x8234130, oact=0x9253738)
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:126
#4 0x804d1dc in aclMatchAcl (ae=0x8213d08, checklist=0x9253738)
    at ../../squid-ntlm/src/acl.c:1556
#5 0x804d54c in aclMatchAclList (list=0x8234130, checklist=0x9253738)
    at ../../squid-ntlm/src/acl.c:1705
#6 0x804d6a1 in aclCheck (checklist=0x9253738)
    at ../../squid-ntlm/src/acl.c:1749
#7 0x804da0d in aclLookupProxyAuthDone (data=0x9253738, result=0x0)
    at ../../squid-ntlm/src/acl.c:1936
#8 0x8098b13 in authenticateNTLMStart (auth_user_request=0xb659ca0,
    handler=0x804d994 <aclLookupProxyAuthDone>, data=0x9253738)
    at ../../../../squid-ntlm/src/auth/ntlm/auth_ntlm.c:730
#9 0x8097edc in authenticateNTLMHandleplaceholder (data=0x9160528,
    lastserver=0x8242358, reply=0x0)
    at ../../../../squid-ntlm/src/auth/ntlm/auth_ntlm.c:398
#10 0x806d9d3 in helperStatefulDispatch (srv=0x8242358, r=0x82e4928)
    at ../../squid-ntlm/src/helper.c:993
#11 0x806db14 in helperStatefulKickQueue (hlp=0x8238290)
    at ../../squid-ntlm/src/helper.c:1047
#12 0x806d486 in helperStatefulHandleRead (fd=8, data=0x8242358)
    at ../../squid-ntlm/src/helper.c:793
#13 0x805f81d in comm_poll (msec=48) at
../../squid-ntlm/src/comm_select.c:434
#14 0x8078948 in main (argc=2, argv=0xbffff4d4)
    at ../../squid-ntlm/src/main.c:712

The code line at fault is (in acl.c):

1556 esc_buf = xstrdup(urlCanonical(r));

r is NULL:

(gdb) p r
$7 = (request_t *) 0x0

This has me and robert completely puzzled: if r is NULL, it should segfault
at the
fourth line of urlCanonical, where it does

if (request->canonical)

But it doesn't.

This would seem to point at stack trashing somewhere, but WHERE? And how
would
be best check for it, or avoid it?

r!=NULL, it's checked at line 1459 (the acl being matched is an url_regex,
so if falls
within the scope of the check.

Also:

(gdb) p ae
$13 = (acl *) 0x0

But ae _cannot_ be NULL, or we'd have had the segfault at the beginning of
the function, at
   swutch (ae->type)
In fact, ae should be (in this case) 0x8213d08: in fact

(gdb) p *(acl *)0x8213d08
$2 = {name = "http", '\000' <repeats 27 times>, type = ACL_URL_REGEX,
  data = 0x8213e70, cfgline = 0x8213470 "acl http url_regex ^http://",
  next = 0x8213eb0}

I (and Robert) am looking for some insights as to WHERE to look, and how to
debug and
correct this.

Setup is Linux 6.2, egcs-2.91.66, compile optimizations -O2
-fno-strength-reduce. The
problem also showed up with -O.

Thanks.

-- 
	/kinkie