Bug#279722: libc6: application sometimes crashes, valgrind shows error in gconv_db.c
- To: wim delvaux <wim.delvaux@adaptiveplanet.com>, GOTO Masanori <gotom@debian.or.jp>, Daniel Jacobowitz <dan@debian.org>, Bill Allombert <allomber@math.u-bordeaux.fr>, 279722@bugs.debian.org
- Subject: Bug#279722: libc6: application sometimes crashes, valgrind shows error in gconv_db.c
- From: Loïc Minier <lool@dooz.org>
- Date: Thu, 3 Feb 2005 17:36:44 +0100
- Message-id: <[🔎] 20050203163644.GA21245@bugs.debian.org>
- Reply-to: Loïc Minier <lool@dooz.org>, 279722@bugs.debian.org
- In-reply-to: <20041205185956.GA30258@seventeen> <20041106174336.GA17514@nevyn.them.org> <81fz3nx4uk.wl@omega.webmasters.gr.jp> <20041104213732.POOD23965.amsfep17-int.chello.nl@[127.0.0.1]>
- References: <20041104213732.POOD23965.amsfep17-int.chello.nl@127.0.0.1> <81fz3nx4uk.wl@omega.webmasters.gr.jp> <20041106174336.GA17514@nevyn.them.org> <20041205185956.GA30258@seventeen> <20041104213732.POOD23965.amsfep17-int.chello.nl@127.0.0.1> <81fz3nx4uk.wl@omega.webmasters.gr.jp> <20041106174336.GA17514@nevyn.them.org> <20041104213732.POOD23965.amsfep17-int.chello.nl@127.0.0.1> <81fz3nx4uk.wl@omega.webmasters.gr.jp> <20041104213732.POOD23965.amsfep17-int.chello.nl@[127.0.0.1]>
Hi,
This is a followup for Debian bug <http://bugs.debian.org/279722>.
wim delvaux <wim.delvaux@adaptiveplanet.com> - Thu, Nov 04, 2004:
> Valgrind shows the following backtrace ...
> ==7105== Invalid read of size 4
> ==7105== at 0x1C22857E: __gconv_release_step (gconv_db.c:198)
> ==7105== by 0x1C22914C: __gconv_close_transform (gconv_db.c:751)
I can get that one fairly easily with:
% valgrind --db-attach=yes ls -l
(% locale LANG=fr_FR@euro LC_CTYPE=fr_FR@euro LC_NUMERIC=fr_FR@euro
LC_TIME=fr_FR@euro LC_COLLATE=fr_FR@euro LC_MONETARY=fr_FR@euro
LC_MESSAGES=fr_FR@euro LC_PAPER=fr_FR@euro LC_NAME=fr_FR@euro
LC_ADDRESS=fr_FR@euro LC_TELEPHONE=fr_FR@euro LC_MEASUREMENT=fr_FR@euro
LC_IDENTIFICATION=fr_FR@euro LC_ALL=)
I get the same bt, I installed the -dbg version of glibc and debuilded
a part of the source (to get the patches applied):
(gdb) bt
#0 0x1b94e58f in __gconv_release_step (step=0x1bae2ccc) at gconv_db.c:198
#1 0x1b94f14d in __gconv_close_transform (steps=0x1bae2c90, nsteps=2)
at gconv_db.c:751
#2 0x1b94e256 in __gconv_close (cd=0x1bae3868) at gconv_close.c:64
#3 0x1b95c54d in _nl_free_domain_conv (domain=0x1baba698) at loadmsgcat.c:873
#4 0x1b95d0b4 in _nl_unload_domain (domain=0x1baba698) at loadmsgcat.c:1289
#5 0x1ba42afd in free_mem () at finddomain.c:179
#6 0x1ba42c45 in *__GI___libc_freeres () at set-freeres.c:49
#7 0x1b8fec51 in _vgw__freeres () at vg_intercept.c:117
#8 0x1b962b18 in *__GI_exit (status=0) at exit.c:82
I think the problem is in iconv/gconv_close.c, in __gconv_close() at
the very end of the file:
while (!((drunp++)->__flags & __GCONV_IS_LAST));
/* Free the data allocated for the descriptor. */
free (cd);
/* Close the participating modules. */
return __gconv_close_transform (srunp, nsteps);
I think "srunp" uses a reference in "cd".
I already tried in the past to build glibc on my system, and this was
too long a task for my laptop, could someone try swapping the free
after the __gconv_close_transform() or hand me a build if he can't
reproduce the bug?
Thanks,
--
Loïc Minier <lool@dooz.org>
"Neutral President: I have no strong feelings one way or the other."
Reply to: