Date: Mon, 10 Feb 2014 07:21:15 -0800 From: Dennis Glatting <freebsd@pki2.com> To: Pavel Timofeev <timp87@gmail.com> Cc: freebsd-stable stable <freebsd-stable@freebsd.org>, Dimitry Andric <dim@freebsd.org>, ports-list freebsd <freebsd-ports@freebsd.org> Subject: Re: Squid aufs crashes under 10.0 Message-ID: <1392045675.20238.9.camel@btw.pki2.com> In-Reply-To: <CAAoTqftQJzg%2B=H5B1B3_fF7Ho6afMRUxGkcmytR-PfP3H2%2BE2A@mail.gmail.com> References: <CAAoTqfv7fdPocAS8aywRiwCtiQhW%2BWR3Xpmk0rx7fLRsdbm88Q@mail.gmail.com> <CAAoTqfsH9HVgNqxHvKndANT=xU14D-DTLZagJ_yWBC2UqiYN9Q@mail.gmail.com> <92705E1C-E06E-411D-B88C-5A1AA096E2BD@FreeBSD.org> <1391973419.88145.103.camel@btw.pki2.com> <0760EB34-0EE7-4519-AF2F-63C0FDC4D8C5@FreeBSD.org> <CAAoTqftQJzg%2B=H5B1B3_fF7Ho6afMRUxGkcmytR-PfP3H2%2BE2A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2014-02-10 at 11:15 +0400, Pavel Timofeev wrote:
> So what should I do?
> Write a PR to squid's bugzilla with link to this thread?
> Fill FreeBSD ports' PR? (it seems like maintainer of squid doesn't
> look at PRs about squid).
> And it seems like this problem is retaled to all of squid ports, not
> only to www/squid33.
>
Good question. I don't know. I ported 3.4 and sent email to the
maintainer and to the list. Zip in response.
My 3.4 patch to the Makefile, based on the 3.3 Makefile, are specific to
FreeBSD 10 and clang++ std=c++11 but I'm not a ports Makefile hack (it
leaves me bewildered at times) and that patch reflects it. Tutoring may
be required. :)
Dimitry's insight to cstring was insightful but that needs to be fed
back to the Squid developers.
I recall compiling 3.4 using GCC 4.8 and 4.9 but I don't recall the
results.
> 2014-02-09 23:56 GMT+04:00 Dimitry Andric <dim@freebsd.org>:
> > On 09 Feb 2014, at 20:16, Dennis Glatting <freebsd@pki2.com> wrote:
> >> On Sun, 2014-02-09 at 19:37 +0100, Dimitry Andric wrote:
> > ...
> >>> 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.
> >
> > There are a bunch of places where they use std::ostream::operator<< to
> > output e.g. configuration strings to the debug stream, for example in
> > uniqueHostname(), in src/tools.cc:
> >
> > const char *
> > uniqueHostname(void)
> > {
> > debugs(21, 3, HERE << " Config: '" << Config.uniqueHostname << "'");
> > return Config.uniqueHostname ? Config.uniqueHostname : getMyHostname();
> > }
> >
> > The problem case is when Config.uniqueHostname is NULL: this gets
> > converted into a std::string first (which is _undefined behavior_), then
> > it gets streamed to the debug stream.
> >
> > However, there is a difference between libstdc++ and libc++ here: the
> > former silently accepts NULL arguments passed to the std::string
> > constructor, creating a sort of "empty" string for you, which seems to
> > work as normal. The latter just stores your NULL pointer, and if you
> > actually try to do anything with it, the program will crash.
> >
> > To fix at least two places where this is done, drop the attached patches
> > in www/squid33/files.
> >
> > -Dimitry
> >
> >
> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1392045675.20238.9.camel>