Re: squid-2.5 and IRIX

This is what I refer to (using ElecticFence):

Program received signal SIGSEGV, Segmentation fault.
memPoolInUseCount (pool=0x40880fb0)
    at /home/henrik/SRC/squid/SQUIDCACHE/commit-2.5/src/MemPool.c:300
300 return pool->meter.inuse.level;
(gdb) where
#0 memPoolInUseCount (pool=0x40880fb0)
    at /home/henrik/SRC/squid/SQUIDCACHE/commit-2.5/src/MemPool.c:300
#1 0x08087049 in memCleanModule ()
    at /home/henrik/SRC/squid/SQUIDCACHE/commit-2.5/src/MemPool.c:121
#2 0x080866ad in SquidShutdown (unused=0x0)
    at /home/henrik/SRC/squid/SQUIDCACHE/commit-2.5/src/main.c:995
#3 0x0806c263 in eventRun ()
    at /home/henrik/SRC/squid/SQUIDCACHE/commit-2.5/src/event.c:147
#4 0x08086033 in main (argc=2, argv=0xbffff994)
    at /home/henrik/SRC/squid/SQUIDCACHE/commit-2.5/src/main.c:722
#5 0x401d96e7 in __libc_start_main (main=0x8085c74 <main>, argc=2,
    ubp_av=0xbffff994, init=0x804aa10 <_init>, fini=0x80c2640
<_fini>,
    rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff98c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) p *pool
$1 = {label = 0x80efb6a "NTLM Helper State data", obj_size = 16,
pstack = {
    capacity = 16, count = 1, items = 0x0}, meter = {alloc = {level =
1,
      hwater_level = 1, hwater_stamp = 1015766798}, inuse = {level =
0,
      hwater_level = 1, hwater_stamp = 1015766798}, idle = {level =
1,
      hwater_level = 1, hwater_stamp = 1015766818}, saved = {count =
0,
      bytes = 0, gb = 0}, total = {count = 1, bytes = 1, gb = 0}}}

I'll take a quick peek to see if I can pinpoint the culpit here.
Shouldn't be too hard.

Regards
Henrik

On Sunday 10 March 2002 11:59, Robert Collins wrote:
> > -----Original Message-----
> > From: Henrik Nordstrom [mailto:hno@squid-cache.org]
> > Sent: Sunday, March 10, 2002 9:18 PM
> > To: Robert Collins; squid-dev@squid-cache.org
> > Subject: Re: squid-2.5 and IRIX
> >
> >
> > IIRC malloc debugging saw more than only asserts.. See earlier
> > thread..
> >
> > Regards
> > Henrik
>
> There was a memleak in the ntlm code that you plugged (thank you),
> and IIRC one in the auth code that we plugged. There is also a
> serious issue with connections that get hung open if the close call
> doesn't fire properly (because they refer to ntlm user details).
> I've no time frame on that as yet, I really need to sit down with
> Kinkie and get some log traces from his test environment to
> determine whats going on - or do a line by line review of the
> connection handling state in 2.5, which for several reasons is
> unlikely just now.
>
> Rob
Received on Sun Mar 10 2002 - 06:38:44 MST