Squid aufs crashes under 10.0

[Dennis Glatting]

On Sun, 2014-02-09 at 19:37 +0100, Dimitry Andric wrote:
> On 07 Feb 2014, at 14:24, Pavel Timofeev <timp87 at gmail.com> wrote:
> > 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.
> 
> Nope, it is a bug in Squid's configure script.  It recognizes FreeBSD
> 10.x and later as FreeBSD 1.x, causing it to disable pthreads support.
> This leads to the required DiskThreads module being disabled too.  It
> then crashes when it tries to access a NULL pointer returned by
> DiskIOModule::Find("DiskThreads"), in src/fs/ufs/UFSSwapDir.cc:
> 
> Fs::Ufs::UFSSwapDir::UFSSwapDir(char const *aType, const char *anIOType) : SwapDir(aType), IO(NULL), map(new FileMap()), suggest(0), swaplog_fd (-1), currentIOOptions(new ConfigOptionVector()), ioType(xstrdup(anIOType)), cur_size(0), n_disk_objects(0)
> {
>     /* modulename is only set to disk modules that are built, by configure,
>      * so the Find call should never return NULL here.
>      */
>     IO = new Fs::Ufs::UFSStrategy(DiskIOModule::Find(anIOType)->createStrategy());
> }
> 
> Very bad coding practice, obviously.  It should call Find() first, and
> if that returns NULL, it should abort in some sort of controlled way.
> 

Found that too but not the reason why:

(lldb) run -d -z -F -f /root/squid.conf
Process 23598 launched: './src/squid' (x86_64)
Find(): Mmapped
Find(): IpcIo
Find(): DiskDaemon
Find(): Blocking
Find(): AIO
Returning NULL

There's a lot of faulty (i.e., a lack thereof) checking in Squid. For
example, I replaced strlen() with a custom version that first checks for
NULL and returns 0 if that is the case (strlen() was often called by
std::cstring::c_str() that was not yet initialized). That small code
fragment resolved a lot of SEGVs.


> In any case, the cause is the following fragment in the configure
> script:
> 
>           freebsd)
>             if test `echo "$squid_host_os_version" | cut -b1` -lt 7 ; then
>                 { $as_echo "$as_me:${as_lineno-$LINENO}: pthread library requires FreeBSD 7 or later" >&5
> $as_echo "$as_me: pthread library requires FreeBSD 7 or later" >&6;}
>                 squid_opt_use_diskthreads="no"
>             else
> 
> which was edited here:
> 
> http://bazaar.launchpad.net/~squid/squid/3-trunk/revision/11124
> 
> I have attached a tentative patch for the port.  However, this causes
> the configure script logic to run a little differently, and there is
> some sort of very strange bug in it, that leads to the SQUID_CFLAGS and
> SQUID_CXXFLAGS values being mangled in the default case.
> 
> With my patch the DiskThreads detection runs again, but the variables
> are not mangled anymore, and this leads to -Werror being enabled again,
> causing errors about deprecated kerberos5 functions later on in the
> build.
> 
> For now, I would not bother with -Werror and Squid, but just add
> --disable-strict-error-checking to CONFIGURE_ARGS in the Makefile.
> 
> That is, until somebody with autoconf knowledge can fix the badly broken
> configure script...
> 
> 
> >> 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?
> 
> Yes, please don't use gdb in base for anything serious.  Use ports gdb
> instead. :-)
> 
> -Dimitry