FATAL: Received Segment Violation...dying.

Asked by FredT on 2015-09-25

Hi All,
I compiled a Squid 3.5.8 with the correct option "--enable-ecap" (compiling Squid is not new for me), I used the latest libecap 1.0.0 and squid-ecap-gzip available from the correct websites. Once all compiled, it works fine using the correct config in Squid as recommended by the Squid wiki.
I decided to copy (clone) the Squid/libecap/ecap-gzip to a second computer (tar command to keep links), but when I start the Squid I can see this error in the cache.log: "FATAL: Received Segment Violation...dying." and the Squid restarts by itself.

Did I forget a lib to install or a folder to copy ?
Any idea ?

Bye Fred

Question information

English Edit question
eCAP Edit question
No assignee Edit question
Last query:
Last reply:
Alex Rousskov (rousskov) said : #1

I do not have any specific ideas (please keep in mind that I do not know much about squid-ecap-gzip and whether it is even compatible with libecap v1.0.0). Please post a gdb backtrace from the segfault. Squid wiki/FAQ has instructions on how to get that information from Squid.

FredT (suppobt) said : #2

HI Alex,
Actually, I found the bug: the ecap-gzip plugin crashes when it's chained.

Let me explain the situation:
The original Squid/libecap/ecap-gzip is the last PC before internet, compressing data for all my devices. I "cloned" the original to another PC for testing meaning this "clone" has to go via the original for surfing: users -> clone -> original -> internet.
As objects are firstly compressed by the original Squid then sent to the clone, here the clone computes original size 0 and compressed size 0 doing an issue and generating a "FATAL: Received Segment Violation...dying." with the Squid clone.

Am I clear enough in the explaination ? :o)
I'm looking for to add a check if the headers already contain "X-Ecap" and bypass the compression... or maybe there is a better way to do not "ecap-gzip" an object already done by an upper squid...

bey Fred

FredT (suppobt) said : #3

I did more tests this morning and I can confirm the Squid crashes when the ecap-gzip has to manage a 0 byte object.
I added some traces in the adapter_gzip.cc and when the "gzipContext->originalSize" is 0 the plugin faces an issue and crashes the Squid...

I don't know why the object is 0 byte, that's weird...

Bye Fred

FredT (suppobt) said : #4


Object with 0 byte for testing and crashing the squid/ecapgzip:

Bye Fred

Alex Rousskov (rousskov) said : #5

Glad you found the source of the problem. Now you need to fix that adapter or find somebody who can fix it for you. This 3rd-party adapter-specific issue is out of general eCAP support scope provided here.

Unfortunately, I cannot think of a reliable way to detect zero-size messages using squid.conf ACLs (to avoid sending them to the adapter). For example, the URLs you have listed above do not have a Content-Length header. They use chunked encoding to encode a zero-size [decoded] body.

Alex Rousskov (rousskov) said : #6

As for avoiding applying the ecap-gzip adapter twice to the same message, you should be able to do that by adding ACL rules that look for Transfer-Encoding:gzip header value (I assume that the ecap-gzip adapter adds that header/value). Please note that Transfer-Encoding header should have multiple values if one of them is gzip so your rules may need to deal with at least these header variants (there are actually more possibilities):

* no Transfer-Encoding at all (apply adapter)
* Transfer-Encoding: chunked (apply adapter)
* Transfer-Encoding: gzip,chunked (do not apply adapter)

FredT (suppobt) said : #7

Hi Alex,
I submited the bug to the ecap-gzip github account, wait and see the answer... i'll post the answer here for sharing to all...

Bye Fred

Hi FredT:

what's the current status ?

FredT (suppobt) said : #9

As it seems nobody cares about this bug so I fixed the problem by myself...

Bye Fred

Can you help with this problem?

Provide an answer of your own, or ask FredT for more information if necessary.

To post a message you must log in.