Hi! There is a problem with squid under FreeBSD10.0. Squid crashes immediately if storage type is set to aufs. It goes down during read of config file. No problem with diskd. No problem with aufs under FreeBSD9.2. Someone thinks that it's related to clang which is default compiler on FreeBSD 10.0. I recompiled www/squid33 with DEBUG option. Got coredump. Then I did and got this: gdb /usr/local/sbin/squid /var/squid/squid.core .... Reading symbols from /usr/lib/private/libheimipcc.so.11...done. Loaded symbols for /usr/lib/private/libheimipcc.so.11 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 Segmentation fault (core dumped) Gdb goes down too =) Any ideas?
Sorry, it has to be in freebsd-ports@ too. 2014-02-07 Pavel Timofeev <timp87 at gmail.com>:> Hi! > There is a problem with squid under FreeBSD10.0. > Squid crashes immediately if storage type is set to aufs. > It goes down during read of config file. > > No problem with diskd. No problem with aufs under FreeBSD9.2. > > Someone thinks that it's related to clang which is default compiler on > FreeBSD 10.0. > > I recompiled www/squid33 with DEBUG option. Got coredump. > Then I did and got this: > gdb /usr/local/sbin/squid /var/squid/squid.core > .... > Reading symbols from /usr/lib/private/libheimipcc.so.11...done. > Loaded symbols for /usr/lib/private/libheimipcc.so.11 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > Segmentation fault (core dumped) > > Gdb goes down too =) > Any ideas?
There are several problems with Squid source with one of the most significant in "debug." Specifically, there are print statements using cstring that DO NOT manage the case where cstring is empty (i.e., c_str() returns NULL) thereby producing SIGSEV. There are also a cases where strlen() is called with a NULL pointer, also causing SIGSEV. I have ported 3.4 to FreeBSD and I have patches available here. Some bugs are fixed, others not; However, I am running this code on two busy sites. http://www.pki2.com/squid34.tar I posted this stuff to ports@ but no response (it's a hack of the 3.3 Makefile, files, etc, but I'm not a ports commiter, for the sake of others :)). I believe aufs code is broken. I don't use it so I DID NOT try to figure out why. For certain the Rock Store code is broken. Note that I used clang++ 3.3 c++11. On Fri, 2014-02-07 at 17:17 +0400, Pavel Timofeev wrote:> Hi! > There is a problem with squid under FreeBSD10.0. > Squid crashes immediately if storage type is set to aufs. > It goes down during read of config file. > > No problem with diskd. No problem with aufs under FreeBSD9.2. > > Someone thinks that it's related to clang which is default compiler on > FreeBSD 10.0. > > I recompiled www/squid33 with DEBUG option. Got coredump. > Then I did and got this: > gdb /usr/local/sbin/squid /var/squid/squid.core > .... > Reading symbols from /usr/lib/private/libheimipcc.so.11...done. > Loaded symbols for /usr/lib/private/libheimipcc.so.11 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > Segmentation fault (core dumped) > > Gdb goes down too =) > Any ideas? > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"-- Dennis Glatting <dg at pki2.com>
Oh, and for fun it also compiles under clang++ 3.4 c++11. I don't recall trying g++ 4.8 or 4.9.
07.02.2014 15:17, Pavel Timofeev wrote:> Hi! > There is a problem with squid under FreeBSD10.0. > Squid crashes immediately if storage type is set to aufs. > It goes down during read of config file. > > No problem with diskd. No problem with aufs under FreeBSD9.2. > > Someone thinks that it's related to clang which is default compiler on > FreeBSD 10.0. > > I recompiled www/squid33 with DEBUG option. Got coredump. > Then I did and got this: > gdb /usr/local/sbin/squid /var/squid/squid.core > ..... > Reading symbols from /usr/lib/private/libheimipcc.so.11...done. > Loaded symbols for /usr/lib/private/libheimipcc.so.11 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > Segmentation fault (core dumped) > > Gdb goes down too =) > Any ideas?Well... I'd just like to share some thoughts and facts: * aufs is not asynchronous anymore, it uses threads now; * diskd is highly experimental, broken and I suppose noone would fix it as it all comes down to incorrect prerequisites when planning this datastore internals; * rock is not working. Besides that ufs is still stable and usable. And fast. -- Sphinx of black quartz, judge my vow.