Squid crash - 3.5.21

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Squid crash - 3.5.21

Jasper Van Der Westhuizen-2
Hi all

This morning I had some problems with some of our proxies. 2 Proxies in cluster A crashed with the below errors. The shortly afterwards 4 in cluster B did the same. Both clusters are configured to run their cache in memory with SMP and 4 workers configured.

2016/10/03 10:28:37 kid3| snmpHandleUdp: FD 258 recvfrom: (11) Resource temporarily unavailable 
2016/10/03 10:28:37 kid4| snmpHandleUdp: FD 21 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:37 kid4| snmpHandleUdp: FD 21 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:37 kid3| snmpHandleUdp: FD 258 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:37 kid2| snmpHandleUdp: FD 1892 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:37 kid3| snmpHandleUdp: FD 258 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:37 kid4| snmpHandleUdp: FD 21 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:37 kid3| snmpHandleUdp: FD 258 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:37 kid1| snmpHandleUdp: FD 217 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid1| snmpHandleUdp: FD 217 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid2| snmpHandleUdp: FD 1892 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid3| snmpHandleUdp: FD 258 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid4| snmpHandleUdp: FD 21 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid3| snmpHandleUdp: FD 258 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid1| snmpHandleUdp: FD 217 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid4| snmpHandleUdp: FD 21 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid1| snmpHandleUdp: FD 217 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid3| snmpHandleUdp: FD 258 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid3| snmpHandleUdp: FD 258 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid1| snmpHandleUdp: FD 217 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid1| snmpHandleUdp: FD 217 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid3| snmpHandleUdp: FD 258 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid1| snmpHandleUdp: FD 217 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid1| snmpHandleUdp: FD 217 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid3| snmpHandleUdp: FD 258 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid4| snmpHandleUdp: FD 21 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid1| snmpHandleUdp: FD 217 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid4| snmpHandleUdp: FD 21 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:38 kid2| snmpHandleUdp: FD 1892 recvfrom: (11) Resource temporarily unavailable
2016/10/03 10:28:39 kid3| snmpHandleUdp: FD 258 recvfrom: (11) Resource temporarily unavailable

FATAL: Received Bus Error...dying.
2016/10/03 10:28:49 kid2| Closing HTTP port xxxxxxxxx:8080
2016/10/03 10:28:49 kid2| Closing HTTP port 127.0.0.1:8080
2016/10/03 10:28:49 kid2| storeDirWriteCleanLogs: Starting...
2016/10/03 10:28:49 kid2|   Finished.  Wrote 0 entries.
2016/10/03 10:28:49 kid2|   Took 0.00 seconds (  0.00 entries/sec).
CPU Usage: 29249.604 seconds = 14130.271 user + 15119.333 sys
Maximum Resident Size: 24210640 KB
Page faults with physical i/o: 0
FATAL: Received Bus Error...dying.
2016/10/03 10:28:47 kid4| Closing HTTP port 
xxxxxxxxxx3:8080 
2016/10/03 10:28:47 kid4| Closing HTTP port 127.0.0.1:8080
2016/10/03 10:28:47 kid4| storeDirWriteCleanLogs: Starting...
2016/10/03 10:28:47 kid4|   Finished.  Wrote 0 entries.
2016/10/03 10:28:47 kid4|   Took 0.00 seconds (  0.00 entries/sec).
CPU Usage: 19100.510 seconds = 9502.454 user + 9598.056 sys
Maximum Resident Size: 9194336 KB
Page faults with physical i/o: 0
FATAL: Received Bus Error...dying.
2016/10/03 10:28:47 kid1| Closing HTTP port 
xxxxxxxxxx:8080
2016/10/03 10:28:47 kid1| Closing HTTP port 127.0.0.1:8080
2016/10/03 10:28:47 kid1| storeDirWriteCleanLogs: Starting...
2016/10/03 10:28:47 kid1|   Finished.  Wrote 0 entries.
2016/10/03 10:28:47 kid1|   Took 0.00 seconds (  0.00 entries/sec).
CPU Usage: 28389.386 seconds = 13891.472 user + 14497.914 sys
Maximum Resident Size: 19754288 KB
Page faults with physical i/o: 0
FATAL: Received Bus Error...dying.
2016/10/03 10:28:47 kid3| Closing HTTP port 
xxxxxxxxxx:8080
2016/10/03 10:28:47 kid3| Closing HTTP port 127.0.0.1:8080
2016/10/03 10:28:47 kid3| storeDirWriteCleanLogs: Starting...
2016/10/03 10:28:47 kid3|   Finished.  Wrote 0 entries.
2016/10/03 10:28:47 kid3|   Took 0.00 seconds (  0.00 entries/sec).
CPU Usage: 35218.057 seconds = 17518.687 user + 17699.370 sys
Maximum Resident Size: 21131904 KB
Page faults with physical i/o: 0


