Re: [squid-users] Squid Cache Issues migration from 5.8 to 6.6
I forgot to mention my certificates I use on squid was generated from this method openssl req -x509 -new -nodes -key myProxykey.key -sha256 -days 365 -out myProxyca.pem Sent from my iPhone > On Jul 3, 2024, at 10:56, Jonathan Lee wrote: > > Hello fellow Squid users does anyone know how to fix this issue? > > Squid - Cache Logs > Date-Time Message > 31.12.1969 16:00:00 > 03.07.2024 10:54:34 kick abandoning conn7853 local=192.168.1.1:3128 > remote=192.168.1.5:49710 FD 89 flags=1 > 31.12.1969 16:00:00 > 03.07.2024 10:54:29 kick abandoning conn7844 local=192.168.1.1:3128 > remote=192.168.1.5:49702 FD 81 flags=1 > 03.07.2024 10:54:09 ERROR: failure while accepting a TLS connection on > conn7648 local=192.168.1.1:3128 remote=192.168.1.5:49672 FD 44 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 03.07.2024 10:54:09 ERROR: failure while accepting a TLS connection on > conn7647 local=192.168.1.1:3128 remote=192.168.1.5:49670 FD 43 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 03.07.2024 10:54:09 ERROR: failure while accepting a TLS connection on > conn7646 local=192.168.1.1:3128 remote=192.168.1.5:49668 FD 34 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 03.07.2024 10:53:04 ERROR: failure while accepting a TLS connection on > conn7367 local=192.168.1.1:3128 remote=192.168.1.5:49627 FD 22 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 03.07.2024 10:52:47 ERROR: failure while accepting a TLS connection on > conn7345 local=192.168.1.1:3128 remote=192.168.1.5:49618 FD 31 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 03.07.2024 10:52:38 ERROR: failure while accepting a TLS connection on > conn7340 local=192.168.1.1:3128 remote=192.168.1.5:49616 FD 45 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1 > 03.07.2024 10:52:34 ERROR: failure while accepting a TLS connection on > conn7316 local=192.168.1.1:3128 remote=192.168.1.5:49609 FD 45 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 31.12.1969 16:00:00 > 03.07.2024 10:51:55 WARNING: Error Pages Missing Language: en-us > 31.12.1969 16:00:00 > 03.07.2024 10:51:55 ERROR: loading file > 9;/usr/local/etc/squid/errors/en-us/ERR_ZERO_SIZE_OBJECT': (2) No such file > or directory > 03.07.2024 10:51:44 ERROR: failure while accepting a TLS connection on > conn7102 local=192.168.1.1:3128 remote=192.168.1.5:49574 FD 34 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 03.07.2024 10:51:28 ERROR: failure while accepting a TLS connection on > conn7071 local=192.168.1.1:3128 remote=192.168.1.5:49568 FD 92 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 03.07.2024 10:50:29 ERROR: failure while accepting a TLS connection on > conn6944 local=192.168.1.1:3128 remote=192.168.1.5:49534 FD 101 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1 > 03.07.2024 10:49:54 ERROR: failure while accepting a TLS connection on > conn6866 local=192.168.1.1:3128 remote=192.168.1.5:49519 FD 31 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 03.07.2024 10:49:38 ERROR: failure while accepting a TLS connection on > conn6809 local=192.168.1.1:3128 remote=192.168.1.5:49503 FD 31 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 31.12.1969 16:00:00 > 03.07.2024 10:49:32 ERROR: system call failure while accepting a TLS > connection on conn6794 local=192.168.1.1:3128 remote=192.168.1.5:49496 FD 19 > flags=1: SQUID_TLS_ERR_ACCEPT+TLS_IO_ERR=5+errno=54 > 03.07.2024 10:49:24 ERROR: failure while accepting a TLS connection on > conn6776 local=192.168.1.1:3128 remote=192.168.1.5:49481 FD 137 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1 > 03.07.2024 10:48:49 ERROR: failure while accepting a TLS connection on > conn6440 local=192.168.1.1:3128 remote=192.168.1.5:49424 FD 16 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1 > 03.07.2024 10:48:49 ERROR: failure while accepting a TLS connection on > conn6445 local=192.168.1.1:3128 remote=192.168.1.5:49426 FD 34 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 03.07.2024 10:48:22 ERROR: failure while accepting a TLS connection on > conn6035 local=192.168.1.1:3128 remote=192.168.1.5:49355 FD 226 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1 > 03.07.2024 10:48:09 ERROR: failure while accepting a TLS connection on > conn5887 local=192.168.1.1:3128 remote=192.168.1.5:49318 FD 33 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 03.07.2024 10:48:09 ERROR: failure while accepting a TLS connection on > conn5875 local=192.168.1.1:3128 remote=192.168.1.5:49312 FD 216 flags=1: > SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 > 03.07.2024 10:48:09 ERROR: failure while accepting a TLS connection on > conn5876 local=192.168.1.1:3128 remote=192.168.1.5:49314
[squid-users] Squid Cache Issues migration from 5.8 to 6.6
Hello fellow Squid users does anyone know how to fix this issue? Squid - Cache Logs Date-Time Message 31.12.1969 16:00:00 03.07.2024 10:54:34 kick abandoning conn7853 local=192.168.1.1:3128 remote=192.168.1.5:49710 FD 89 flags=1 31.12.1969 16:00:00 03.07.2024 10:54:29 kick abandoning conn7844 local=192.168.1.1:3128 remote=192.168.1.5:49702 FD 81 flags=1 03.07.2024 10:54:09 ERROR: failure while accepting a TLS connection on conn7648 local=192.168.1.1:3128 remote=192.168.1.5:49672 FD 44 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 03.07.2024 10:54:09 ERROR: failure while accepting a TLS connection on conn7647 local=192.168.1.1:3128 remote=192.168.1.5:49670 FD 43 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 03.07.2024 10:54:09 ERROR: failure while accepting a TLS connection on conn7646 local=192.168.1.1:3128 remote=192.168.1.5:49668 FD 34 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 03.07.2024 10:53:04 ERROR: failure while accepting a TLS connection on conn7367 local=192.168.1.1:3128 remote=192.168.1.5:49627 FD 22 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 03.07.2024 10:52:47 ERROR: failure while accepting a TLS connection on conn7345 local=192.168.1.1:3128 remote=192.168.1.5:49618 FD 31 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 03.07.2024 10:52:38 ERROR: failure while accepting a TLS connection on conn7340 local=192.168.1.1:3128 remote=192.168.1.5:49616 FD 45 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1 03.07.2024 10:52:34 ERROR: failure while accepting a TLS connection on conn7316 local=192.168.1.1:3128 remote=192.168.1.5:49609 FD 45 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 31.12.1969 16:00:00 03.07.2024 10:51:55 WARNING: Error Pages Missing Language: en-us 31.12.1969 16:00:00 03.07.2024 10:51:55 ERROR: loading file 9;/usr/local/etc/squid/errors/en-us/ERR_ZERO_SIZE_OBJECT': (2) No such file or directory 03.07.2024 10:51:44 ERROR: failure while accepting a TLS connection on conn7102 local=192.168.1.1:3128 remote=192.168.1.5:49574 FD 34 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 03.07.2024 10:51:28 ERROR: failure while accepting a TLS connection on conn7071 local=192.168.1.1:3128 remote=192.168.1.5:49568 FD 92 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 03.07.2024 10:50:29 ERROR: failure while accepting a TLS connection on conn6944 local=192.168.1.1:3128 remote=192.168.1.5:49534 FD 101 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1 03.07.2024 10:49:54 ERROR: failure while accepting a TLS connection on conn6866 local=192.168.1.1:3128 remote=192.168.1.5:49519 FD 31 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 03.07.2024 10:49:38 ERROR: failure while accepting a TLS connection on conn6809 local=192.168.1.1:3128 remote=192.168.1.5:49503 FD 31 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 31.12.1969 16:00:00 03.07.2024 10:49:32 ERROR: system call failure while accepting a TLS connection on conn6794 local=192.168.1.1:3128 remote=192.168.1.5:49496 FD 19 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_IO_ERR=5+errno=54 03.07.2024 10:49:24 ERROR: failure while accepting a TLS connection on conn6776 local=192.168.1.1:3128 remote=192.168.1.5:49481 FD 137 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1 03.07.2024 10:48:49 ERROR: failure while accepting a TLS connection on conn6440 local=192.168.1.1:3128 remote=192.168.1.5:49424 FD 16 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1 03.07.2024 10:48:49 ERROR: failure while accepting a TLS connection on conn6445 local=192.168.1.1:3128 remote=192.168.1.5:49426 FD 34 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 03.07.2024 10:48:22 ERROR: failure while accepting a TLS connection on conn6035 local=192.168.1.1:3128 remote=192.168.1.5:49355 FD 226 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1 03.07.2024 10:48:09 ERROR: failure while accepting a TLS connection on conn5887 local=192.168.1.1:3128 remote=192.168.1.5:49318 FD 33 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 03.07.2024 10:48:09 ERROR: failure while accepting a TLS connection on conn5875 local=192.168.1.1:3128 remote=192.168.1.5:49312 FD 216 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 03.07.2024 10:48:09 ERROR: failure while accepting a TLS connection on conn5876 local=192.168.1.1:3128 remote=192.168.1.5:49314 FD 217 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000417+TLS_IO_ERR=1 03.07.2024 10:47:57 ERROR: failure while accepting a TLS connection on conn5815 local=192.168.1.1:3128 remote=192.168.1.5:49297 FD 201 flags=1: SQUID_TLS_ERR_ACCEPT+TLS_LIB_ERR=A000418+TLS_IO_ERR=1 03.07.2024 10:47:54 ERROR: failure while accepting a TLS conne
Re: [squid-users] FATAL: assertion failed: mem/PageStack.cc:159: "StoredNode().is_lock_free()"
On 2024-07-03 09:27, Nishant Sharma wrote: I had reported the issue to Openwrt project as well and I understood that in order to save space, squid was being compiled for mips16 instead of mips32. Sorry, I do not know why/how that fact is relevant to this discussion, but thank you for sharing it as it may be useful for others. Even after compiling it for mips32 (by adding a flag for the build system), the error is still occuring as in the code in `ipc/mem/PageStack.h` `uint64_t` is specified. Glad to hear that: That assertion should not depend on those build flags AFAICT. I was able to compile by replacing `uint64_t` to `uint32_t` and squid worked with workers > 1. Where did you replace uint64_t with uint32_t? In IdSet::Node typedef? Any other changes? AFAICT, changing just IdSet::Node badly breaks the corresponding binary tree code because we hard-code the number of bits per leaf node (at least!) to be 64. I did not audit code for other dependencies. Further discussion on Openwrt issue tracker suggested [1] the following: The posix definition is that lock ID is native integer. It should be some conditional in ./configure style portability of squid to run on (most) 32bit platforms. It is possible that the above comment was negatively influenced by the previous misleading statement about Squid v4 having no uint64_t: "In code for version 4.x, there is no mention of uint64_t. It was introduced with 5.x." In reality, Squid has been using 64-bit integers since before Squid v3. It is neither practical nor necessary to remove uint64_t from Squid so there will be no corresponding conditionals in ./configure. The shared binary tree (that contains the assertion) did not exist in v4, as we discussed earlier. Is there any change that we need to do in the configure script to check for the availability of 64 bit atomic lock and use 32 bit lock if not available? It is technically possible (perhaps even without ./configure checks), but it would require adjusting complex shared tree code in the abcense of comprehensive ready-to-use tests. It is trivial to break that code. It is difficult to detect bugs. IMO, we should not expose ourselves to such risks in this case, especially since Squid uses 64-bit atomics in many other places: Supporting 32 bits in shared binary tree nodes is not going to remove the last frequently used 64-bit lock. Or may be document the fact that it is not advisable / possible to run squid in SMP mode on such platforms that are not able to provide 64 bit lock ID. I believe your experiments with removing the assertion point in a rather different direction: If your tests do not suggest otherwise, we should downgrade that assertion to a startup warning. Let folks run Squid on platforms without 64-bit atomic locks (if they wish to do so), but warn them about an uncertain impact. Perhaps we can even convince ourselves that the impact can only be on performance (i.e., there can be no deadlocks due to mutexes). Disclaimer: I do not know what "lock ID" is in this context. HTH, Alex. I tried to go through config.log and could see the following messages which might or might not be related to this: ... ... ... configure:46036: checking for uint64_t configure:46036: $? = 0 configure:46036: result: yes AND configure:46027: checking for int64_t configure:46027: mipsel-openwrt-linux-musl-g++ -std=c++17 -c -I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include -I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -msoft-float -fmacro-prefix-map=/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/build_dir/target-mipsel_24kc_musl/squid-6.10=squid-6.10 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -Wno-error -I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include -I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include/libxml2 -I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/toolchain-mipsel_24kc_gcc-12.3.0_musl/usr/include -I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/toolchain-mipsel_24kc_gcc-12.3.0_musl/include/fortify -I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/toolchain-mipsel_24kc_gcc-12.3.0_musl/include conftest.cpp >&5 configure:46027: $? = 0 configure:46027: mipsel-openwrt-linux-musl-g++ -std=c++17 -c -I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include -I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -msoft-float -fmacro-prefix-map=/home/devuser/openwrt-23.05/arthur/m
[squid-users] Speed issues
Does anyone have tips for getting the proxy to run faster when SSL intercept is enabled along side splice lists with dynamic cache and ClamAV running? I just seems to have slow traffic on the interception side. Sent from my iPhone ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] FATAL: assertion failed: mem/PageStack.cc:159: "StoredNode().is_lock_free()"
Hello,
On 28/06/24 20:01, Nishant Sharma wrote:
On 28/06/24 19:44, Alex Rousskov wrote:
I do not know the answer to your question. SMP performance penalties
are often smaller for smaller cache sizes, but cache size is not the
only performance-affecting locking-sensitive parameter, so YMMV.
I was able to compile after commenting the specific line of code. Squid
workers start and I am able to bind them to specific CPU cores.
I had reported the issue to Openwrt project as well and I understood
that in order to save space, squid was being compiled for mips16 instead
of mips32.
Even after compiling it for mips32 (by adding a flag for the build
system), the error is still occuring as in the code in
`ipc/mem/PageStack.h` `uint64_t` is specified.
I was able to compile by replacing `uint64_t` to `uint32_t` and squid
worked with workers > 1.
Further discussion on Openwrt issue tracker suggested [1] the following:
The posix definition is that lock ID is native integer. It should be
some conditional in ./configure style portability of squid to run on
(most) 32bit platforms.
Is there any change that we need to do in the configure script to check
for the availability of 64 bit atomic lock and use 32 bit lock if not
available?
Or may be document the fact that it is not advisable / possible to run
squid in SMP mode on such platforms that are not able to provide 64 bit
lock ID.
I tried to go through config.log and could see the following messages
which might or might not be related to this:
...
...
...
configure:46036: checking for uint64_t
configure:46036: $? = 0
configure:46036: result: yes
AND
configure:46027: checking for int64_t
configure:46027: mipsel-openwrt-linux-musl-g++ -std=c++17 -c
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include
-Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves
-fno-plt -fhonour-copts -msoft-float
-fmacro-prefix-map=/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/build_dir/target-mipsel_24kc_musl/squid-6.10=squid-6.10
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro -Wno-error
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include/libxml2
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/toolchain-mipsel_24kc_gcc-12.3.0_musl/usr/include
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/toolchain-mipsel_24kc_gcc-12.3.0_musl/include/fortify
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/toolchain-mipsel_24kc_gcc-12.3.0_musl/include
conftest.cpp >&5
configure:46027: $? = 0
configure:46027: mipsel-openwrt-linux-musl-g++ -std=c++17 -c
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include
-Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves
-fno-plt -fhonour-copts -msoft-float
-fmacro-prefix-map=/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/build_dir/target-mipsel_24kc_musl/squid-6.10=squid-6.10
-Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1
-Wl,-z,now -Wl,-z,relro -Wno-error
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/target-mipsel_24kc_musl/usr/include/libxml2
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/toolchain-mipsel_24kc_gcc-12.3.0_musl/usr/include
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/toolchain-mipsel_24kc_gcc-12.3.0_musl/include/fortify
-I/home/devuser/openwrt-23.05/arthur/mt7621/openwrt/staging_dir/toolchain-mipsel_24kc_gcc-12.3.0_musl/include
conftest.cpp >&5
conftest.cpp: In function 'int main()':
conftest.cpp:324:67: warning: integer overflow in expression of type
'int64_t' {aka 'long long int'} results in '-9223372036854775808'
[-Woverflow]
324 | < (int64_t) (int64_t) 1 << N) << N) - 1) *
2 + 2))];
|
^~~
conftest.cpp:323:26: error: size '-1' of array 'test_array' is negative
323 | static int test_array [1 - 2 * !((int64_t) (int64_t) 1 <<
N) << N) - 1) * 2 + 1)
|
~~^~~
324 | < (int64_t) (int64_t) 1 << N) << N) - 1) *
2 + 2))];
|
~~
configure:46027: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "Squid Web Proxy"
| #define PACKAGE_TARNAME "squid"
| #define PACKAGE_VERSION "6.10"
| #define PACKAGE_STRING "Squid
