[squid-users] Squid BUG: assurance failed: tok.skip(WellKnownUrlPathPrefix())

Thu Sep 14 10:40:52 UTC 2023

Wow - Alex now even the old cachemgr.cgi works :-] client v4.6 also works

But - could someone (or you) clarify the next one for me? I've read some questions about the "new" cachemgr.cgi and the MGR_INDEX template. Without this file the only output which the cmgr.cgi produces is "Internal Error: Missing Template MGR_INDEX". But if I put content from MGR_INDEX from https://github.com/yadij/cachemgr.js/ it gives me (Apache/2.4.38 Debian)

[Wed Sep 13 05:57:57.902368 2023] [cgid:error] [pid 22501:tid 140478824113920] [client 192.168.xx.xx:24201] End of script output before headers: cachemgr.cgi, referer: http://squid_IP/cgi-bin/cachemgr.cgi
assertion failed: MemBuf.cc:211: "sz >= 0"

(line 211 is in the function MemBuf::Append)

But if I put only some text in the MGR_INDEX file (something like <p>Test bla bla</p>) it renders 

Cache Manager menu for localhost:
Test bla bla

Generated Thu, 14 Sep 2023 10:16:11 GMT, by cachemgr.cgi/6.3-20230903-ra9c06aa6a at proxy

Have not found any info about substitutions (eq. like in the ERR files) or something. I thought if there is no MGR_INDEX file cachemgr.cgi should work as the old one - and MGR_INDEX is only used while I need some customization or my own design/functions.

Besides that I have found out that every time I shutdown squid with start-stop-daemon it coredumps. Frankly - I do not have capacity to go through these.