Squid Cache: Version 3.5.21 
Service Name: squid
configure options:  '--prefix=/usr/local/squid3.5.21' '--sysconfdir=/etc/squid3.5.21' '--enable-follow-x-forwarded-for' '--with-logdir=/var/lo
g/squid/' '-with-pidfile=/var/run/squid.pid' '--with-swapdir=/var/cache/squid/' '--with-large-files' '--with-default-user=squid' '--with-inclu
ded-ltdl' '--enable-snmp' '--enable-storeio=ufs,aufs' '--enable-removal-policies=lru,heap' '--enable-ltdl-convenience' '--with-pthreads'

--
Kind Regards
Jasper





Disclaimer:
http://www.shopriteholdings.co.za/Pages/ShopriteE-mailDisclaimer.aspx

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid crash - 3.5.21

Alex Rousskov
On 10/03/2016 04:50 AM, Jasper Van Der Westhuizen wrote:
> This morning I had some problems with some of our proxies. 2 Proxies in
> cluster A crashed with the below errors. The shortly afterwards 4 in
> cluster B did the same. Both clusters are configured to run their cache
> in memory with SMP and 4 workers configured.
>
> FATAL: Received Bus Error...dying.


There are at least two possible reasons:

  1. A bug in Squid and
  2. Memory overallocation by the OS kernel.

To fix the former, the developers will need a stack trace (at least). I
recommend filing a bug report after getting that trace and excluding
reason #2. Squid wiki and various system administration guides explain
how to make Squid dump core files.

To check for memory overallocation, you can temporary start Squid v4.0
with "shared_memory_locking on". Unfortunately, that squid.conf
directive is not available in Squid v3. You may be able to emulate it
using some OS-specific sysctl or environment variables, but doing so may
be far from trivial, and I do not have instructions.


HTH,

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid crash - 3.5.21

Jasper Van Der Westhuizen-2


On Mon, 2016-10-03 at 11:33 -0600, Alex Rousskov wrote:
On 10/03/2016 04:50 AM, Jasper Van Der Westhuizen wrote:
This morning I had some problems with some of our proxies. 2 Proxies in cluster A crashed with the below errors. The shortly afterwards 4 in cluster B did the same. Both clusters are configured to run their cache in memory with SMP and 4 workers configured. FATAL: Received Bus Error...dying.
There are at least two possible reasons: 1. A bug in Squid and 2. Memory overallocation by the OS kernel. To fix the former, the developers will need a stack trace (at least). I recommend filing a bug report after getting that trace and excluding reason #2. Squid wiki and various system administration guides explain how to make Squid dump core files. To check for memory overallocation, you can temporary start Squid v4.0 with "shared_memory_locking on". Unfortunately, that squid.conf directive is not available in Squid v3. You may be able to emulate it using some OS-specific sysctl or environment variables, but doing so may be far from trivial, and I do not have instructions.

