Thomas Meier wrote:
Hello
just compiled Squid 3.1, but the same error (assertion failed +
tunnelReadServer )
The first reload now after only 3 Minutes.
What kind of "trace" do you need ??
That fast cycle of happenings is kind of good news.
It means you can run squid inside gdb and get better info.
Christos already passed you links to the FAQ where its detailed how to
do that.
What would be good is a 'bt' from the frame below the assert.
And also if running in gdb a 'print getType()' and 'print *this'
Amos
Here the cache.log:
2008/12/17 09:55:22| tunnelReadServer: FD 154: read failure: (0) Error 0
2008/12/17 09:55:23| tunnelReadServer: FD 188: read failure: (0) Error 0
2008/12/17 09:55:23| tunnelReadServer: FD 270: read failure: (0) Error 0
2008/12/17 09:55:25| tunnelReadServer: FD 243: read failure: (0) Error 0
2008/12/17 09:55:26| tunnelReadServer: FD 253: read failure: (0) Error 0
2008/12/17 09:56:13| ctx: enter level 0:
'http://213.203.200.72/chatin?SID=72525605&ID=17198778&OUT=/wer'
2008/12/17 09:56:13| HttpMsg.cc(175) parse: first line of HTTP message
is invalid
2008/12/17 09:57:16| ctx: exit level 0
2008/12/17 09:57:16| assertion failed: store_client.cc:430:
"STORE_DISK_CLIENT == getType()"
2008/12/17 09:57:19| Starting Squid Cache version 3.1.0.3 for
sparc-sun-solaris2.9...
And now with Squid3.1 an new ERROR:
2008/12/17 10:07:24| tunnelReadServer: FD 255: read failure: (0) Error 0
2008/12/17 10:08:01| tunnelReadServer: FD 261: read failure: (0) Error 0
2008/12/17 10:08:01| assertion failed: fqdncache.cc:642:
"!addr.IsAnyAddr() && !addr.IsNoAddr()"
2008/12/17 10:08:05| Starting Squid Cache version 3.1.0.3 for
sparc-sun-solaris2.9...
The "tunnelReadServer" Error overall shows an intervall ~ 3-4 Minutes..
2008/12/17 10:01:08| tunnelReadServer: FD 28: read failure: (0) Error 0
2008/12/17 10:01:08| tunnelReadServer: FD 387: read failure: (0) Error 0
2008/12/17 10:01:12| tunnelReadServer: FD 144: read failure: (0) Error 0
2008/12/17 10:01:12| tunnelReadServer: FD 175: read failure: (0) Error 0
2008/12/17 10:01:13| tunnelReadServer: FD 91: read failure: (0) Error 0
2008/12/17 10:01:13| tunnelReadServer: FD 44: read failure: (0) Error 0
2008/12/17 10:01:14| tunnelReadServer: FD 435: read failure: (0) Error 0
2008/12/17 10:01:14| tunnelReadServer: FD 387: read failure: (0) Error 0
2008/12/17 10:01:14| tunnelReadServer: FD 146: read failure: (0) Error 0
2008/12/17 10:01:15| tunnelReadServer: FD 47: read failure: (0) Error 0
2008/12/17 10:01:16| tunnelReadServer: FD 314: read failure: (0) Error 0
2008/12/17 10:01:21| tunnelReadServer: FD 303: read failure: (0) Error 0
2008/12/17 10:01:22| tunnelReadServer: FD 35: read failure: (0) Error 0
2008/12/17 10:01:23| tunnelReadServer: FD 163: read failure: (0) Error 0
2008/12/17 10:01:23| tunnelReadServer: FD 44: read failure: (0) Error 0
2008/12/17 10:01:24| tunnelReadServer: FD 44: read failure: (0) Error 0
2008/12/17 10:01:24| tunnelReadServer: FD 114: read failure: (0) Error 0
2008/12/17 10:01:25| tunnelReadServer: FD 259: read failure: (0) Error 0
2008/12/17 10:01:26| tunnelReadServer: FD 406: read failure: (0) Error 0
2008/12/17 10:01:27| tunnelReadServer: FD 324: read failure: (0) Error 0
2008/12/17 10:01:28| tunnelReadServer: FD 144: read failure: (0) Error 0
2008/12/17 10:04:01| tunnelReadServer: FD 330: read failure: (0) Error 0
2008/12/17 10:04:03| tunnelReadServer: FD 326: read failure: (0) Error 0
2008/12/17 10:04:05| tunnelReadServer: FD 64: read failure: (0) Error 0
2008/12/17 10:04:06| tunnelReadServer: FD 64: read failure: (0) Error 0
2008/12/17 10:04:06| tunnelReadServer: FD 190: read failure: (0) Error 0
2008/12/17 10:04:14| tunnelReadServer: FD 247: read failure: (0) Error 0
2008/12/17 10:04:15| tunnelReadServer: FD 221: read failure: (0) Error 0
2008/12/17 10:04:15| tunnelReadServer: FD 322: read failure: (0) Error 0
2008/12/17 10:04:15| tunnelReadServer: FD 98: read failure: (0) Error 0
2008/12/17 10:04:16| tunnelReadServer: FD 13: read failure: (0) Error 0
2008/12/17 10:04:16| tunnelReadServer: FD 55: read failure: (0) Error 0
2008/12/17 10:04:16| tunnelReadServer: FD 190: read failure: (0) Error 0
2008/12/17 10:04:17| tunnelReadServer: FD 255: read failure: (0) Error 0
2008/12/17 10:04:18| tunnelReadServer: FD 384: read failure: (0) Error 0
2008/12/17 10:04:18| tunnelReadServer: FD 255: read failure: (0) Error 0
2008/12/17 10:04:19| tunnelReadServer: FD 247: read failure: (0) Error 0
2008/12/17 10:04:19| tunnelReadServer: FD 264: read failure: (0) Error 0
2008/12/17 10:04:25| tunnelReadServer: FD 413: read failure: (0) Error 0
2008/12/17 10:04:25| tunnelReadServer: FD 79: read failure: (0) Error 0
2008/12/17 10:04:25| tunnelReadServer: FD 221: read failure: (0) Error 0
2008/12/17 10:04:27| tunnelReadServer: FD 298: read failure: (0) Error 0
2008/12/17 10:04:28| tunnelReadServer: FD 350: read failure: (0) Error 0
2008/12/17 10:04:30| tunnelReadServer: FD 117: read failure: (0) Error 0
2008/12/17 10:04:31| tunnelReadServer: FD 257: read failure: (0) Error 0
Amos Jeffries schrieb:
Thomas Meier wrote:
Hello,
another Problem...
after ~ 30 - 60 Min. Squid3.0 S4 writes this in the cache.log
.
.
2008/12/16 14:17:07| tunnelReadServer: FD 284: read failure: (0) Error 0
2008/12/16 14:17:08| tunnelReadServer: FD 280: read failure: (0) Error 0
2008/12/16 14:17:13| tunnelReadServer: FD 239: read failure: (0) Error 0
2008/12/16 14:21:05| assertion failed: store_client.cc:430:
"STORE_DISK_CLIENT == getType()"
2008/12/16 14:21:08| Starting Squid Cache version 3.0.STABLE4 for
sparc-sun-solaris2.9...
Squid reloads, and works fine for the next 30-60 Minutes.
Squid3S9 tested, but ists the same.
Something like that was processed here, but not solved:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2155
Yes those appear to be the same bug.
We still need a solid trace of stack with debug symbols when the error
occurs and a confirmation that its still relevant against the much
improved 3.1 code.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE5 or 3.0.STABLE10
Current Beta Squid 3.1.0.3 or 3.0.STABLE11-RC1
