libc6: application sometimes crashes, valgrind shows error in gconv_db.c

[Debian Bug Importer]

Automatically imported from Debian bug report #279722 http://bugs.debian.org/279722

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #279722 http://bugs.debian.org/279722

[Debian Bug Importer (debzilla)]

Message-Id: <20041104213732.POOD23965.amsfep17-int.chello.nl@[127.0.0.1]>
Date: Thu, 04 Nov 2004 22:37:34 +0100
From: wim delvaux <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: libc6: application sometimes crashes, valgrind shows error in gconv_db.c

Package: libc6
Version: 2.3.2.ds1-17
Severity: critical
Justification: breaks unrelated software

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)
==7105== by 0x1C2A1C76: _nl_cleanup_ctype (wcsmbsload.c:265)
==7105== by 0x1C31C9A2: _nl_archive_subfreeres (loadarchive.c:517)
==7105== by 0x1C31C89F: free_mem (setlocale.c:494)
==7105== by 0x1C31CC44: __GI___libc_freeres (set-freeres.c:49)
==7105== by 0x1B8FEC50: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117)
==7105== by 0x1C23CB17: exit (exit.c:82)
==7105== by 0x1C226DCD: __libc_start_main (libc-start.c:245)
==7105== by 0x804EF00: ??? (start.S:102)
==7105== Address 0x1CCE3138 is 8 bytes inside a block of size 60 free'd
==7105== at 0x1B907460: free (vg_replace_malloc.c:153)
==7105== by 0x1C228527: free_derivation (gconv_db.c:188)
==7105== by 0x1C2E6EE2: tdestroy_recurse (tsearch.c:642)
==7105== by 0x1C2E6F05: tdestroy_recurse (tsearch.c:639)
==7105== by 0x1C31C721: free_mem (gconv_db.c:796)
==7105== by 0x1C31CC44: __GI___libc_freeres (set-freeres.c:49)
==7105== by 0x1B8FEC50: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117)
==7105== by 0x1C23CB17: exit (exit.c:82)
==7105== by 0x1C226DCD: __libc_start_main (libc-start.c:245)
==7105== by 0x804EF00: ??? (start.S:102)

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-rc3
Locale: LANG=en_US, LC_CTYPE=en_US

Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7 The Berkeley database routines [gl

-- no debconf information

[GOTO Masanori (gotom-debian)]

severity 279722 normal
thanks

At Thu, 04 Nov 2004 22:37:34 +0100,
wim delvaux wrote:
> 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)
> ==7105== by 0x1C2A1C76: _nl_cleanup_ctype (wcsmbsload.c:265)
> ==7105== by 0x1C31C9A2: _nl_archive_subfreeres (loadarchive.c:517)
> ==7105== by 0x1C31C89F: free_mem (setlocale.c:494)
> ==7105== by 0x1C31CC44: __GI___libc_freeres (set-freeres.c:49)
> ==7105== by 0x1B8FEC50: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117)
> ==7105== by 0x1C23CB17: exit (exit.c:82)
> ==7105== by 0x1C226DCD: __libc_start_main (libc-start.c:245)
> ==7105== by 0x804EF00: ??? (start.S:102)
> ==7105== Address 0x1CCE3138 is 8 bytes inside a block of size 60 free'd
> ==7105== at 0x1B907460: free (vg_replace_malloc.c:153)
> ==7105== by 0x1C228527: free_derivation (gconv_db.c:188)
> ==7105== by 0x1C2E6EE2: tdestroy_recurse (tsearch.c:642)
> ==7105== by 0x1C2E6F05: tdestroy_recurse (tsearch.c:639)
> ==7105== by 0x1C31C721: free_mem (gconv_db.c:796)
> ==7105== by 0x1C31CC44: __GI___libc_freeres (set-freeres.c:49)
> ==7105== by 0x1B8FEC50: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117)
> ==7105== by 0x1C23CB17: exit (exit.c:82)
> ==7105== by 0x1C226DCD: __libc_start_main (libc-start.c:245)
> ==7105== by 0x804EF00: ??? (start.S:102)

Even if there's memory leak, this does not show "application sometimes
crashes". We need more explanation in detail.

