From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3532 invoked by alias); 20 Dec 2019 18:39:45 -0000 Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-locales-owner@sourceware.org Received: (qmail 3448 invoked by uid 89); 20 Dec 2019 18:39:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576867181; 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=yyqOECho7ZA7pgRoqjHIybMDb+JYX2NXAsCT8LuDMSY=; b=aivu4XiI5QLeFZkFxE1kt9GDEue3MSCNbT0ONNQNninjyadMgb5bnhmOckt0hKO8uqykrp LImvJhzFiHM5j/X/NqhtCRKrC3M4kznxGwocwXd+FkDi5DOK9KsPOyEolFXls8ztXy0T/E qwsFET0PkNK2ug5KEi+W9vE9W10QBXs= From: Florian Weimer To: Abhidnya Joshi Cc: libc-locales@sourceware.org Subject: Re: Crash in gconv_db.c References: <87bltiv10t.fsf@oldenburg2.str.redhat.com> <877e42cqfo.fsf@oldenburg2.str.redhat.com> <875ziledsy.fsf@oldenburg2.str.redhat.com> <87mubngh8e.fsf@oldenburg2.str.redhat.com> <8736dfgfyo.fsf@oldenburg2.str.redhat.com> <87r20zf07d.fsf@oldenburg2.str.redhat.com> <87lfr7eyg0.fsf@oldenburg2.str.redhat.com> Date: Fri, 20 Dec 2019 18:39:00 -0000 In-Reply-To: (Abhidnya Joshi's message of "Fri, 20 Dec 2019 22:48:44 +0530") Message-ID: <87h81ug7tj.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-q4/txt/msg00103.txt.bz2 * Abhidnya Joshi: > I checked for gconv-modules.cache. I do not see that at all in > /usr/lib64/gconv . > Also the environment variable is not set. Is there a possibility that > cache is not at all getting enabled? Yes, distributions usually run iconvconfig during the installation to create the cache. I'm pretty sure that enabling the cache will paper over this bug, otherwise it would have been reported before. With caching enable, the counters should remain constant at 1. Thanks, Florian