Maybe it is somewhere in the auth handler in squid.
Markus
"Klaus Walter" wrote in message
news:086bae224bf3fd9ccf686c85e2e54...@myway.de...
Hi Markus,
yes, you are right.
But why is squid using more and more memory until it dies because there
is no more memory available at the server.
When
Hi Markus,
yes, you are right.
But why is squid using more and more memory until it dies because there
is no more memory available at the server.
When I run the same squid 3.2.1 with the same configuration but with
basic
authentication only the memory usage is constant and it is running
stable
Hi Klaus,
If I did not make an error it is the following line:
service_principal = xstrdup(optarg);
and it is not part of a loop and should not create a leak. It gets freed
when the helper exits.
Markus
"Klaus Walter" wrote in message
news:1c3bf830b7785fbff9f25e2486d5a...@myw
Hi Markus,
here the output of valgrind with source code lines form the
negotiate_kerberos_auth
helper that comes with squid 3.2.1:
==6124== 14 bytes in 1 blocks are definitely lost in loss record 1 of 1
==6124==at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==6124==by 0x403384: xmalloc
Hi Markus,
thank you very much for your help.
I changed MAX_AUTHTOKEN_LEN to 64 KB and recompiled squid.
After that there are no longer any hanging negotiate_kerberos_auth
helper processes.
This problem is fixed now.
For the memory problem I tried to debug with valgrind and I hope
I did it i
Hi Klaus
If the token is to big then you need to update the source here:
src/auth/UserRequest.h:#define MAX_AUTHTOKEN_LEN 32768
I am curious about the memory leak as I run it through valgrind ( I
noticed some underlying Kerberos library leaks, but no leaks in the helper
itself). Can y