Regards,
-- gotom

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 06 Nov 2004 08:18:11 +0900
From: GOTO Masanori <email address hidden>
To: wim delvaux <email address hidden>,
 <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#279722: libc6: application sometimes crashes, valgrind shows error in gconv_db.c

severity 279722 normal
thanks

At Thu, 04 Nov 2004 22:37:34 +0100,
wim delvaux wrote:
> 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)
> ==7105== by 0x1C2A1C76: _nl_cleanup_ctype (wcsmbsload.c:265)
> ==7105== by 0x1C31C9A2: _nl_archive_subfreeres (loadarchive.c:517)
> ==7105== by 0x1C31C89F: free_mem (setlocale.c:494)
> ==7105== by 0x1C31CC44: __GI___libc_freeres (set-freeres.c:49)
> ==7105== by 0x1B8FEC50: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117)
> ==7105== by 0x1C23CB17: exit (exit.c:82)
> ==7105== by 0x1C226DCD: __libc_start_main (libc-start.c:245)
> ==7105== by 0x804EF00: ??? (start.S:102)
> ==7105== Address 0x1CCE3138 is 8 bytes inside a block of size 60 free'd
> ==7105== at 0x1B907460: free (vg_replace_malloc.c:153)
> ==7105== by 0x1C228527: free_derivation (gconv_db.c:188)
> ==7105== by 0x1C2E6EE2: tdestroy_recurse (tsearch.c:642)
> ==7105== by 0x1C2E6F05: tdestroy_recurse (tsearch.c:639)
> ==7105== by 0x1C31C721: free_mem (gconv_db.c:796)
> ==7105== by 0x1C31CC44: __GI___libc_freeres (set-freeres.c:49)
> ==7105== by 0x1B8FEC50: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117)
> ==7105== by 0x1C23CB17: exit (exit.c:82)
> ==7105== by 0x1C226DCD: __libc_start_main (libc-start.c:245)
> ==7105== by 0x804EF00: ??? (start.S:102)

Even if there's memory leak, this does not show "application sometimes
crashes". We need more explanation in detail.

Regards,
-- gotom

[Daniel Jacobowitz (dan)]

On Sat, Nov 06, 2004 at 08:18:11AM +0900, GOTO Masanori wrote:
> severity 279722 normal
> thanks
>
> At Thu, 04 Nov 2004 22:37:34 +0100,
> wim delvaux wrote:
> > 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)
> > ==7105== by 0x1C2A1C76: _nl_cleanup_ctype (wcsmbsload.c:265)
> > ==7105== by 0x1C31C9A2: _nl_archive_subfreeres (loadarchive.c:517)
> > ==7105== by 0x1C31C89F: free_mem (setlocale.c:494)
> > ==7105== by 0x1C31CC44: __GI___libc_freeres (set-freeres.c:49)
> > ==7105== by 0x1B8FEC50: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117)
> > ==7105== by 0x1C23CB17: exit (exit.c:82)
> > ==7105== by 0x1C226DCD: __libc_start_main (libc-start.c:245)
> > ==7105== by 0x804EF00: ??? (start.S:102)
> > ==7105== Address 0x1CCE3138 is 8 bytes inside a block of size 60 free'd
> > ==7105== at 0x1B907460: free (vg_replace_malloc.c:153)
> > ==7105== by 0x1C228527: free_derivation (gconv_db.c:188)
> > ==7105== by 0x1C2E6EE2: tdestroy_recurse (tsearch.c:642)
> > ==7105== by 0x1C2E6F05: tdestroy_recurse (tsearch.c:639)
> > ==7105== by 0x1C31C721: free_mem (gconv_db.c:796)
> > ==7105== by 0x1C31CC44: __GI___libc_freeres (set-freeres.c:49)
> > ==7105== by 0x1B8FEC50: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117)
> > ==7105== by 0x1C23CB17: exit (exit.c:82)
> > ==7105== by 0x1C226DCD: __libc_start_main (libc-start.c:245)
> > ==7105== by 0x804EF00: ??? (start.S:102)
>
> Even if there's memory leak, this does not show "application sometimes
> crashes". We need more explanation in detail.

"Invalid read" is not a memory leak - this says something has been
freed and then used. It looks like the destructors are running in the
wrong order, maybe.

We'd still need a testcase.

