From owner-freebsd-stable@FreeBSD.ORG Mon Feb 10 07:15:46 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4942CE13; Mon, 10 Feb 2014 07:15:46 +0000 (UTC) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D35271BD0; Mon, 10 Feb 2014 07:15:45 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id ie18so4538305vcb.12 for ; Sun, 09 Feb 2014 23:15:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qIZZI231tKdzlaEzzDjBkS1aYnbQGD/4YdQGZVrcJ+0=; b=cV/FKBAom3cfXlQR/m9OBnoCcj2UMdY57i94LTZafcUCS61PyyAAHxOYa6x4/7Y9Zs YII4l9sEesmqsWU4uQT1SUgtBlOlKy32aghRGbNlEyOJHj/lZSP0NwzE0Y/0mJc5VOu3 GhXg7asKAgr0RLz2SUX0XIar8DOvJ18dbd3e4vAyRpOEFFmH+naDrQ56+37IvdRlqjzT kNhNr/Mt6OUMLgAURm6dXOlB/hp17QTyywN0MJynoiL8vnuy7D6t3NFktEkngOHDgpRt N06KH7xV1w5RuScqjCawgn8c0IMUwoC6LC6nHjUVbnGWdCusp32SPRhPsxFhmDF77WDe Bj8Q== MIME-Version: 1.0 X-Received: by 10.58.235.129 with SMTP id um1mr23172461vec.17.1392016544035; Sun, 09 Feb 2014 23:15:44 -0800 (PST) Received: by 10.52.171.80 with HTTP; Sun, 9 Feb 2014 23:15:43 -0800 (PST) In-Reply-To: <0760EB34-0EE7-4519-AF2F-63C0FDC4D8C5@FreeBSD.org> References: <92705E1C-E06E-411D-B88C-5A1AA096E2BD@FreeBSD.org> <1391973419.88145.103.camel@btw.pki2.com> <0760EB34-0EE7-4519-AF2F-63C0FDC4D8C5@FreeBSD.org> Date: Mon, 10 Feb 2014 11:15:43 +0400 Message-ID: Subject: Re: Squid aufs crashes under 10.0 From: Pavel Timofeev To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable stable , Dennis Glatting , ports-list freebsd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 07:15:46 -0000 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. 2014-02-09 23:56 GMT+04:00 Dimitry Andric : > On 09 Feb 2014, at 20:16, Dennis Glatting 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 > > >