From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-locales-return-6940-listarch-libc-locales=sources.redhat.com@sourceware.org>
Received: (qmail 44588 invoked by alias); 20 Dec 2019 16:09:37 -0000
Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-locales.sourceware.org>
List-Subscribe: <mailto:libc-locales-subscribe@sourceware.org>
List-Post: <mailto:libc-locales@sourceware.org>
List-Help: <mailto:libc-locales-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: libc-locales-owner@sourceware.org
Received: (qmail 44574 invoked by uid 89); 20 Dec 2019 16:09:36 -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=1576858174;
	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=JPjRN9io7Z/0yXPRK3Jmjhu6PkkkUJJd+xif3G3eo+g=;
	b=bckYd5jVLgqz2hXRnQxH4rOeYxzvuR38Y/7UYT8jcv92G9hz40lSzxeY5je4lZy85bEdaT
	XYlguicouIQ1ec3XoYAHIH1YSbozgo2SpOKI4FValwv6OGFnC+UQ8ntiiXmeIftC1HaiC3
	rlHh1fJAurlYFQ/AjYXF4kYNrSX3xZ4=
From: Florian Weimer <fweimer@redhat.com>
To: Abhidnya Joshi <abhidnyachirmule@gmail.com>
Cc: libc-locales@sourceware.org
Subject: Re: Crash in gconv_db.c
References: <CALmqtCWYWMUm51HhL0VM3YgBJagyC8T3uCGxiUCjXA0KBB-h8w@mail.gmail.com>
	<87bltiv10t.fsf@oldenburg2.str.redhat.com>
	<CALmqtCWfnPZ=B2=_VM=uqAgMWqh3FbGjxXLcbg466Tgct+dUVw@mail.gmail.com>
	<CALmqtCVBCb2vJ+XNb6WZa1csNZaisLmqoG5nTn-QUU0MO=UbPw@mail.gmail.com>
	<877e42cqfo.fsf@oldenburg2.str.redhat.com>
	<CALmqtCVKqf53j7=SbUA-k8jHu4AydsoFfN6SZVX8Hv=iYVBLuQ@mail.gmail.com>
	<CALmqtCU6KB6qu1c7R4ngZh=0v+jvqOVjUT431zJoVsKhiNQdbw@mail.gmail.com>
	<875ziledsy.fsf@oldenburg2.str.redhat.com>
	<CALmqtCXvsdTWQindGNsgVVtMdsWW0dNW+FAttrogeH4uenk_iw@mail.gmail.com>
	<87mubngh8e.fsf@oldenburg2.str.redhat.com>
	<CALmqtCX5=NBAb_qabTmz-nGYJW8qb8iYG_Obbt9JvN8N6gdm5g@mail.gmail.com>
	<8736dfgfyo.fsf@oldenburg2.str.redhat.com>
	<CALmqtCXKHrTsAChozkHaDbLohswOpkU9qeTmy=v7nkzKXuR=Kg@mail.gmail.com>
Date: Fri, 20 Dec 2019 16:09:00 -0000
In-Reply-To: <CALmqtCXKHrTsAChozkHaDbLohswOpkU9qeTmy=v7nkzKXuR=Kg@mail.gmail.com>
	(Abhidnya Joshi's message of "Fri, 20 Dec 2019 21:23:23 +0530")
Message-ID: <87r20zf07d.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/msg00099.txt.bz2

* Abhidnya Joshi:

> The gconv_steps looked like below:
>
> (gdb) p *(&step[1])
> $4 =3D {__shlib_handle =3D 0x7f028853b240, __modname =3D 0x7f028853b270
> "/usr/lib64/gconv/UTF-16.so", __counter =3D 1, __from_name =3D
> 0x7f028abca431 "INTERNAL",
>   __to_name =3D 0x7f028853b220 "UTF-16LE//", __fct =3D 0x59e0be5c0391534f,
> __btowc_fct =3D 0xa7e5bbe252f1534f, __init_fct =3D 0x59e0be5c1c91534f,
> __end_fct =3D 0x59e0be5c03b1534f,
>   __min_needed_from =3D 4, __max_needed_from =3D 4, __min_needed_to =3D 2,
> __max_needed_to =3D 4, __stateful =3D 0, __data =3D 0x9bd320}
> (gdb) p *(&step[0])
> $5 =3D {__shlib_handle =3D 0x0, __modname =3D 0x0, __counter =3D 1,
> __from_name =3D 0x7f028853b890 "ISO-10646/UTF8/", __to_name =3D
> 0x7f028abca431 "INTERNAL",
>   __fct =3D 0x7f028aa73ce0 <__gconv_transform_utf8_internal>,
> __btowc_fct =3D 0x7f028aa714b0 <__gconv_btwoc_ascii>, __init_fct =3D 0x0,
> __end_fct =3D 0x0, __min_needed_from =3D 1,
>   __max_needed_from =3D 6, __min_needed_to =3D 4, __max_needed_to =3D 4,
> __stateful =3D 0, __data =3D 0x0}
> (gdb)

Since both __counter values are 1, I'm not sure there is a counter
overflow?

What I meant is that it would be nice to have a sequence of glibc API
calls which clearly demonstrate this behavior.  I can't reproduce this
with an obvious sequence of iconv calls in a loop.

Thanks,
Florian