--
Daniel Jacobowitz

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 6 Nov 2004 12:43:36 -0500
From: Daniel Jacobowitz <email address hidden>
To: GOTO Masanori <email address hidden>, <email address hidden>
Cc: wim delvaux <email address hidden>
Subject: Re: Bug#279722: libc6: application sometimes crashes, valgrind shows error in gconv_db.c

On Sat, Nov 06, 2004 at 08:18:11AM +0900, GOTO Masanori wrote:
> severity 279722 normal
> thanks
>
> At Thu, 04 Nov 2004 22:37:34 +0100,
> wim delvaux wrote:
> > 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)
> > ==7105== by 0x1C2A1C76: _nl_cleanup_ctype (wcsmbsload.c:265)
> > ==7105== by 0x1C31C9A2: _nl_archive_subfreeres (loadarchive.c:517)
> > ==7105== by 0x1C31C89F: free_mem (setlocale.c:494)
> > ==7105== by 0x1C31CC44: __GI___libc_freeres (set-freeres.c:49)
> > ==7105== by 0x1B8FEC50: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117)
> > ==7105== by 0x1C23CB17: exit (exit.c:82)
> > ==7105== by 0x1C226DCD: __libc_start_main (libc-start.c:245)
> > ==7105== by 0x804EF00: ??? (start.S:102)
> > ==7105== Address 0x1CCE3138 is 8 bytes inside a block of size 60 free'd
> > ==7105== at 0x1B907460: free (vg_replace_malloc.c:153)
> > ==7105== by 0x1C228527: free_derivation (gconv_db.c:188)
> > ==7105== by 0x1C2E6EE2: tdestroy_recurse (tsearch.c:642)
> > ==7105== by 0x1C2E6F05: tdestroy_recurse (tsearch.c:639)
> > ==7105== by 0x1C31C721: free_mem (gconv_db.c:796)
> > ==7105== by 0x1C31CC44: __GI___libc_freeres (set-freeres.c:49)
> > ==7105== by 0x1B8FEC50: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:117)
> > ==7105== by 0x1C23CB17: exit (exit.c:82)
> > ==7105== by 0x1C226DCD: __libc_start_main (libc-start.c:245)
> > ==7105== by 0x804EF00: ??? (start.S:102)
>
> Even if there's memory leak, this does not show "application sometimes
> crashes". We need more explanation in detail.

"Invalid read" is not a memory leak - this says something has been
freed and then used. It looks like the destructors are running in the
wrong order, maybe.

We'd still need a testcase.

--
Daniel Jacobowitz

[Bill Allombert (allomber)]

On Sat, Nov 06, 2004 at 12:43:36PM -0500, Daniel Jacobowitz wrote:
> "Invalid read" is not a memory leak - this says something has been
> freed and then used. It looks like the destructors are running in the
> wrong order, maybe.
>
> We'd still need a testcase.

A somewhat crappy testcase:
$ apt-get install pari-gp
$ valgrind gp
\q
==30297== ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 33 from 1)

If you run instead

$ valgrind --run-libc-freeres=no gp
\q
==30314== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 33 from
1)

If you enter ^D instead of \q you do not get errors, so it might be
linked to the libc I/O subsystem.
(GP is a CLI using GNU readline.)

Of course I did not rule out a bug in the gp binary itself, but I
suppose the submitter observed the problem in an unrelated program.

Cheers,
--
Bill. <email address hidden>

Imagine a large red swirl here.

[Debian Bug Importer (debzilla)]

Message-ID: <20041205185956.GA30258@seventeen>
Date: Sun, 5 Dec 2004 19:59:56 +0100
From: Bill Allombert <email address hidden>
To: <email address hidden>
Cc: wim delvaux <email address hidden>
Subject: Re: Bug#279722: libc6: application sometimes crashes, valgrind shows error in gconv_db.c

On Sat, Nov 06, 2004 at 12:43:36PM -0500, Daniel Jacobowitz wrote:
> "Invalid read" is not a memory leak - this says something has been
> freed and then used. It looks like the destructors are running in the
> wrong order, maybe.
>
> We'd still need a testcase.

A somewhat crappy testcase:
$ apt-get install pari-gp
$ valgrind gp
\q
==30297== ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 33 from 1)

If you run instead

