Thanks Henrik. -D_FILE_OFFSET_BITS=64 worked for me. Thank you very much. -----Original Message----- From: Henrik Nordstrom <henrik@xxxxxxxxxxxxxxxxxxx> To: juris.krumins@xxxxxxx Cc: squid-users@xxxxxxxxxxxxxxx Subject: Re: Failed download files larger that 2GB through proxy with ICAP. Date: Thu, 20 Aug 2009 13:41:53 +0200 tor 2009-08-20 klockan 11:59 +0300 skrev Juris Krumins: > Following your suggestion I've captured traffic betwen ICAP and Squid. > 11:11:05.864532 IP 127.0.0.1.49824 > 127.0.0.1.1345: P > 2157719238:2157723337(4099) ack 2156830511 win 28786 <nop,nop,timestamp > 1727787390 1727787383> Squid sends data to the ICAP server. > 11:11:05.877022 IP 127.0.0.1.1345 > 127.0.0.1.49824: R > 2156830511:2156830511(0) ack 2157723337 win 30720 <nop,nop,timestamp > 1727787403 1727787387> ICAP server aborts with a TCP Reset, abnormally terminating the transaction. > 3) ICAP server logs following > The child 13559 not exited normaly.signaled with signal:25 > > Signal 25 is SIGXFSZ and man 7 signal shows us that: > SIGXFSZ 25,25,31 Core File size limit exceeded (4.2BSD) Heh, there you go ;-) > So theoretically ICAP process/subprocess have to create core file > (because of default action specified in standart). > But I can't find it unfortunatelly. It does not need to dump core. Depends on many factors. And is not needed either as it's very obvious what happened. You ran an 32-bit application trying to store more than 2G of data in a file without being compiled with LFS support. 2GB = 2^(32-1) bytes and is the limit on what the POSIX file I/O API can handle in 32-bit mode. Fix: Recompile the ICAP server with LFS support (64-bit file I/O), or move to a 64-bit OS if supported by CPU and forget all of these 32-bit issues... REgards Henrik
