Amos, thank you for the really quick response! I will try the patch and wait what other informations I get with the next crash. Bug 3177 filed. Martin Amos Jeffries <squid3@xxxxxxxxxxxxx> schrieb am 16.03.2011 15:01:00: > Von: Amos Jeffries <squid3@xxxxxxxxxxxxx> > An: squid-users@xxxxxxxxxxxxxxx > Datum: 16.03.2011 15:02 > Betreff: Re: WG: squid 3.1.11 --asserts with FTP traffic > > On 17/03/11 02:00, Martin.Pichlmaier@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote: > > > > Hello list, > > > > I finally upgraded my old squid-3.0.STABLE25 installations to > > squid-3.1.10 / 3.1.11 on RedHat AS5. > > > > But now I have some asserts: > > > > 2011/03/16 09:47:50| comm_old_accept: FD 2196: (22) Invalid argument > > 2011/03/16 09:47:50| FTP data connection from unexpected server ([::]), > > expecting 65.44.170.164 > > 2011/03/16 09:47:50| assertion failed: comm.cc:1583: "fd>= 0" > > 2011/03/16 09:47:53| Starting Squid Cache version 3.1.11 for > > x86_64-unknown-linux-gnu... > > 2011/03/16 09:47:53| Process ID 10749 > > 2011/03/16 09:47:53| With 16384 file descriptors available > > 2011/03/16 09:47:53| Initializing IP Cache... > > 2011/03/16 09:47:53| DNS Socket created at [::], FD 7 > > 2011/03/16 09:47:53| DNS Socket created at 0.0.0.0, FD 8 > > ..... > > > > I saw this five times today, always with the same "FTP data connection from > > unexpected server...", > > always the same FTP server IP. > > No entry in the access.log, probably because squid crashed before it could > > log the connection. > > No special logs in cache.log before the assert. > > Proxies are configured as forward proxies. > > ----------------- > > # grep assert cache.log > > 2011/03/16 09:47:24| assertion failed: comm.cc:1583: "fd>= 0" > > 2011/03/16 09:47:50| assertion failed: comm.cc:1583: "fd>= 0" > > 2011/03/16 09:48:11| assertion failed: comm.cc:1583: "fd>= 0" > > 2011/03/16 11:01:54| assertion failed: comm.cc:1583: "fd>= 0" > > 2011/03/16 11:02:24| assertion failed: comm.cc:1583: "fd>= 0" > > ----------------- > > I checked the old logs, connections to that server 65.44.170.164 > > (ftp.dspaceinc.com) worked with 3.0, > > but always crashed my 3.1.10 and 3.1.11 servers. > > > > Unfortunately I do not yet have a coredump and therefore no gdb backtrace. > > As the FTP site does not allow anonymous FTP access I cannot yet reproduce > > the error myself > > and I have not yet found the user who tried to access this URL. > > > > Has anyone an idea what could cause this? > > > The assert is a bug to do with closing a not-open FD. The attached patch > should fix that so we can get some better info on the main problem. > Patch is on 3.1.11 snapshot, but should apply to either version. > > > Somehow Squid is failing to pick up the remote-end IP address of a > received FTP data connection. > > The FTP server needs to be in "active" mode for data connections in > order to hit any of this code. That may be all that is needed for you to > replicate. > > If you can get a backtrace, a dump of the "io" object will be needed. > And please report this all to bugzilla so it does not get lost. > > > Amos > -- > Please be using > Current Stable Squid 2.7.STABLE9 or 3.1.11 > Beta testers wanted for 3.2.0.5 > [Anhang "ftp_crash.patch" gelöscht von Martin Pichlmaier/usr/cag]