转发: Want some support
-邮件原件- 发件人: dingyoudong [mailto:dingyoud...@cn.fujitsu.com] 发送时间: 2009年12月8日 16:49 收件人: 'i...@squid-cache.org' 主题: Want some support HI: Pls check those information, would you help me to get a solution? Pls refer to these, Thank a lot: From: sq...@mail.ojipaper.cn To: dingyoud...@cn.fujitsu.com Subject: The Squid Cache (version 2.6.STABLE6-CVS-AVP) died. You've encountered a fatal error in the Squid Cache version 2.6.STABLE6-CVS-AVP. If a core file was created (possibly in the swap directory), please execute 'gdb squid core' or 'dbx squid core', then type 'where', and report the trace back to squid-b...@squid-cache.org. Thanks! # no core # The cache.log is below: 2009/12/08 08:25:26| icapLineLength: warning lineLen (2) len (1) 2009/12/08 08:25:26| icapParseChunkSize: WARNING in mid-line, ret 0 2009/12/08 08:25:41| Unsupported status '400' from ICAP server 2009/12/08 08:26:33| Unsupported status '400' from ICAP server 2009/12/08 08:26:52| icapLineLength: warning lineLen (2) len (1) 2009/12/08 08:26:52| icapParseChunkSize: WARNING in mid-line, ret 0 2009/12/08 08:27:16| Unsupported status '400' from ICAP server 2009/12/08 08:27:32| WARNING: failed to unpack meta data 2009/12/08 08:27:32| Unsupported status '400' from ICAP server 2009/12/08 08:27:32| WARNING: failed to unpack meta data 2009/12/08 08:27:37| icapLineLength: warning lineLen (3) len (2) 2009/12/08 08:27:37| icapParseChunkSize: WARNING in mid-line, ret 0 2009/12/08 08:27:51| Unsupported status '400' from ICAP server 2009/12/08 08:28:40| Unsupported status '400' from ICAP server 2009/12/08 08:29:28| Unsupported status '400' from ICAP server 2009/12/08 08:29:37| icapLineLength: warning lineLen (2) len (1) 2009/12/08 08:29:37| icapParseChunkSize: WARNING in mid-line, ret 0 2009/12/08 08:29:42| icapLineLength: warning lineLen (2) len (1) 2009/12/08 08:29:42| icapParseChunkSize: WARNING in mid-line, ret 0 2009/12/08 08:29:53| Unsupported status '400' from ICAP server 2009/12/08 08:30:19| Unsupported status '400' from ICAP server 2009/12/08 08:31:01| icapLineLength: warning lineLen (2) len (1) 2009/12/08 08:31:01| icapParseChunkSize: WARNING in mid-line, ret 0 2009/12/08 08:31:15| Unsupported status '400' from ICAP server 2009/12/08 08:31:21| Unsupported status '400' from ICAP server 2009/12/08 08:31:39| icapLineLength: warning lineLen (2) len (1) 2009/12/08 08:31:39| icapParseChunkSize: WARNING in mid-line, ret 0 2009/12/08 08:32:01| icapLineLength: warning lineLen (2) len (1) 2009/12/08 08:32:01| icapParseChunkSize: WARNING in mid-line, ret 0 2009/12/08 08:32:02| icapLineLength: warning lineLen (2) len (1) http_port 8080 hierarchy_stoplist cgi-bin ? acl QUERY urlpath_regex cgi-bin \? cache deny QUERY cache_mgr ding acl apache rep_header Server ^Apache #broken_vary_encoding allow apache access_log /usr/squid/var/logs/access.log squid refresh_pattern ^ftp: 144020% 10080 refresh_pattern ^gopher:14400% 1440 refresh_pattern . 0 20% 4320 acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl to_localhost dst 127.0.0.0/8 acl localhost src 10.64.16.0/255.255.240.0 acl localhost src 10.64.128.0/255.255.240.0 acl localhost src 10.64.32.0/255.255.224.0 acl localhost src 10.64.144.0/255.255.240.0 acl SSL_ports port 443 563 acl Safe_ports port 1-65535 acl CONNECT method CONNECT #never_direct deny all #always_direct allow all cache_dir ufs /squidcache 1 128 256 cache_mem 64 MB cache_swap_low 80 cache_swap_high 90 maximum_object_size 1024000 KB minimum_object_size 0 KB maximum_object_size_in_memory 8 KB no_cache deny QUERY http_access allow all http_access allow manager localhost http_access allow localhost http_access allow Safe_ports http_access allow localhost http_reply_access allow all icp_access allow all forwarded_for off log_icp_queries off buffered_logs on header_access Via deny all header_access X-Forwarded-For deny all header_access Cache-Control deny all logfile_rotate 5 coredump_dir /usr/squid/var/cache redirect_rewrites_host_header off icap_enable on icap_send_client_ip on # Added by Kaspersky Anti-Virus installer icap_service is_kav_resp respmod_precache 0 icap://127.0.0.1:1344/av/respmod icap_service is_kav_req reqmod_precache 0 icap://127.0.0.1:1344/av/reqmod icap_class ic_kav is_kav_req is_kav_resp icap_access ic_kav allow all cache_effective_user squid cache_effective_group squid delay_pools 1 delay_class 1 1 delay_parameters 1 -1/-1 cache_mgr dingyoud...@cn.fujitsu.com --=_NextPart_000_000D_01CA77EE.0DDB2D30 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN HTML HEAD META HTTP-EQUIV=3DContent-Type CONTENT=3Dtext/html; = charset=3Dus-ascii META
Re: 转发: Want some support
dingyoudong wrote: -邮件原件- 发件人: dingyoudong [mailto:dingyoud...@cn.fujitsu.com] 发送时间: 2009年12月8日 16:49 收件人: 'i...@squid-cache.org' 主题: Want some support HI: Pls check those information, would you help me to get a solution? Pls refer to these, Thank a lot: From: sq...@mail.ojipaper.cn To: dingyoud...@cn.fujitsu.com Subject: The Squid Cache (version 2.6.STABLE6-CVS-AVP) died. You've encountered a fatal error in the Squid Cache version 2.6.STABLE6-CVS-AVP. If a core file was created (possibly in the swap directory), please execute 'gdb squid core' or 'dbx squid core', then type 'where', and report the trace back to squid-b...@squid-cache.org. Thanks! # no core # The cache.log is below: 2009/12/08 08:25:26| icapLineLength: warning lineLen (2) len (1) 2009/12/08 08:25:26| icapParseChunkSize: WARNING in mid-line, ret 0 2009/12/08 08:25:41| Unsupported status '400' from ICAP server 2009/12/08 08:26:33| Unsupported status '400' from ICAP server Please use Squid 3.0 or later. The ICAP patches on Squid-2 are known to be very broken and are not officially supported since 3.0 was released stable for production use. Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20 Current Beta Squid 3.1.0.15
'gprof squid squid.gmon' only shows the initial configuration functions
I've built squid with the -pg flag and run it in the no-daemon mode (-N flag), without the initial fork(). I send it the SIGTERM signal which is caught by the signal handler, to flag graceful exit from main(). I expect to see meaningful squid.gmon, but 'gprof squid squid.gmon' only shows the initial configuration functions: called/total parents index %timeself descendents called+selfname index called/total children spontaneous [1] 63.40.170.00 _mcount [1] --- 0.000.10 1/1 _start [3] [2] 36.00.000.10 1 main [2] 0.000.10 1/1 parseConfigFile [4] ... --- spontaneous [3] 36.00.000.10 _start [3] 0.000.10 1/1 main [2] --- 0.000.10 1/1 main [2] [4] 36.00.000.10 1 parseConfigFile [4] 0.000.09 1/1 readConfigLines [5] 0.000.00 169/6413parse_line [6] ... System info: # uname -m -r -s FreeBSD 6.2-RELEASE-p9 amd64 # gcc -v Using built-in specs. Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 There are 7 fork()s for unlinkd/diskd helpers. Can these fork()s affect profiling info?
Re: Assertion in clientProcessBody
debug_options 33,2 results in: 2009/12/08 18:34:24| clientTryParseRequest: 0xdbeac0: FD 54: request body is 226 bytes in size 2009/12/08 18:34:24| The request GET [URL] is ALLOWED, because it matched '[acl]' 2009/12/08 18:34:24| clientCacheHit: refreshCheckHTTPStale returned -2 2009/12/08 18:34:24| clientCacheHit: stale-while-revalidate needs revalidation 2009/12/08 18:34:24| The reply for GET [URL] is ALLOWED, because it matched 'all' 2009/12/08 18:34:24| clientProcessBody: start fd=54 body_size=226 in.offset=226 cb=0x42eac0 req=(nil) 2009/12/08 18:34:24| clientProcessBody: end fd=54 size=226 body_size=0 in.offset=0 cb=0x42eac0 req=(nil) 2009/12/08 18:34:24| clientReadBody: start fd=54 body_size=0 in.offset=0 cb=0x45602f req=0xdbeac0 2009/12/08 18:34:24| clientProcessBody: start fd=54 body_size=0 in.offset=0 cb=0x45602f req=0xdbeac0 2009/12/08 18:34:24| The request GET [URL2] is ALLOWED, because it matched '[acl]' 2009/12/08 18:34:24| clientCacheHit: refreshCheckHTTPStale returned -2 2009/12/08 18:34:24| clientCacheHit: stale-while-revalidate needs revalidation 2009/12/08 18:34:24| The reply for GET [URL2] is ALLOWED, because it matched 'all' 2009/12/08 18:34:24| clientProcessBody: start fd=54 body_size=0 in.offset=420 cb=0x45602f req=0xdbeac0 2009/12/08 18:34:24| assertion failed: client_side.c:4445: conn-body.size_left 0 On 08/12/2009, at 5:23 PM, Mark Nottingham wrote: #2 0x00435749 in xassert (msg=0x4c02f1 conn-body.size_left 0, file=0x4bd9d0 client_side.c, line=4445) at debug.c:505 No locals. #3 0x0042ece1 in clientProcessBody (conn=0xc270c8) at client_side.c:4445 valid = 1 size = 0 buf = 0x81024f0 cbdata = (void *) 0x51703568 callback = (CBCB *) 0x45602f httpRequestBodyHandler request = (request_t *) 0x1ed3c80 #4 0x0042e853 in clientReadRequest (fd=37, data=0xc270c8) at client_side.c:4331 conn = (ConnStateData *) 0xc270c8 size = 422 F = (fde *) 0x2a957a68b8 len = 4095 ret = 0 #5 0x004346ad in comm_call_handlers (fd=37, read_event=1, write_event=0) at comm_generic.c:264 hdl = (PF *) 0x42e4e3 clientReadRequest hdl_data = (void *) 0xc270c8 do_read = 1 F = (fde *) 0x2a957a68b8 do_incoming = 1 #6 0x00434f3e in do_comm_select (msec=579) at comm_epoll.c:195 i = 0 num = 1 saved_errno = 11 #7 0x00434a55 in comm_select (msec=579) at comm_generic.c:390 last_timeout = 1260237328.0927789 rc = 0 start = 1260237328.5134871 #8 0x0046722c in main (argc=3, argv=0x7fbfffd798) at main.c:862 errcount = 0 On 08/12/2009, at 4:12 PM, Henrik Nordstrom wrote: tis 2009-12-08 klockan 13:34 +1100 skrev Mark Nottingham: Any thoughts here? Should this really be =, or should clientProcessBody never get a 0 size_left? It's done when size_left == 0, and no further body processing handler shoud be active on this request at that time. Any data on the connection at this time is either surplus data (HTTP violation) or a pipelined request waiting to be processed. If you look a little further down (about one screen) in clientProcessBody you'll also see that the body reader gets unregistered when processing reaches 0. But it would not be harmful to make clientProcessBody gracefully handle size_left == 0 I guess. A backtrace would be nice. Regards Henrik -- Mark Nottingham m...@yahoo-inc.com -- Mark Nottingham m...@yahoo-inc.com
SMB help needed
During the helper conversion to C++ I found that the various SMB lookup helpers had a lot of duplicate code as each included the entire smbval/smblib validation library as inline code. I've managed to consolidate just about all of the files into a shared library but there remains two problems: 1) the MSNT helper which performs proper domain-controller lookups make use of the available domain and encryption details. And a few other things the smb_lm helper did not. unidiff patch attached if anyone who knows what SMB is meant to do can give their opinion on the best way to merge these bits. 2) I'm unable to actually test the merged code still works. A lot of castings and void* types have been removed in the upgrade so I want to be really sure before it gets merged in. Is anyone able to pull down the lp:~yadi/squid/helpers branch and give the new basic_msnt_auth and ntlm_smb_lm_auth helpers a whirl? NP: there is a fair bit of header cleanups still to be done/ongoing which will require another test later, but I'd like some confidence that the basic code still works. Amos --- valid.cc 2009-12-09 01:08:18.0 +1300 +++ valid.cc.MSNT 2009-12-07 17:49:38.0 +1300 @@ -16,22 +13,24 @@ #include string.h #endif +#include smblib-priv.h +#include smblib.h +#include valid.h + int Valid_User(char *username, char *password, char *server, char *backup, char *domain) { -int pass_is_precrypted_p = 0; -char const *supportedDialects[] = { -/* PC NETWORK PROGRAM 1.0, */ -/* MICROSOFT NETWORKS 1.03, */ -/* MICROSOFT NETWORKS 3.0, */ -LANMAN1.0, -LM1.2X002, -Samba, -/* NT LM 0.12, */ -/* NT LANMAN 1.0, */ -NULL -}; -SMB_Handle_Type con; +const char *SMB_Prots[] = {PC NETWORK PROGRAM 1.0, + MICROSOFT NETWORKS 1.03, + MICROSOFT NETWORKS 3.0, + LANMAN1.0, + LM1.2X002, + Samba, + NT LM 0.12, + NT LANMAN 1.0, + NULL + }; +void *con; SMB_Init(); con = SMB_Connect_Server(NULL, server, domain); @@ -41,16 +40,11 @@ return (NTV_SERVER_ERROR); } } -if (SMB_Negotiate(con, supportedDialects) 0) { /* An error */ -SMB_Discon(con, 0); -return (NTV_PROTOCOL_ERROR); -} -/* Test for a server in share level mode do not authenticate against it */ -if (con-Security == 0) { +if (SMB_Negotiate(con, SMB_Prots) 0) { /* An error */ SMB_Discon(con, 0); return (NTV_PROTOCOL_ERROR); } -if (SMB_Logon_Server(con, username, password, domain, pass_is_precrypted_p) 0) { +if (SMB_Logon_Server(con, username, password) 0) { SMB_Discon(con, 0); return (NTV_LOGON_ERROR); } --- smblib.cc 2009-12-07 16:43:51.0 +1300 +++ smblib.cc.MSNT 2009-12-07 17:21:00.0 +1300 @@ -145,17 +145,7 @@ strcpy(con-LMType, SMBLIB_DEFAULT_LMTYPE); con-first_tree = con-last_tree = NULL; -/* ugh. This is horribly broken. */ -/* SMB_Get_My_Name(con - myname, sizeof(con - myname)); */ -/* hacked by Kinkie */ -if (-1 == gethostname(con-myname, sizeof(con-myname))) { -strcpy(con-myname, unknown); -} else { -if (NULL != (address = strchr(con-myname, '.'))) { -*address = '\0'; /* truncate at first '.' */ -} -} - +SMB_Get_My_Name(con-myname, sizeof(con-myname)); con-port = 0; /* No port selected */ @@ -324,7 +314,7 @@ int SMB_Logon_Server(SMB_Handle_Type Con_Handle, char *UserName, - char *PassWord, char *UserDomain, int precrypted) + char *PassWord) { struct RFCNB_Pkt *pkt; int param_len, pkt_len, pass_len; @@ -340,24 +330,22 @@ return (SMBlibE_BAD); } -if (precrypted) { +strcpy(pword, PassWord); +#ifdef PAM_SMB_ENC_PASS +if (Con_Handle-encrypt_passwords) { pass_len = 24; -memcpy(pword, PassWord, 24); -} else { -strcpy(pword, PassWord); -if (Con_Handle-encrypt_passwords) { -pass_len = 24; -SMBencrypt((uchar *) PassWord, (uchar *) Con_Handle-Encrypt_Key, (uchar *) pword); -} else -pass_len = strlen(pword); -} +SMBencrypt((uchar *) PassWord, (uchar *) Con_Handle-Encrypt_Key, (uchar *) pword); +} else +#endif +pass_len = strlen(pword); + /* Now build the correct structure */ if (Con_Handle-protocol SMB_P_NT1) { param_len = strlen(UserName) + 1 + pass_len + 1 + -strlen(UserDomain) + 1 + +strlen(Con_Handle-PDomain) + 1 +