$ valgrind --run-libc-freeres=no gp
\q
==30314== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 33 from
1)

If you enter ^D instead of \q you do not get errors, so it might be
linked to the libc I/O subsystem.
(GP is a CLI using GNU readline.)

Of course I did not rule out a bug in the gp binary itself, but I
suppose the submitter observed the problem in an unrelated program.

Cheers,
--
Bill. <email address hidden>

Imagine a large red swirl here.

[Loïc Minier (lool)]

        Hi,

 This is a followup for Debian bug <http://bugs.debian.org/279722>.

wim delvaux <email address hidden> - 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 <email address hidden>
"Neutral President: I have no strong feelings one way or the other."

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 3 Feb 2005 17:36:44 +0100
From: =?iso-8859-1?Q?Lo=EFc?= Minier <email address hidden>
To: wim delvaux <email address hidden>, GOTO Masanori <email address hidden>,
 Daniel Jacobowitz <email address hidden>,
 Bill Allombert <email address hidden>, <email address hidden>
Subject: Re: libc6: application sometimes crashes, valgrind shows error in gconv_db.c

        Hi,

 This is a followup for Debian bug <http://bugs.debian.org/279722>.

wim delvaux <email address hidden> - Thu, Nov 04, 2004:

> Valgrind shows the following backtrace ...
> =3D=3D7105=3D=3D Invalid read of size 4
> =3D=3D7105=3D=3D at 0x1C22857E: __gconv_release_step (gconv_db.c:198=
)
> =3D=3D7105=3D=3D by 0x1C22914C: __gconv_close_transform (gconv_db.c:=
751)

 I can get that one fairly easily with:
    % valgrind --db-attach=3Dyes ls -l

 (% locale LANG=3Dfr_FR@euro LC_CTYPE=3Dfr_FR@euro LC_NUMERIC=3Dfr_FR@eur=
o
 LC_TIME=3Dfr_FR@euro LC_COLLATE=3Dfr_FR@euro LC_MONETARY=3Dfr_FR@euro
 LC_MESSAGES=3Dfr_FR@euro LC_PAPER=3Dfr_FR@euro LC_NAME=3Dfr_FR@euro
 LC_ADDRESS=3Dfr_FR@euro LC_TELEPHONE=3Dfr_FR@euro LC_MEASUREMENT=3Dfr_FR=
@euro
 LC_IDENTIFICATION=3Dfr_FR@euro LC_ALL=3D)

 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=3D0x1bae2ccc) at gconv_db.c:=
198
#1 0x1b94f14d in __gconv_close_transform (steps=3D0x1bae2c90, nsteps=3D2=
)
    at gconv_db.c:751
#2 0x1b94e256 in __gconv_close (cd=3D0x1bae3868) at gconv_close.c:64
#3 0x1b95c54d in _nl_free_domain_conv (domain=3D0x1baba698) at loadmsgca=
t.c:873
#4 0x1b95d0b4 in _nl_unload_domain (domain=3D0x1baba698) 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=3D0) 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,

--=20
Lo=EFc Minier <email address hidden>
"Neutral President: I have no strong feelings one way or the other."

[Bill Allombert (allomber)]

On Thu, Feb 03, 2005 at 05:36:44PM +0100, Loïc Minier wrote:
> Hi,
>
> This is a followup for Debian bug <http://bugs.debian.org/279722>.
>
> 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?

Well I tried the following patch, but that did not fix the bug.
(Though I have to use ls --help for reproducing the bug).

Thanks for investigating this irritating issue!
--
Bill. <email address hidden>

Imagine a large red swirl here.

--- build-tree/glibc-2.3.2/iconv/gconv_close.c.old 2005-02-15 13:24:35.000000000 +0100
+++ build-tree/glibc-2.3.2/iconv/gconv_close.c 2005-02-15 14:33:08.000000000 +0100
@@ -30,6 +30,7 @@
   struct __gconv_step *srunp;
   struct __gconv_step_data *drunp;
   size_t nsteps;
+ int ret;

   /* Free all resources by calling destructor functions and release
      the implementations. */
@@ -57,9 +58,10 @@
     }
   while (!((drunp++)->__flags & __GCONV_IS_LAST));