Thanks Alex. We have patched the servers to the latest and will monitor. If it happens again I will fill in a bug report and see where it takes us. 

Regards
Jasper





Disclaimer:
http://www.shopriteholdings.co.za/Pages/ShopriteE-mailDisclaimer.aspx

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid crash - 3.5.21

hindsight1
In reply to this post by Alex Rousskov

Hi,Alex
When running Squid4.8 on the arm using SMP. And setting 4 or 7,9  worker
,the same error occurred in the log.
>> Received Bus Error...dying,
Debugging the core file with gdb found that the address was not aligned.

Does it consider the case where only address-aligned access is supported on
arm

The question is, why is the type of Item in the PageStack class using
uint32_t, can it be replaced with uint64_t or size_t? When I change to
uint64_t, the problem disappears.
I tried another way to ensure that the theCapacity  parameter passed in to
an even number also solves this problem.

Kind Regards,
hindsight
Alex Rousskov wrote

> On 10/03/2016 04:50 AM, Jasper Van Der Westhuizen wrote:
>> This morning I had some problems with some of our proxies. 2 Proxies in
>> cluster A crashed with the below errors. The shortly afterwards 4 in
>> cluster B did the same. Both clusters are configured to run their cache
>> in memory with SMP and 4 workers configured.
>>
>> FATAL: Received Bus Error...dying.
>
>
> There are at least two possible reasons:
>
>   1. A bug in Squid and
>   2. Memory overallocation by the OS kernel.
>
> To fix the former, the developers will need a stack trace (at least). I
> recommend filing a bug report after getting that trace and excluding
> reason #2. Squid wiki and various system administration guides explain
> how to make Squid dump core files.
>
> To check for memory overallocation, you can temporary start Squid v4.0
> with "shared_memory_locking on". Unfortunately, that squid.conf
> directive is not available in Squid v3. You may be able to emulate it
> using some OS-specific sysctl or environment variables, but doing so may
> be far from trivial, and I do not have instructions.
>
>
> HTH,
>
> Alex.
>
> _______________________________________________
> squid-users mailing list

> squid-users@.squid-cache

> http://lists.squid-cache.org/listinfo/squid-users





--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid crash - 3.5.21

Alex Rousskov
Context: hindsight1 was replying to a 2016 email archived at
http://lists.squid-cache.org/pipermail/squid-users/2016-October/012881.html


On 11/10/19 7:13 AM, hindsight1 wrote:
> When running Squid4.8 on the arm using SMP. And setting 4 or 7,9  worker
> ,the same error occurred in the log.

>>> Received Bus Error...dying,

> Debugging the core file with gdb found that the address was not aligned.
>
> Does it consider the case where only address-aligned access is supported on
> arm

I am not sure whether "it" in your sentence refers to gdb or Squid, but
if Squid dereferences an unaligned data field in shared memory, then it
is most likely a Squid bug.


> The question is, why is the type of Item in the PageStack class using
> uint32_t,

Probably to avoid wasting space: Squid Store does not yet support caches
with more than 16777215 entries (a signed 25-bit integer) and SMP-aware
caches do not support storing responses with more pages than that limit.
Even though response size and the number of responses are conceptually
different limits, the underlying code/structures tie the two together IIRC.


> can it be replaced with uint64_t or size_t?

I have not checked whether any other adjustments would be required, but
I suspect that the answer is "yes". Needless to say, this replacement
will waste RAM.


> When I change to uint64_t, the problem disappears.

If there is an unaligned access bug, we should fix that bug directly
rather than relying on side effects of field sizes or, at least, we
should confirm and document that those side effects are the right fix.

To fix this properly, a stack trace would be very helpful. Can you post
that?


Alex.


