From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120187 invoked by alias); 18 Nov 2019 20:33:33 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 120176 invoked by uid 89); 18 Nov 2019 20:33:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=multithreaded X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Nov 2019 20:33:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574109210; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=f/9lvNAMnRs9wWC+lytZbAfMU13Qyxw5POOi1z5RkEw=; b=BaimVR1sgRDDex24i4Z5y+g4zjClUFQE1vQU7UKIQy84OzGodI4KPfFmxQOoCgj2FBurdJ BE1Iy5MMnzxiu+9yUSGB+LoUxWlUdYLddtJUjGdw64aBt0FAuf+P4Id5iVm2wTwfRk750G p7cPGnOpUsh3upgPrZE9nknXgbaI+vI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-156-5Io1jutGMJqfUugOBM7WPg-1; Mon, 18 Nov 2019 15:33:27 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 21BA91005509; Mon, 18 Nov 2019 20:33:26 +0000 (UTC) Received: from redhat.com (ovpn-116-19.phx2.redhat.com [10.3.116.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 016816106D; Mon, 18 Nov 2019 20:33:25 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.92) (envelope-from ) id 1iWni8-0001AN-8e; Mon, 18 Nov 2019 15:33:24 -0500 Date: Mon, 18 Nov 2019 20:33:00 -0000 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: elfutils-devel@sourceware.org, amerey@redhat.com Subject: Re: patch 1/2 debuginfod client Message-ID: <20191118203324.GD2880@redhat.com> References: <20191028190438.GC14349@redhat.com> <20191028190602.GD14349@redhat.com> <9bc154bce6389be9b07f2db9dcdcc605ad4f39e3.camel@klomp.org> <20191113232456.GA31583@redhat.com> <6d7430368a18c943f72bc3583efeafb2c192516f.camel@klomp.org> <20191116185256.GB19543@redhat.com> <356e88e4937ddb97a3e7cc93dbdfe29239ff960e.camel@klomp.org> MIME-Version: 1.0 In-Reply-To: <356e88e4937ddb97a3e7cc93dbdfe29239ff960e.camel@klomp.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-MC-Unique: 5Io1jutGMJqfUugOBM7WPg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00177.txt.bz2 Hi - > > > But since the user won't see the URL generated they might not notice > > > what is really going on. They will just see that something wasn't > > > found, won't they? > >=20 > > Yes, so the only benefit would be the generation of a different error > > message for impossible buildids. >=20 > But if there are multiple server URLs it might not be clear which/where > the error came from.=20 (My comment was about detecting even number of chars in the hex code.) > Since all this is done through a very simple web > api I think it is useful for the user to get informed about what the > actual request URL was that failed. [...] > If we go with the client connection context idea for the API we could > add an extra function that would tell you the last URL tried maybe? Yeah, maybe. They are tried in parallel. We could also hook up to libcurl's own progress-notification callbacks. > > > Do you know how other libraries that use libcurl deal with this? > >=20 > > I looked over some other libcurl users in fedora. Some don't worry > > about the issue at all, relying on implicit initialization, which is > > only safe if single-threaded. Others (libvirtd) do an explicitly > > invoked initialization function, which is also only safe if invoked > > from a single-threaded context. > >=20 > > I think actually our way here, running the init function from the > > shared library constructor, is about the best possible. As long as > > the ld.so process is done as normal, it should be fine. Programs that > > use the elfutils trick of manual dlopen'ing libdebuginfod.so should do > > so only if they are single-threaded. >=20 > But they cannot really control that... Since they might not know (and > really shouldn't care) that libdw lazily tries to dlopen > libdebuginfod.so which then pulls in libcurl and calls that global init > function... >=20 > Could we do try to do the dlopen and global curl initialization from > libdw _init, or a ctor, to make sure it is done as early as possible?=20 Doing a redundant initialization later is not a problem; there is a counter in there. The problematic case would be - a multithreaded application - loading debuginfod.so multiply concurrently somehow - and calling the solib ctor concurrently somehow - and all of this concurrently enough to defeat libcurl's init-counter IMHO, not worth worrying about. Someday libcurl will do the right thing (tm) and plop this initialization into their solib ctor. > > > I was more thinking zero =3D=3D infinity (no timeout). > >=20 > > An unset environment variable should do that. >=20 > Are you sure? If DEBUGINFOD_TIMEOUT isn't set, then it seems it > defaults to 5 seconds: >=20 > /* Timeout for debuginfods, in seconds. > This env var must be set for debuginfod-client to run. */ > static const char *server_timeout_envvar =3D DEBUGINFOD_TIMEOUT_ENV_VAR; > static int server_timeout =3D 5; > [...] >=20 > if (getenv(server_timeout_envvar)) > server_timeout =3D atoi (getenv(server_timeout_envvar)); OK, hm, we could make an -empty- but set environment variable mean 'infinity'. Then again, a user can also say =3D99999. - FChE