Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

bugreporter
Hi,

Is it allowed (supported) to chain icap and ecap services (using adaptation_service_chain)? I get a "FATAL: Received Segment Violation...dying." when trying to do it with some websites (www.linguee.com for instance). Each of those services works very well separately.

Maybe this has never been tested before and I'm on a wrong way... But if (in theory) it's supported can someone help me to build the right squid configuration? I'll give more details on my configuration if the answer to the above question is YES.

In a few words I'm trying to chain c_icap/clamav with  squid-ecap-gzip. Below my configuration:
# 8<------------------------------------------------------------------------------------------------------------------------
ecap_service gzip_response respmod_precache ecap://www.vigos.com/ecap_gzip bypass=off routing=off
icap_service av_response respmod_precache icap://127.0.0.3:1344/virusscan routing=off on-overload=wait bypass=off max-conn=32

adaptation_service_chain av_gzip_response av_response gzip_response
adaptation_access av_gzip_response allow all
# 8<------------------------------------------------------------------------------------------------------------------------
Bug Reporter Contributor OpenSource = Open-Minded
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

Yuri Voinov
Details. Squid's version, OS version, compiler version, core dump contents.


09.07.2017 22:59, bugreporter пишет:

> Hi,
>
> Is it allowed (supported) to chain icap and ecap services (using
> /adaptation_service_chain/)? I get a "FATAL: Received Segment
> Violation...dying." when trying to do it with some websites (www.linguee.com
> for instance). Each of those services works very well separately.
>
> Maybe this has never been tested before and I'm on a wrong way... But if (in
> theory) it's supported can someone help me to build the right squid
> configuration? I'll give more details on my configuration if the answer to
> the above question is YES.
>
> In a few words I'm trying to chain *c_icap/clamav* with  *squid-ecap-gzip*.
> Below my configuration:
>
>
>
>
>
> -----
> Bug Reporter Contributor
> OpenSource = Open-Minded
> --
> View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Chaining-icap-and-ecap-services-FATAL-Received-Segment-Violation-dying-tp4683033.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

bugreporter
This post was updated on .
Thank you for your prompt response Yuri. Below information that you have requested:

- Squid 3.5.26
- Linux kernel 3.10.100 on an LFS (Linux From Scratch)
- gcc-4.8.1, glibc-2.18

Cheers
Bug Reporter Contributor OpenSource = Open-Minded
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

Yuri Voinov


10.07.2017 0:54, bugreporter пишет:
> Thank you for your prompt response Yuri. Below information that you have
> requested:
>
> - Squid 3.5.26
> - Linux kernel 3.10.100 on an LFS (Linux From Scratch)
> - gcc-4.8.1, glibc-2.18
>
> Don't yet have a core dump. Are you interested in having the log file in
> debug mode?
In addition to core backtrace - yes.

 Set up your OS for save process cores, I guess this fatal produce
squid's core. Better to build squid's first with debug symbols (-g
compiler option) and backtrace resulting core with debugger.
> Cheers
I suggest old adaptation subsystem bug (still opened), which is not
reproduces in 4.x/5.x squid's.  But to make sure it is require to take a
look on core.

>
>
>
> -----
> Bug Reporter Contributor
> OpenSource = Open-Minded
> --
> View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Chaining-icap-and-ecap-services-FATAL-Received-Segment-Violation-dying-tp4683033p4683036.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

Yuri Voinov
In reply to this post by bugreporter
Also it can be issue with ecap-gzip adapter itself. AFAIK it has opened
issue with segfault on some sites.

Public version has not close this bug because of author abandoned project.


10.07.2017 0:54, bugreporter пишет:

> Thank you for your prompt response Yuri. Below information that you have
> requested:
>
> - Squid 3.5.26
> - Linux kernel 3.10.100 on an LFS (Linux From Scratch)
> - gcc-4.8.1, glibc-2.18
>
> Don't yet have a core dump. Are you interested in having the log file in
> debug mode?
> Cheers
>
>
>
> -----
> Bug Reporter Contributor
> OpenSource = Open-Minded
> --
> View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Chaining-icap-and-ecap-services-FATAL-Received-Segment-Violation-dying-tp4683033p4683036.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