+ /* Close the participating modules. */
+ ret = __gconv_close_transform (srunp, nsteps);
+
   /* Free the data allocated for the descriptor. */
   free (cd);
-
- /* Close the participating modules. */
- return __gconv_close_transform (srunp, nsteps);
+ return ret;
 }

[Debian Bug Importer (debzilla)]

Message-ID: <20050217102510.GF453@seventeen>
Date: Thu, 17 Feb 2005 11:25:10 +0100
From: Bill Allombert <email address hidden>
To: =?iso-8859-1?Q?Lo=EFc?= Minier <email address hidden>
Cc: wim delvaux <email address hidden>, GOTO Masanori <email address hidden>,
 Daniel Jacobowitz <email address hidden>, Bill Allombert <email address hidden>,
 <email address hidden>
Subject: Re: libc6: application sometimes crashes, valgrind shows error in gconv_db.c

On Thu, Feb 03, 2005 at 05:36:44PM +0100, Lo�Minier wrote:
> Hi,
>
> This is a followup for Debian bug <http://bugs.debian.org/279722>.
>
> 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?

Well I tried the following patch, but that did not fix the bug.
(Though I have to use ls --help for reproducing the bug).

Thanks for investigating this irritating issue!
--
Bill. <email address hidden>

Imagine a large red swirl here.

--- build-tree/glibc-2.3.2/iconv/gconv_close.c.old 2005-02-15 13:24:35.000000000 +0100
+++ build-tree/glibc-2.3.2/iconv/gconv_close.c 2005-02-15 14:33:08.000000000 +0100
@@ -30,6 +30,7 @@
   struct __gconv_step *srunp;
   struct __gconv_step_data *drunp;
   size_t nsteps;
+ int ret;

   /* Free all resources by calling destructor functions and release
      the implementations. */
@@ -57,9 +58,10 @@
     }
   while (!((drunp++)->__flags & __GCONV_IS_LAST));

+ /* Close the participating modules. */
+ ret = __gconv_close_transform (srunp, nsteps);
+
   /* Free the data allocated for the descriptor. */
   free (cd);
-
- /* Close the participating modules. */
- return __gconv_close_transform (srunp, nsteps);
+ return ret;
 }

[Loïc Minier (lool)]

        Hi,

On Thu, Feb 17, 2005, Bill Allombert wrote:
> Well I tried the following patch, but that did not fix the bug.
> (Though I have to use ls --help for reproducing the bug).

 Sadly, I'm out of ideas here, clearly some data is freed and used again
 afterwards (to clean allocated data in a substructure mostly), but that
 probably happens at a higher level, and I'm kind of lost in higher
 level functions. :-/

   Thanks for trying swapping the free (I really can't build glibc on my
 laptop)!

--
Loïc Minier <email address hidden>
"Neutral President: I have no strong feelings one way or the other."

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 17 Feb 2005 12:01:13 +0100
From: =?iso-8859-1?Q?Lo=EFc?= Minier <email address hidden>
To: Bill Allombert <email address hidden>
Cc: wim delvaux <email address hidden>, GOTO Masanori <email address hidden>,
 Daniel Jacobowitz <email address hidden>, Bill Allombert <email address hidden>,
 <email address hidden>
Subject: Re: libc6: application sometimes crashes, valgrind shows error in gconv_db.c

        Hi,

On Thu, Feb 17, 2005, Bill Allombert wrote:
> Well I tried the following patch, but that did not fix the bug.
> (Though I have to use ls --help for reproducing the bug).

 Sadly, I'm out of ideas here, clearly some data is freed and used again
 afterwards (to clean allocated data in a substructure mostly), but that
 probably happens at a higher level, and I'm kind of lost in higher
 level functions. :-/

   Thanks for trying swapping the free (I really can't build glibc on my
 laptop)!

--=20
Lo=EFc Minier <email address hidden>
"Neutral President: I have no strong feelings one way or the other."

[Jeff Bailey (jbailey)]

Reducing severity - this bug is several months old, has no testcase, and debian
has reduced severity. Likely to silently go away with the 2.3.4 update if it is
a bug. There's been a fair amount of valgrinding of the stable glibc.

[Jeff Bailey (jbailey)]

No followup in the upstream bug since February, no reports against 2.3.5 at all,
no reports in Ubuntu at all. Closing this bug.