Re: Stack trashing with 2.5-NTLM?

Note: gdb cannot always (or quite seldom actually) fully track local
variables when compiled with -O2, so it might simply be that gdb does
not know the correct register or whatever where r currently is located.

/Henrik

Chemolli Francesco (USI) wrote:
>
> 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
Received on Wed Apr 04 2001 - 13:13:21 MDT