ep 14 11:55:13 proxy squid[23984]: Squid Parent: squid-4 process 23990 exited due to signal 6 with status 0
Sep 14 11:55:15 proxy squid[23984]: Squid Parent: squid-1 process 23993 exited due to signal 6 with status 0
Sep 14 11:55:47 proxy squid[23984]: Squid Parent: squid-3 process 23991 exited due to signal 6 with status 0
Sep 14 11:55:48 proxy squid[23984]: Squid Parent: squid-2 process 23992 exited due to signal 6 with status 0
Sep 14 11:56:18 proxy systemd-coredump[3679]: Process 23990 (squid) of user 13 dumped core.#012#012Stack trace of thread 23990:
#012#0  0x00007f35c21ab8eb __GI_raise (libc.so.6)
#012#1  0x00007f35c2196535 __GI_abort (libc.so.6)
#012#2  0x000055c7eca80694 xassert (squid)
#012#3  0x000055c7ecb23c7c _ZN5Store4RootEv (squid)
#012#4  0x000055c7ec8805af _ZN10StoreEntry16destroyMemObjectEv (squid)
#012#5  0x000055c7ec8811f6 _Z17destroyStoreEntryPv (squid)
#012#6  0x000055c7ecb2d3eb hashFreeItems (squid)
#012#7  0x000055c7ecb1fe4a _ZN5Store10ControllerD1Ev (squid)
#012#8  0x000055c7ecb1fec9 _ZN5Store10ControllerD0Ev (squid)
#012#9  0x00007f35c21adebc __run_exit_handlers (libc.so.6)
#012#10 0x00007f35c21adfea __GI_exit (libc.so.6)
#012#11 0x000055c7ec847ce3 SquidShutdown (squid)
#012#12 0x000055c7ec6f0cf1 SquidMainSafe (squid)
#012#13 0x00007f35c219809b __libc_start_main (libc.so.6)
#012#14 0x000055c7ec6fa71a _start (squid)
Sep 14 11:56:18 proxy systemd-coredump[3681]: Process 23993 (squid) of user 13 dumped core.
#012#012Stack trace of thread 23993:
#012#0  0x00007f169c64c8eb __GI_raise (libc.so.6)#012#1  0x00007f169c637535 __GI_abort (libc.so.6)
#012#2  0x0000557ee57ab694 xassert (squid)
#012#3  0x0000557ee584ec7c _ZN5Store4RootEv (squid)
#012#4  0x0000557ee55ab5af _ZN10StoreEntry16destroyMemObjectEv (squid)
#012#5  0x0000557ee55ac1f6 _Z17destroyStoreEntryPv (squid)
#012#6  0x0000557ee58583eb hashFreeItems (squid)
#012#7  0x0000557ee584ae4a _ZN5Store10ControllerD1Ev (squid)
#012#8  0x0000557ee584aec9 _ZN5Store10ControllerD0Ev (squid)
#012#9  0x00007f169c64eebc __run_exit_handlers (libc.so.6)
#012#10 0x00007f169c64efea __GI_exit (libc.so.6)#012#11 0x0000557ee5572ce3 SquidShutdown (squid)
#012#12 0x0000557ee541bcf1 SquidMainSafe (squid)
#012#13 0x00007f169c63909b __libc_start_main (libc.so.6)#012#14 0x0000557ee542571a _start (squid)
Sep 14 11:56:18 proxy systemd[1]: systemd-coredump at 60-3678-0.service: Succeeded.
Sep 14 11:56:18 proxy systemd[1]: systemd-coredump at 61-3680-0.service: Succeeded.
Sep 14 11:56:42 proxy systemd-coredump[3688]: Process 23992 (squid) of user 13 dumped core.
#012#012Stack trace of thread 23992:#012
#0  0x00007fa6a64568eb __GI_raise (libc.so.6
#012#1  0x00007fa6a6441535 __GI_abort (libc.so.6)
#012#2  0x000055bde67df694 xassert (squid)
#012#3  0x000055bde6882c7c _ZN5Store4RootEv (squid)
#012#4  0x000055bde65df5af _ZN10StoreEntry16destroyMemObjectEv (squid)
#012#5  0x000055bde65e01f6 _Z17destroyStoreEntryPv (squid)
#012#6  0x000055bde688c3eb hashFreeItems (squid)
#012#7  0x000055bde687ee4a _ZN5Store10ControllerD1Ev (squid)
#012#8  0x000055bde687eec9 _ZN5Store10ControllerD0Ev (squid)
#012#9  0x00007fa6a6458ebc __run_exit_handlers (libc.so.6)
#012#10 0x00007fa6a6458fea __GI_exit (libc.so.6)
#012#11 0x000055bde65a6ce3 SquidShutdown (squid)
#012#12 0x000055bde644fcf1 SquidMainSafe (squid)
#012#13 0x00007fa6a644309b __libc_start_main (libc.so.6)
#012#14 0x000055bde645971a _start (squid)
Sep 14 11:56:43 proxy systemd[1]: systemd-coredump at 62-3685-0.service: Succeeded.
Sep 14 11:56:56 proxy systemd-coredump[3677]: Process 23991 (squid) of user 13 dumped core.
#012#012Stack trace of thread 23991:
#012#0  0x00007fbe358dd8eb __GI_raise (libc.so.6)
#012#1  0x00007fbe358c8535 __GI_abort (libc.so.6)
#012#2  0x00005642b5ae8694 xassert (squid)
#012#3  0x00005642b5b8bc7c _ZN5Store4RootEv (squid)
#012#4  0x00005642b58e85af _ZN10StoreEntry16destroyMemObjectEv (squid)
#012#5  0x00005642b58e91f6 _Z17destroyStoreEntryPv (squid)
#012#6  0x00005642b5b953eb hashFreeItems (squid)
#012#7  0x00005642b5b87e4a _ZN5Store10ControllerD1Ev (squid)
#012#8  0x00005642b5b87ec9 _ZN5Store10ControllerD0Ev (squid)
#012#9  0x00007fbe358dfebc __run_exit_handlers (libc.so.6)
#012#10 0x00007fbe358dffea __GI_exit (libc.so.6)
#012#11 0x00005642b58afce3 SquidShutdown (squid)
#012#12 0x00005642b5758cf1 SquidMainSafe (squid)
#012#13 0x00007fbe358ca09b __libc_start_main (libc.so.6)
#012#14 0x00005642b576271a _start (squid)
Sep 14 11:56:57 proxy systemd[1]: systemd-coredump at 59-3676-0.service: Succeeded.

Maybe something with my (rock) storage closing?
THX
LL

-----Původní zpráva-----
Od: squid-users za uživatele Alex Rousskov
Odesláno: st 13.9.2023 20:53
Komu: squid-users at lists.squid-cache.org
Předmět: Re: [squid-users] Squid BUG: assurance failed: tok.skip(WellKnownUrlPathPrefix())

On 2023-09-12 15:50, Loučanský Lukáš wrote:

> 2023/09/12 19:12:03 kid4| ERROR: Squid BUG: assurance failed: 
> tok.skip(WellKnownUrlPathPrefix())