> Alex Rousskov wrote
>> On 10/03/2016 04:50 AM, Jasper Van Der Westhuizen wrote:
>>> This morning I had some problems with some of our proxies. 2 Proxies in
>>> cluster A crashed with the below errors. The shortly afterwards 4 in
>>> cluster B did the same. Both clusters are configured to run their cache
>>> in memory with SMP and 4 workers configured.
>>>
>>> FATAL: Received Bus Error...dying.
>>
>>
>> There are at least two possible reasons:
>>
>>   1. A bug in Squid and
>>   2. Memory overallocation by the OS kernel.
>>
>> To fix the former, the developers will need a stack trace (at least). I
>> recommend filing a bug report after getting that trace and excluding
>> reason #2. Squid wiki and various system administration guides explain
>> how to make Squid dump core files.
>>
>> To check for memory overallocation, you can temporary start Squid v4.0
>> with "shared_memory_locking on". Unfortunately, that squid.conf
>> directive is not available in Squid v3. You may be able to emulate it
>> using some OS-specific sysctl or environment variables, but doing so may
>> be far from trivial, and I do not have instructions.
>>
>>
>> HTH,
>>
>> Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid crash - 3.5.21

hindsight1
Hi,Alex

thank you for your reply
Sorry for my English,First of all,
> I am not sure whether "it" in your sentence refers to gdb or Squid, but
> if Squid dereferences an unaligned data field in shared memory, then it
> is most likely a Squid bug.

"it" is refers to Squid.

i want to Explain my problem again


I run Squid4.8 using SMP mode on the Arm64 platform. When setting some
worker numbers, for example 4 or 7,9 the same error Received Bus
Error...dying appears in the log.
Using gdb debugging, I found an error when accessing theLevels variable in
the Ipc::Mem::PagePool::level function, due to the non-aligned address
access caused by the atomic operation load.
Here is stacktrace:

#0  0x0000ffff9c945228 in raise () from /lib64/libc.so.6
#1  0x0000ffff9c9468a0 in abort () from /lib64/libc.so.6
#2  0x00000000007c6238 in death (sig=7) at tools.cc:359
#3  <signal handler called>
#4  0x00000000007c50a4 in std::__atomic_base<unsigned long>::load
(this=0xfff9d9d40cec, __m=std::memory_order_seq_cst) at
/usr/include/c++/4.8.2/bits/atomic_base.h:496
#5  0x00000000007c4344 in std::__atomic_base<unsigned long>::operator
unsigned long (this=0xfff9d9d40cec) at
/usr/include/c++/4.8.2/bits/atomic_base.h:367
#6  0x0000000000937f2c in Ipc::Mem::PagePool::level (this=0xde9150,
purpose=0) at mem/PagePool.cc:46
#7  0x0000000000934ae8 in Ipc::Mem::PageLevel (purpose=0) at mem/Pages.cc:88
#8  0x00000000007c3db0 in Ipc::Mem::PagesAvailable (purpose=0) at
ipc/mem/Pages.h:51
#9  0x00000000009342a4 in Ipc::Mem::GetPage
(purpose=Ipc::Mem::PageId::cachePage, page=...) at mem/Pages.cc:36
#10 0x00000000007c241c in MemStore::reserveSapForWriting (this=0x10e3bb0,
page=...) at MemStore.cc:778
#11 0x00000000007c1c18 in MemStore::nextAppendableSlice (this=0x10e3bb0,
fileNo=513735, sliceOffset=@0x10e3bd8: -1) at MemStore.cc:731
#12 0x00000000007c145c in MemStore::copyToShm (this=0x10e3bb0, e=...) at
MemStore.cc:682
#13 0x00000000007c2cdc in MemStore::write (this=0x10e3bb0, e=...) at
MemStore.cc:856
#14 0x00000000009f9838 in Store::Controller::memoryOut (this=0xdd2e20,
e=..., preserveSwappable=true) at Controller.cc:550
#15 0x00000000007b50e8 in StoreEntry::swapOut (this=0x125e4e0) at
store_swapout.cc:175
#16 0x00000000007af4a4 in StoreEntry::invokeHandlers (this=0x125e4e0) at
store_client.cc:720
#17 0x00000000007a650c in StoreEntry::flush (this=0x125e4e0) at
store.cc:1674
#18 0x00000000007a6dcc in StoreEntry::startWriting (this=0x125e4e0) at
store.cc:1844
#19 0x000000000083b7e8 in Client::setFinalReply (this=0x1275b18,
rep=0x12b36c0) at Client.cc:164
#20 0x00000000008401bc in Client::adaptOrFinalizeReply (this=0x1275b18) at
Client.cc:974
#21 0x0000000000726344 in HttpStateData::processReply (this=0x1275b18) at
http.cc:1246
#22 0x0000000000725fec in HttpStateData::readReply (this=0x1275b18, io=...)
at http.cc:1223
#23 0x000000000072fc10 in CommCbMemFunT<HttpStateData,
CommIoCbParams>::doDial (this=0x1285f80) at CommCalls.h:205
#24 0x0000000000730070 in JobDialer<HttpStateData>::dial (this=0x1285f80,
call=...) at base/AsyncJobCalls.h:174
#25 0x000000000072f728 in AsyncCallT<CommCbMemFunT&lt;HttpStateData,
CommIoCbParams> >::fire (this=0x1285f50) at ../src/base/AsyncCall.h:145
#26 0x0000000000887728 in AsyncCall::make (this=0x1285f50) at
AsyncCall.cc:40
#27 0x0000000000888270 in AsyncCallQueue::fireNext (this=0xe11e80) at
AsyncCallQueue.cc:56
#28 0x0000000000888068 in AsyncCallQueue::fire (this=0xe11e80) at
AsyncCallQueue.cc:42
#29 0x00000000006f4948 in EventLoop::dispatchCalls (this=0xfffff17422e8) at
EventLoop.cc:144
#30 0x00000000006f485c in EventLoop::runOnce (this=0xfffff17422e8) at
EventLoop.cc:121
#31 0x00000000006f46a0 in EventLoop::run (this=0xfffff17422e8) at
EventLoop.cc:83
#32 0x000000000076090c in SquidMain (argc=4, argv=0xfffff1742638) at
main.cc:1709
#33 0x000000000075fe70 in SquidMainSafe (argc=4, argv=0xfffff1742638) at
main.cc:1417
#34 0x000000000075fe3c in main (argc=4, argv=0xfffff1742638) at main.cc:1405

When theLevels is initialized, the assigned value is a multiple of 4 and is
not aligned with the unsigned long.
Atomic operations on arm only support aligned address access.
This problem has not been encountered on the x86 platform.


In the previous reply, there was another question that was not answered.

> I tried another way to ensure that the theCapacity  parameter passed in to
> an even number also solves this problem.

Keep the item type uint32_t, modify the NoteMemoryNeeds method in the
IpcIoFile.cc file in NotePageNeed as follows

 Ipc:: Mem:: NotePageNeed(Ipc::Mem::PageId::ioPage,static_cast
<int>(itemsCount * 1.1)+ static_cast < Int>(itemsCount * 1.1)%2);


This modification ensures that the value obtained by the theCapacity
parameter is even,which also solves this problem.


After your analysis, please evaluate whether this method is reasonable,thank
you.


Regards,
hindsight



--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid crash - 3.5.21

Alex Rousskov
FTR: hindsight1 runs v4.8 despite the email subject saying "3.5.21".


On 11/11/19 9:34 PM, hindsight1 wrote:

> thank you for your reply

Thank you for detailing the problem. The best place to discuss these
low-level details is Squid Bugzilla. I suggest that you open a new bug
report there. If you want to continue here, then the primary remaining
question for me is _why_ theLevels array elements are misaligned in your
tests:

* theLevels[0]: The segments are allocated on page-boundaries so the
first level element (i.e. level[0]) should be properly aligned. I
believe your stack trace shows that this zero-offset access is misaligned.