bugreporter
Yes I had some issue with ecap-gzip (related to chunked content) that I have already resolved by bypassing chunked content (I modified the code). Now I have no issue with ecap-gzip when it's used alone (without being in a chain).

Herewith the log file (debug_options ALL,3):
squid.gz
Bug Reporter Contributor OpenSource = Open-Minded
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

Yuri Voinov
Hmmmm. Bases on this log, issue occurs in ICAP processing.

Most close to this:

http://bugs.squid-cache.org/show_bug.cgi?id=4597

As I can remember, this bug occurs on ECAP, not with ICAP. Configuration
was like you, chained ecap+icap services. Sadly, I can't show patch for
3.5, especially it was platform-specific dirty hack ;)

Can you try to reproduce this on 4.0.x Squid? This time I have not 3.5.x
running servers.

AFAIK, this issue was not occurs neither on 4.x nor on 5.x Squid's.


10.07.2017 4:22, bugreporter пишет:

> Yes I had some issue with ecap-gzip (related to chunked content) that I have
> already resolved by bypassing chunked content (I modified the code). Now I
> have no issue with ecap-gzip when it's used alone (without being in a
> chain).
>
> Herewith the log file (debug_options ALL,3):
> squid.gz
> <http://squid-web-proxy-cache.1019090.n4.nabble.com/file/n4683039/squid.gz>  
>
>
>
> -----
> Bug Reporter Contributor
> OpenSource = Open-Minded
> --
> View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Chaining-icap-and-ecap-services-FATAL-Received-Segment-Violation-dying-tp4683033p4683039.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

bugreporter
Hi Yuri
,
Below the gdb backtrace. I hope that it could help you resolving the issue.

Regarding Squid-4.0 my understanding is that it is a beta version while I need a stable version. Actually at this stage upgrading to 4.0  would represent a lot of integration, testing and validation work. Therefore, either I abandon the idea to have ecap and icap at the same time or the bug can be fixed (or at least we can find a workaround).

