[squid-users] Squid BUG: assurance failed: tok.skip(WellKnownUrlPathPrefix())
Alex Rousskov
rousskov at measurement-factory.com
Thu Sep 14 21:55:11 UTC 2023
On 2023-09-14 06:40, Loučanský Lukáš wrote:
> 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.
Sorry, I cannot help with cachemgr.cgi without heroic efforts. IMHO,
Squid Project should remove cachemgr.cgi feature instead of supporting
it. I hope that somebody else will help you with it.
> Besides that I have found out that every time I shutdown squid with
> start-stop-daemon it coredumps.
> user 13 dumped core.#012#012Stack trace of thread 23990:
> #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)
Yes, "TheRoot" assertions after shutdown (during "automatic" at-exit
cleanup) is a known bug. Recent shutdown improvements make this
particular assertion more likely, unfortunately. More difficult work is
needed to fully solve the underlying problem. We will solve it.
Meanwhile, please try the attached patch with an untested workaround.
Does it help in your environment?
Thank you,
Alex.
> -----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://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
> <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> <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
> <https://lists.squid-cache.org/listinfo/squid-users>
>
>
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users
-------------- next part --------------
commit 381f130
Author: Alex Rousskov <rousskov at measurement-factory.com>
Date: Thu Sep 14 17:50:10 2023 -0400
Work around "TheRoot" assertions after shutdown
Deleting complex objects like Stores and StoreEntries after main() is
wrong. We probably want to delete (safely, before the end of main())
those StoreEntries that are no longer in use. We do want to delete
Stores before main() is over (but still leave TheRoot in a minimally
functioning state instead of deleted!). This hack does none of that.
diff --git a/src/store/Controller.cc b/src/store/Controller.cc
index 66147a6..caa9757 100644
--- a/src/store/Controller.cc
+++ b/src/store/Controller.cc
@@ -47,10 +47,12 @@ Store::Controller::~Controller()
delete transients;
delete swapDir;
if (store_table) {
- hashFreeItems(store_table, destroyStoreEntry);
- hashFreeMemory(store_table);
+ // XXX: Cannot destroy MemObjects that still have locks on entries in
+ // stores deleted above!
+ // hashFreeItems(store_table, destroyStoreEntry);
+ // hashFreeMemory(store_table);
store_table = nullptr;
}
}
More information about the squid-users
mailing list