Hi Amos,
Using the latest trunk version squid crashes when I use negotiate wrapper
and Kerberos. It did not do so before.
(gdb) where
#0 0xffffe424 in __kernel_vsyscall ()
#1 0xb71e77ff in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb71e9140 in abort () at abort.c:92
#3 0x0812f9e8 in xassert (msg=0x82bf30c "request->clientConnectionManager
== http_conn",
file=0x82bee62 "client_side_request.cc", line=836) at debug.cc:567
#4 0x08124fc3 in clientCheckPinning (this=0x84cb7f8) at
client_side_request.cc:836
#5 clientInterpretRequestHeaders (this=0x84cb7f8) at
client_side_request.cc:945
#6 ClientHttpRequest::doCallouts (this=0x84cb7f8) at
client_side_request.cc:1335
#7 0x08126548 in ClientRequestContext::clientAccessCheckDone
(this=0x84d0860, answer=1) at client_side_request.cc:659
#8 0x08126823 in ClientRequestContext::clientAccessCheck2 (this=0x84d0860)
at client_side_request.cc:555
#9 0x081246c3 in ClientHttpRequest::doCallouts (this=0x84cb7f8) at
client_side_request.cc:1328
#10 0x08126548 in ClientRequestContext::clientAccessCheckDone
(this=0x84d0860, answer=1) at client_side_request.cc:659
#11 0x08227825 in ACLChecklist::checkCallback (this=0x84d0a08,
answer=ACCESS_ALLOWED) at Checklist.cc:194
#12 0x08208c8f in ACLFilledChecklist::checkCallback (this=0x84d0a08,
answer=ACCESS_ALLOWED) at FilledChecklist.cc:32
#13 0x0822845b in ACLChecklist::check (this=0x84d0a08) at Checklist.cc:105
#14 0x081f2c32 in ProxyAuthLookup::LookupDone (data=0x84d0a08, result=0x0)
at AclProxyAuth.cc:173
#15 0x0821d075 in AuthNegotiateUserRequest::HandleReply (data=0x848c3b0,
lastserver=0x848d870,
reply=<value optimized out>) at UserRequest.cc:399
#16 0x0816baac in helperStatefulHandleRead (fd=10,
buf=0x8496970 "AF
oYGgMIGdoAMKAQChCwYJKoZIgvcSAQICooGIBIGFYIGCBgkqhkiG9xIBAgICAG9zMHGgAwIBBaEDAgEPomUwY6ADAgEXolwEWq1L/YTAWybqyPUgTY241MqX/0T0hOW8P0hkAceWJ+9eziWLZiEtX70GvOB1kxvSDZYAbM0cAsw/rd4tcdz8ULyl1jeUsjqey0+vs"...,
len=253,
flag=COMM_OK, xerrno=0, data=0x848d870) at helper.cc:959
#17 0x0823a625 in CommIoCbPtrFun::dial (this=0x848d904) at CommCalls.cc:183
#18 0x08228e4b in AsyncCall::make (this=0x848d8e8) at AsyncCall.cc:34
#19 0x0822c3e7 in AsyncCallQueue::fireNext (this=0x848d268) at
AsyncCallQueue.cc:54
#20 0x0822c560 in AsyncCallQueue::fire (this=0x848d268) at
AsyncCallQueue.cc:40
#21 0x08146cf5 in EventLoop::runOnce (this=0xbfb417d4) at EventLoop.cc:131
#22 0x08146df0 in EventLoop::run (this=0xbfb417d4) at EventLoop.cc:95
#23 0x0819cc00 in SquidMain (argc=4, argv=0xbfb41904) at main.cc:1496
#24 0x0819d9bc in SquidMainSafe (argc=4, argv=0xbfb41904) at main.cc:1229
---Type <return> to continue, or q <return> to quit---
#25 main (argc=4, argv=0xbfb41904) at main.cc:1221
"Amos Jeffries" <[email protected]> wrote in message
news:[email protected]...
On 11/02/11 02:38, Amos Jeffries wrote:
Since 1xx handing went in HttpRequest has had two links to the one
ConnStateData managing its client connection.
* Rename the 1xx link to clientConnectionManager (since it is not
actually the connection, but the manager object controlling the FD usage
and stats.
* Convert the pinning code to using the permanent
clientConnectionManager link instead of a temporary pinned_connection
link.
This moves all connection pinning state fully into the ConnStateData
manager objects scope.
Side changes that appear to be buggy code previously:
* do not alter pinning state at the point where the pinned connection
is about to start being used. Changes are only relevant at the point of
pinning or unpinning.
* unpin operation now closes the Server FD if still open. Previously
there was the possibility that some code paths would leave server FD
open and pconn it. (especially since the above mentioned state
alteration cleared the "pinned" flag).
Applied to trunk. revno 11419
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.7 and 3.1.12.1