8<-----------------------------------------------------------------------------------------------------------------------------------------
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /sbin/squid...done.
[New LWP 4452]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Core was generated by `(squid-1) -f /etc/squid.conf'.
Program terminated with signal 6, Aborted.
#0  0x00007fc47fa6a3a9 in raise () from /lib/libc.so.6
(gdb) bt full
#0  0x00007fc47fa6a3a9 in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x00007fc47fa6b7a8 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x000000000066186e in death (sig=<optimized out>) at tools.cc:356
No locals.
#3  <signal handler called>
No symbol table info available.
#4  0x00007fc45cfc8bb0 in Adapter::Xaction::noteVbContentDone (this=0x25c8cb0, atEnd=<optimized out>) at adapter_gzip.cc:533
No locals.
#5  0x00000000007eff28 in Adaptation::Ecap::XactionRep::noteBodyProductionEnded (this=0x25bd928, bp=...) at XactionRep.cc:657
No locals.
#6  0x000000000057332d in UnaryMemFunT<BodyConsumer, RefCount<BodyPipe>, RefCount<BodyPipe> >::doDial (this=0x261c880) at base/AsyncJobCalls.h:121
No locals.
#7  0x00000000005737f9 in JobDialer<BodyConsumer>::dial (this=0x261c880, call=...) at base/AsyncJobCalls.h:174
        __FUNCTION__ = "dial"
#8  0x00000000006e45a7 in AsyncCall::make (this=0x261c850) at AsyncCall.cc:40
        __FUNCTION__ = "make"
#9  0x00000000006e8722 in AsyncCallQueue::fireNext (this=this@entry=0x1d94e20) at AsyncCallQueue.cc:56
        call = {p_ = 0x261c850}
        __FUNCTION__ = "fireNext"
#10 0x00000000006e8b60 in AsyncCallQueue::fire (this=0x1d94e20) at AsyncCallQueue.cc:42
        made = true
#11 0x000000000058b109 in dispatchCalls (this=0x7ffd7f0c0e20) at EventLoop.cc:143
        dispatchedSome = <optimized out>
#12 EventLoop::runOnce (this=this@entry=0x7ffd7f0c0e20) at EventLoop.cc:120
        sawActivity = <optimized out>
        waitingEngine = 0x7ffd7f0c0db0
#13 0x000000000058b1f0 in EventLoop::run (this=0x7ffd7f0c0e20) at EventLoop.cc:82
No locals.
#14 0x00000000005ee425 in SquidMain (argc=<optimized out>, argv=<optimized out>) at main.cc:1541
        __FUNCTION__ = "SquidMain"
        signalEngine = {<AsyncEngine> = {_vptr.AsyncEngine = 0x8829d0 <vtable for SignalEngine+16>}, <No data fields>}
        store_engine = {<AsyncEngine> = {_vptr.AsyncEngine = 0x882990 <vtable for StoreRootEngine+16>}, <No data fields>}
        comm_engine = {<AsyncEngine> = {_vptr.AsyncEngine = 0xb68ab0 <vtable for CommSelectEngine+16>}, <No data fields>}
        mainLoop = {errcount = 0, static Running = 0x7ffd7f0c0e20, last_loop = false, engines = {<std::_Vector_base<AsyncEngine*, std::allocator<AsyncEngine*> >> = {
              _M_impl = {<std::allocator<AsyncEngine*>> = {<__gnu_cxx::new_allocator<AsyncEngine*>> = {<No data fields>}, <No data fields>}, _M_start = 0x2202150, _M_finish = 0x2202170,
                _M_end_of_storage = 0x2202170}}, <No data fields>}, timeService = 0x7ffd7f0c0dc0, primaryEngine = 0x7ffd7f0c0db0, loop_delay = 0, error = false, runOnceResult = false}
        time_engine = {_vptr.TimeEngine = 0x892550 <vtable for TimeEngine+16>}
#15 0x00000000005082cb in SquidMainSafe (argv=<optimized out>, argc=<optimized out>) at main.cc:1265
No locals.
#16 main (argc=<optimized out>, argv=<optimized out>) at main.cc:1258
No locals.
(gdb)                                                                                                                                                                                                                                                                                                                                                                                                                                  
8<-----------------------------------------------------------------------------------------------------------------------------------------

Warm Regards,
Bug Reporter Contributor OpenSource = Open-Minded
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

Yuri Voinov
Yup, seems this is

http://bugs.squid-cache.org/show_bug.cgi?id=4597


10.07.2017 13:45, bugreporter пишет:

> Hi Yuri
> ,
> Below the gdb backtrace. I hope that it could help you resolving the issue.
>
> Regarding Squid-4.0 my understanding is that it is a beta version while I
> need a stable version. Actually at this stage upgrading to 4.0  would
> represent a lot of integration, testing and validation work. Therefore,
> either I abandon the idea to have ecap and icap at the same time or the bug
> can be fixed (or at least we can find a workaround).
>
> 8<-----------------------------------------------------------------------------------------------------------------------------------------
> GNU gdb (GDB) 7.5
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /sbin/squid...done.
> [New LWP 4452]
>
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> Core was generated by `(squid-1) -f /etc/squid.conf'.
> Program terminated with signal 6, Aborted.
> #0  0x00007fc47fa6a3a9 in raise () from /lib/libc.so.6
> (gdb) bt full
> #0  0x00007fc47fa6a3a9 in raise () from /lib/libc.so.6
> No symbol table info available.
> #1  0x00007fc47fa6b7a8 in abort () from /lib/libc.so.6
> No symbol table info available.
> #2  0x000000000066186e in death (sig=<optimized out>) at tools.cc:356
> No locals.
> #3  <signal handler called>
> No symbol table info available.
> #4  0x00007fc45cfc8bb0 in Adapter::Xaction::noteVbContentDone
> (this=0x25c8cb0, atEnd=<optimized out>) at adapter_gzip.cc:533
> No locals.
> #5  0x00000000007eff28 in
> Adaptation::Ecap::XactionRep::noteBodyProductionEnded (this=0x25bd928,
> bp=...) at XactionRep.cc:657
> No locals.
> #6  0x000000000057332d in UnaryMemFunT<BodyConsumer, RefCount&lt;BodyPipe>,
> RefCount<BodyPipe> >::doDial (this=0x261c880) at base/AsyncJobCalls.h:121
> No locals.
> #7  0x00000000005737f9 in JobDialer<BodyConsumer>::dial (this=0x261c880,
> call=...) at base/AsyncJobCalls.h:174
>          __FUNCTION__ = "dial"
> #8  0x00000000006e45a7 in AsyncCall::make (this=0x261c850) at
> AsyncCall.cc:40
>          __FUNCTION__ = "make"
> #9  0x00000000006e8722 in AsyncCallQueue::fireNext
> (this=this@entry=0x1d94e20) at AsyncCallQueue.cc:56
>          call = {p_ = 0x261c850}
>          __FUNCTION__ = "fireNext"
> #10 0x00000000006e8b60 in AsyncCallQueue::fire (this=0x1d94e20) at
> AsyncCallQueue.cc:42
>          made = true
> #11 0x000000000058b109 in dispatchCalls (this=0x7ffd7f0c0e20) at
> EventLoop.cc:143
>          dispatchedSome = <optimized out>
> #12 EventLoop::runOnce (this=this@entry=0x7ffd7f0c0e20) at EventLoop.cc:120
>          sawActivity = <optimized out>
>          waitingEngine = 0x7ffd7f0c0db0
> #13 0x000000000058b1f0 in EventLoop::run (this=0x7ffd7f0c0e20) at
> EventLoop.cc:82
> No locals.
> #14 0x00000000005ee425 in SquidMain (argc=<optimized out>, argv=<optimized
> out>) at main.cc:1541
>          __FUNCTION__ = "SquidMain"
>          signalEngine = {<AsyncEngine> = {_vptr.AsyncEngine = 0x8829d0
> <vtable for SignalEngine+16>}, <No data fields>}
>          store_engine = {<AsyncEngine> = {_vptr.AsyncEngine = 0x882990
> <vtable for StoreRootEngine+16>}, <No data fields>}
>          comm_engine = {<AsyncEngine> = {_vptr.AsyncEngine = 0xb68ab0 <vtable
> for CommSelectEngine+16>}, <No data fields>}
>          mainLoop = {errcount = 0, static Running = 0x7ffd7f0c0e20, last_loop
> = false, engines = {<std::_Vector_base&lt;AsyncEngine*,
> std::allocator&lt;AsyncEngine*> >> = {
>                _M_impl = {<std::allocator&lt;AsyncEngine*>> =
> {<__gnu_cxx::new_allocator<AsyncEngine*>> = {<No data fields>}, <No data
> fields>}, _M_start = 0x2202150, _M_finish = 0x2202170,
>                  _M_end_of_storage = 0x2202170}}, <No data fields>},
> timeService = 0x7ffd7f0c0dc0, primaryEngine = 0x7ffd7f0c0db0, loop_delay =
> 0, error = false, runOnceResult = false}
>          time_engine = {_vptr.TimeEngine = 0x892550 <vtable for
> TimeEngine+16>}
> #15 0x00000000005082cb in SquidMainSafe (argv=<optimized out>,
> argc=<optimized out>) at main.cc:1265
> No locals.
> #16 main (argc=<optimized out>, argv=<optimized out>) at main.cc:1258
> No locals.
> (gdb)
> 8<-----------------------------------------------------------------------------------------------------------------------------------------
>
> Warm Regards,
>
>
>
>
> -----
> Bug Reporter Contributor
> OpenSource = Open-Minded
> --
> View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Chaining-icap-and-ecap-services-FATAL-Received-Segment-Violation-dying-tp4683033p4683042.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users

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

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