* theLevels[n+1]: The levels array is declared using regular C++
constructs, without any casting, so subsequent elements should be
aligned properly if the first element is aligned properly.

So where does this misalignment originate from? Properly addressing this
bug probably requires answering this question.


Please note that there are GCC v4 bugs that might be relevant here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65147

What is your compiler? Does building with GCC v5.1 fix the problem?


BTW, there is a potentially useful alignas() workaround/trick shown at
https://stackoverflow.com/questions/26703297/alignment-of-atomic-variables



Thank you,

Alex.


> Sorry for my English,First of all,
>> I am not sure whether "it" in your sentence refers to gdb or Squid, but
>> if Squid dereferences an unaligned data field in shared memory, then it
>> is most likely a Squid bug.
>
> "it" is refers to Squid.
>
> i want to Explain my problem again
>
>
> I run Squid4.8 using SMP mode on the Arm64 platform. When setting some
> worker numbers, for example 4 or 7,9 the same error Received Bus
> Error...dying appears in the log.
> Using gdb debugging, I found an error when accessing theLevels variable in
> the Ipc::Mem::PagePool::level function, due to the non-aligned address
> access caused by the atomic operation load.
> Here is stacktrace:
>
> #0  0x0000ffff9c945228 in raise () from /lib64/libc.so.6
> #1  0x0000ffff9c9468a0 in abort () from /lib64/libc.so.6
> #2  0x00000000007c6238 in death (sig=7) at tools.cc:359
> #3  <signal handler called>
> #4  0x00000000007c50a4 in std::__atomic_base<unsigned long>::load
> (this=0xfff9d9d40cec, __m=std::memory_order_seq_cst) at
> /usr/include/c++/4.8.2/bits/atomic_base.h:496
> #5  0x00000000007c4344 in std::__atomic_base<unsigned long>::operator
> unsigned long (this=0xfff9d9d40cec) at
> /usr/include/c++/4.8.2/bits/atomic_base.h:367
> #6  0x0000000000937f2c in Ipc::Mem::PagePool::level (this=0xde9150,
> purpose=0) at mem/PagePool.cc:46
> #7  0x0000000000934ae8 in Ipc::Mem::PageLevel (purpose=0) at mem/Pages.cc:88
> #8  0x00000000007c3db0 in Ipc::Mem::PagesAvailable (purpose=0) at
> ipc/mem/Pages.h:51
> #9  0x00000000009342a4 in Ipc::Mem::GetPage
> (purpose=Ipc::Mem::PageId::cachePage, page=...) at mem/Pages.cc:36
> #10 0x00000000007c241c in MemStore::reserveSapForWriting (this=0x10e3bb0,
> page=...) at MemStore.cc:778
> #11 0x00000000007c1c18 in MemStore::nextAppendableSlice (this=0x10e3bb0,
> fileNo=513735, sliceOffset=@0x10e3bd8: -1) at MemStore.cc:731
> #12 0x00000000007c145c in MemStore::copyToShm (this=0x10e3bb0, e=...) at
> MemStore.cc:682
> #13 0x00000000007c2cdc in MemStore::write (this=0x10e3bb0, e=...) at
> MemStore.cc:856
> #14 0x00000000009f9838 in Store::Controller::memoryOut (this=0xdd2e20,
> e=..., preserveSwappable=true) at Controller.cc:550
> #15 0x00000000007b50e8 in StoreEntry::swapOut (this=0x125e4e0) at
> store_swapout.cc:175
> #16 0x00000000007af4a4 in StoreEntry::invokeHandlers (this=0x125e4e0) at
> store_client.cc:720
> #17 0x00000000007a650c in StoreEntry::flush (this=0x125e4e0) at
> store.cc:1674
> #18 0x00000000007a6dcc in StoreEntry::startWriting (this=0x125e4e0) at
> store.cc:1844
> #19 0x000000000083b7e8 in Client::setFinalReply (this=0x1275b18,
> rep=0x12b36c0) at Client.cc:164
> #20 0x00000000008401bc in Client::adaptOrFinalizeReply (this=0x1275b18) at
> Client.cc:974
> #21 0x0000000000726344 in HttpStateData::processReply (this=0x1275b18) at
> http.cc:1246
> #22 0x0000000000725fec in HttpStateData::readReply (this=0x1275b18, io=...)
> at http.cc:1223
> #23 0x000000000072fc10 in CommCbMemFunT<HttpStateData,
> CommIoCbParams>::doDial (this=0x1285f80) at CommCalls.h:205
> #24 0x0000000000730070 in JobDialer<HttpStateData>::dial (this=0x1285f80,
> call=...) at base/AsyncJobCalls.h:174
> #25 0x000000000072f728 in AsyncCallT<CommCbMemFunT&lt;HttpStateData,
> CommIoCbParams> >::fire (this=0x1285f50) at ../src/base/AsyncCall.h:145
> #26 0x0000000000887728 in AsyncCall::make (this=0x1285f50) at
> AsyncCall.cc:40
> #27 0x0000000000888270 in AsyncCallQueue::fireNext (this=0xe11e80) at
> AsyncCallQueue.cc:56
> #28 0x0000000000888068 in AsyncCallQueue::fire (this=0xe11e80) at
> AsyncCallQueue.cc:42
> #29 0x00000000006f4948 in EventLoop::dispatchCalls (this=0xfffff17422e8) at
> EventLoop.cc:144
> #30 0x00000000006f485c in EventLoop::runOnce (this=0xfffff17422e8) at
> EventLoop.cc:121
> #31 0x00000000006f46a0 in EventLoop::run (this=0xfffff17422e8) at
> EventLoop.cc:83
> #32 0x000000000076090c in SquidMain (argc=4, argv=0xfffff1742638) at
> main.cc:1709
> #33 0x000000000075fe70 in SquidMainSafe (argc=4, argv=0xfffff1742638) at
> main.cc:1417
> #34 0x000000000075fe3c in main (argc=4, argv=0xfffff1742638) at main.cc:1405
>
> When theLevels is initialized, the assigned value is a multiple of 4 and is
> not aligned with the unsigned long.
> Atomic operations on arm only support aligned address access.
> This problem has not been encountered on the x86 platform.
>
>
> In the previous reply, there was another question that was not answered.
>
>> I tried another way to ensure that the theCapacity  parameter passed in to
>> an even number also solves this problem.
>
> Keep the item type uint32_t, modify the NoteMemoryNeeds method in the
> IpcIoFile.cc file in NotePageNeed as follows
>
>  Ipc:: Mem:: NotePageNeed(Ipc::Mem::PageId::ioPage,static_cast
> <int>(itemsCount * 1.1)+ static_cast < Int>(itemsCount * 1.1)%2);
>
>
> This modification ensures that the value obtained by the theCapacity
> parameter is even,which also solves this problem.
>
>
> After your analysis, please evaluate whether this method is reasonable,thank
> you.
>
>
> Regards,
> hindsight

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid crash - 3.5.21

hindsight1
Hi Alex,

> So where does this misalignment originate from? Properly addressing this
bug probably requires answering this question.


Let's discuss it on Squid Bugzilla, I have already mentioned the bug above,
the bug number is 5008

> Please note that there are GCC v4 bugs that might be relevant here:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65147
>What is your compiler? Does building with GCC v5.1 fix the problem?

Originally used 4.8.5,but updated to 7.3.0. This problem still exists

> BTW, there is a potentially useful alignas() workaround/trick shown at
> https://stackoverflow.com/questions/26703297/alignment-of-atomic-variables


This method I have tried when the problem appeared, it no use

Regards,
hindsight





--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users