> Request:
> GET cache_object://squid_ip/info HTTP/1.0
> Host: squid_ip
> User-Agent: squidclient/4.6
> Accept: */*
> Connection: close

Thank you for sharing this detail. I can now reproduce this problem.

You are suffering from a bug in Squid v6.3 commit 6695897 (which was 
incorrectly attributed to me). Until that bug is addressed, cache 
manager requests using the deprecated cache_object scheme (e.g., those 
emitted by older squidclients) will trigger the above 
WellKnownUrlPathPrefix assertion in Squid v6.3.

I have attached a patch that fixes this v6.3 bug in my tests.

> Sending HTTP request ...
> done.
> HTTP/1.1 404 Not Found
> Server: squid
> Mime-Version: 1.0
> Date: Tue, 12 Sep 2023 19:09:41 GMT
> Content-Type: text/html;charset=utf-8
> Content-Length: 13057
> X-Squid-Error: ERR_INVALID_URL 0
> Cache-Status: proxy;detail=no-cache
> Via: 1.1 proxy (squid)
> Connection: close
> 
> This is obviously calling for url cache_object://squid_ip/info which I 
> think is obsolete. Now I went with the new squidclient:
> 
> ./squidclient -h squid_ip -p squid_port -vv mgr:info
> 
> Request:
> GET http://squid_ip:squid_port/squid-internal-mgr/info HTTP/1.0
> Host: 10.50.1.5:3127
> User-Agent: squidclient/6.3
> Accept: */*
> Connection: close

> But it seems squid is then trying to open it's 
> visible_hostname:squid_port/squid-internal-mgr/ and due my DNS setting 
> it is its WAN IP - so it's connecting to its outside IP with its outside 
> IP which is not in the http_access manager allow list (now it is and the 
> newer squidclient works).

You are in Squid Bug 5283 territory here:
https://bugs.squid-cache.org/show_bug.cgi?id=5283

In a Linux test environment, I can work around those "outside IP" 
problems by adding "-l 127.0.0.1" option to squidclient, forcing 
squidclient to connect to Squid from the loopback address. IIRC, that 
"-l" trick does not work in environments that do not support 
from-localhost connections to "outside IPs" on the same box (e.g., Windows).

HTH,

Alex.

> -----Původní zpráva-----
> Od: squid-users za uživatele Alex Rousskov
> Odesláno: út 12.9.2023 19:28
> Komu: squid-users at lists.squid-cache.org
> Předmět: Re: [squid-users] Squid BUG: assurance failed: 
> tok.skip(WellKnownUrlPathPrefix())
> 
> On 2023-09-12 13:06, Loučanský Lukáš wrote:
>  > Is this anyhow interesting?
> 
> Not really, IMO -- the problem happens earlier. I can confirm that you
> are running v6.3-based code. Let's call that progress :-).
> 
> Can you share the a _pointer_ to a compressed ALL,9 cache.log file while
> reproducing the problem using a single transaction?
> 
> https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction <https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction>
> 
> Alex.
> 
>  >
>  > 2023/09/12 18:47:04.267 kid4| 24,8| SBuf.cc(30) SBuf: SBuf15514952 
> created
>  > 2023/09/12 18:47:04.267 kid4| 24,8| SBuf.cc(30) SBuf: SBuf15514953 
> created
>  > 2023/09/12 18:47:04.267 kid4| 24,8| SBuf.cc(30) SBuf: SBuf15514954 
> created
>  > 2023/09/12 18:47:04.267 kid4| 24,7| SBuf.cc(85) assign: assigning
>  > SBuf15514952 from SBuf15514912
>  > 2023/09/12 18:47:04.267 kid4| 24,8| SBuf.cc(38) SBuf: SBuf15514955
>  > created from id SBuf15514915
>  > 2023/09/12 18:47:04.267 kid4| 24,8| SBuf.cc(445) startsWith:
>  > SBuf15514955 startsWith SBuf125812, caseSensitive: 0
>  > 2023/09/12 18:47:04.267 kid4| 24,8| SBuf.cc(447) startsWith: no, too 
> short
>  > 2023/09/12 18:47:04.267 kid4| 24,8| Tokenizer.cc(185) skip: no match,
>  > not skipping '/squid-internal-mgr/'
>  > 2023/09/12 18:47:04 kid4| ERROR: Squid BUG: assurance failed:
>  > tok.skip(WellKnownUrlPathPrefix())
>  > 2023/09/12 18:47:04.268 kid4| 24,8| SBuf.cc(70) ~SBuf: SBuf15514955
>  > destructed
>  >
>  >
>  > BTW debug 24,9 makes pretty big log files... :-)
>  >
>  > L
>  >
> 
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20230914/1b9bed63/attachment-0001.htm>