Alex Rousskov
In reply to this post by bugreporter
On 07/09/2017 10:59 AM, bugreporter wrote:

> Is it allowed (supported) to chain icap and ecap services (using
> /adaptation_service_chain/)?

Yes, it is allowed and supported.


> I get a "FATAL: Received Segment
> Violation...dying." when trying to do it with some websites (www.linguee.com
> for instance). Each of those services works very well separately.

AFAICT, the bug is most likely in the eCAP adapter that you are using.
Yes, I understand that the same adapter seems to work OK in other
configurations. The Squid Project cannot help you with fixing that
unofficial adapter. Your options include finding somebody who can fix
the broken adapter, replacing that broken adapter with something better,
or not using the adapter at all.

The above conclusion is based on all the information you have provided
so far (thank you!). If you discover new information that points the
finger back at Squid, consider filing a Squid bug report with that new
information. I do not recommend using bug #4597 for your problem because
the stack traces look different, you are using rather than disabling
ICAP, and your are using Linux rather than Solaris.

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

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

bugreporter
In reply to this post by Yuri Voinov
Thank you Yuri,

The least I can say is that the conversation at http://bugs.squid-cache.org/show_bug.cgi?id=4597 makes me laugh a lot. My opinion is that if you modify the source code of an open source program without publishing your modifications your are in contradiction with GPL v2. Your sponsor may have serious blame from the open source community (and also legal problems). 10 days of hard working is not nothing and I can understand your position. But What do you think that we do all of us (open source developers) ? My own Open Source project represents 1700 days of (very) hard working... But I always respect the GPL.

