FATAL: Received Segment Violation...dying.

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.

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

Alex,
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

Alex,

Object with 0 byte for testing and crashing the squid/ecapgzip:
http://its.tradelab.fr/?type=iev&advid=123320
http://its.tradelab.fr/?type=iev&advid=66733

Bye Fred

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.

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)

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 ?

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

Bye Fred