Anyway... Thank you for your help. At least, now I'm not going to investigate for nothing.

Kind Regards,
Bug Reporter Contributor OpenSource = Open-Minded
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

bugreporter
In reply to this post by Alex Rousskov
Hi Alex,

Thank you for your post. I do appreciate your help and recommendations.

By chance, do you know another adapter that I can use to replace squid-ecap-gzip. Actually I'm looking for an adapter capable to compress HTTP contents.

Warm Reagrds,
Bug Reporter Contributor OpenSource = Open-Minded
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

Antony Stone
In reply to this post by bugreporter
On Wednesday 12 July 2017 at 10:55:36, bugreporter wrote:

> Thank you Yuri,
>
> The least I can say is that the conversation at
> http://bugs.squid-cache.org/show_bug.cgi?id=4597 makes me laugh a lot. My
> opinion is that if you modify the source code of an open source program
> without publishing your modifications your are in contradiction with GPL
> v2.

That depends entirely on whether the modified version has been distributed or
not.

If whoever has done the modifications uses the modified version only for their
own use, that is entirely in keeping with the GPL.

The GPL only says that you must make available the source code of your
modifications for any modified version which you distribute to others.

> Your sponsor may have *serious blame* from the open source community
> (and also *legal problems*). 10 days of hard working is not nothing and I
> can understand your position. But What do you think that we do all of us
> (open source developers) ? My own Open Source project represents 1700 days
> of (very) hard working... But I always respect the GPL.

Please read it more closely, specifically sections 2 and 6, paying attention to
the word "distribute".

https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html


Regards,


Antony.

--
Pavlov is in the pub enjoying a pint.
The barman rings for last orders, and Pavlov jumps up exclaiming "Damn!  I
forgot to feed the dog!"

                                                   Please reply to the list;
                                                         please *don't* CC me.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

Alex Rousskov
In reply to this post by bugreporter
On 07/12/2017 04:01 AM, bugreporter wrote:

> By chance, do you know another adapter that I can use to replace
> squid-ecap-gzip. Actually I'm looking for an adapter capable to compress
> HTTP contents.

I do not know of any free adapters that do that. FWIW, one of the
Factory adapters can be configured to compress message bodies, but the
primary purpose of that adapter is content injection, and I am not 100%
sure that it works well for pure compression purposes (because nobody I
know deploys that adapter for those purposes).

Please feel free to post an RFP to the eCAP Users list:
http://www.e-cap.org/Support

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

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

bugreporter
In reply to this post by Antony Stone
Hi Antony,

If they effectively don't distribute their modifications... But we don't know. Thank you so much for the clarification.

Kind Regards,
Bug Reporter Contributor OpenSource = Open-Minded
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

Yuri Voinov


13.07.2017 5:13, bugreporter пишет:
> Hi Antony,
>
> If they effectively don't *distribute* their modifications... But we don't
> know. Thank you so much for the clarification.
We're not so brainless. Even we not threat GPL as religious dogma, we're
never distribute our solutions. Especially, as I said, this seems as
very close platform-specific (and platform is marginal), also, in fact,
this bug is gone in later branches. So we're don't care on this bug.

>
> Kind Regards,
>
>
>
> -----
> Bug Reporter Contributor
> OpenSource = Open-Minded
> --
> View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Chaining-icap-and-ecap-services-FATAL-Received-Segment-Violation-dying-tp4683033p4683087.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

Yuri Voinov
In reply to this post by bugreporter


13.07.2017 5:13, bugreporter пишет:
> Hi Antony,
>
> If they effectively don't *distribute* their modifications... But we don't
> know. Thank you so much for the clarification.
And in general, making such statements, you need to be ready to prove
them in court.

When you can prove that we are distributing software for commercial
purposes with patches that are not given to the community, then you will
throw such statements.

Until this is proven - I suggest you apologize.

>
> Kind Regards,
>
>
>
> -----
> Bug Reporter Contributor
> OpenSource = Open-Minded
> --
> View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Chaining-icap-and-ecap-services-FATAL-Received-Segment-Violation-dying-tp4683033p4683087.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

bugreporter
Dear Yuri,

My goal is not to hurt anybody here and if you consider that I offended you (or rather your "sponsor") I apologize. So sorry! The fact of the matter is that the conversation at http://bugs.squid-cache.org/show_bug.cgi?id=4597 caught my attention and it was the first time I saw such a discussion on an open source technical forum.

Thanks to you and exchanges with others I understand better the GPL today.

Kind Regards,
Bug Reporter Contributor OpenSource = Open-Minded
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

Yuri Voinov
Apologies are accepted. No problems. We ourselves were not pleased that
we did not have enough time to write the correct and beautiful patch. At
that time it was quite an unpleasant problem. The bottom line is that
it's very specific and for me it's a big surprise that something similar
happened again on another platform. Fortunately, on current versions
there is no problem.


13.07.2017 13:38, bugreporter пишет:

> Dear Yuri,
>
> My goal is not to hurt anybody here and if you consider that I offended you
> (or rather your "sponsor") I apologize. So sorry! The fact of the matter is
> that the conversation at http://bugs.squid-cache.org/show_bug.cgi?id=4597
> caught my attention and it was the first time I saw such a discussion on an
> open source technical forum.
>
> Thanks to you and exchanges with others I understand better the GPL today.
>
> Kind Regards,
>
>
>
> -----
> Bug Reporter Contributor
> OpenSource = Open-Minded
> --
> View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Chaining-icap-and-ecap-services-FATAL-Received-Segment-Violation-dying-tp4683033p4683090.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Chaining icap and ecap services - FATAL: Received Segment Violation...dying.

bugreporter
I can fully understand!
Warm Regards,
Bug Reporter Contributor OpenSource = Open-Minded
12
Loading...