Ubuntu
valgrind package

libc6: dlerror valgrind error

Bug #13460 reported by Debian Bug Importer
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
valgrind (Debian)
Fix Released
Unknown
valgrind (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

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

See original description
Revision history for this message
Debian Bug Importer (debzilla) wrote :

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

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (3.5 KiB)

Message-Id: <email address hidden>
Date: Thu, 03 Mar 2005 00:31:39 +0100
From: wim delvaux <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: libc6: dlerror valgrind error

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

the following statement

     AC_RaiseExc( AC_Critical, AC_For(Myself),
          AC_Private( AC_9999 ),
          "Cannot load PEX %s of %s : %s",
              Fn, Name, dlerror() );

which basically serves as a printf

gives following valgrind error

==8220== Invalid read of size 1
==8220== at 0x1B906788: strlen (mac_replace_strmem.c:189)
==8220== by 0x1C0EB249: AC_vfnprintf (fnprintf_A.c:299)
==8220== by 0x1C0EAB39: AC_vfdprintf (fdprintf_A.c:9)
==8220== by 0x1C0EA02D: AC_VLog (ActivatorErrorHandling_A.c:136)
==8220== by 0x1C0EA3EC: AC_VRaiseExc (ActivatorErrorHandling_A.c:202)
==8220== by 0x1C0EA559: AC_RaiseExc (ActivatorErrorHandling_A.c:268)
==8220== by 0x1C5FDA8D: Repo2Pex_Load (PEX_A.c:35)
==8220== by 0x1B9192DA: Repo2Mgr_FindAndLoadParcelOfComponent (P_Repo2Manager_A.c:759)
==8220== by 0x1B90CADE: TOREPO_FindAndLoadParcel (REPO.c:196)
==8220== by 0x1B90E8A9: ILoadComponent (StdRootManager.c:776)
==8220== by 0x1B90F763: CheckCompRefQuality (StdRootManager.c:995)
==8220== by 0x1B910DC8: FindBehavior (StdRootManager.c:1457)
==8220== by 0x1B9128BD: Wrap_FindBehavior (StdRootManager.c:2023)
==8220== by 0x1C0EBF42: AC_FindBehaviorByCID (ActivatorLoader_A.c:98)
==8220== by 0x804866D: main (main.c:8)
==8220== Address 0x1C4F5E58 is 0 bytes inside a block of size 74 free'd
==8220== at 0x1B907460: free (vg_replace_malloc.c:153)
==8220== by 0x1C1284FA: _dlerror_run (dlerror.c:140)
==8220== by 0x1C128153: dlsym (dlsym.c:51)
==8220== by 0x1C0FE263: write (vg_libpthread.c:2369)
==8220== by 0x1C0EFF1D: AC_WriteExt (ActivatorIo_A.c:112)
==8220== by 0x1C0EAAF8: AC_WriteToFd (fdprintf_A.c:4)
==8220== by 0x1C0EACAC: fmtout (fnprintf_A.c:63)
==8220== by 0x1C0EB8A9: AC_vfnprintf (fnprintf_A.c:506)
==8220== by 0x1C0EAB39: AC_vfdprintf (fdprintf_A.c:9)
==8220== by 0x1C0EAB70: AC_fdprintf (fdprintf_A.c:17)
==8220== by 0x1C0E9FB0: AC_VLog (ActivatorErrorHandling_A.c:118)
==8220== by 0x1C0EA3EC: AC_VRaiseExc (ActivatorErrorHandling_A.c:202)
==8220== by 0x1C0EA559: AC_RaiseExc (ActivatorErrorHandling_A.c:268)
==8220== by 0x1C5FDA8D: Repo2Pex_Load (PEX_A.c:35)
==8220== by 0x1B9192DA: Repo2Mgr_FindAndLoadParcelOfComponent (P_Repo2Manager_A.c:759)
==8220== by 0x1B90CADE: TOREPO_FindAndLoadParcel (REPO.c:196)
==8220== by 0x1B90E8A9: ILoadComponent (StdRootManager.c:776)
==8220== by 0x1B90F763: CheckCompRefQuality (StdRootManager.c:995)
==8220== by 0x1B910DC8: FindBehavior (StdRootManager.c:1457)
==8220== by 0x1B9128BD: Wrap_FindBehavior (StdRootManager.c:2023)
==8220==

if i interpret this correctly then dlsym (used somewhere in the write
function of valgrind), causes a free of the return string of a
dlerror() which is still needed by my application because it wants
to printf it.

if that free occ...

Read more...

Revision history for this message
In , Daniel Jacobowitz (drow) wrote : Re: Bug#297798: libc6: dlerror valgrind error

On Thu, Mar 03, 2005 at 12:31:39AM +0100, wim delvaux wrote:
> Package: libc6
> Version: 2.3.2.ds1-20
> Severity: critical
> Justification: breaks unrelated software

That's not "unrelated" software, you're using libc6. By that
justification every bug in a library is critical.

> if i interpret this correctly then dlsym (used somewhere in the write
> function of valgrind), causes a free of the return string of a
> dlerror() which is still needed by my application because it wants
> to printf it.
>
> if that free occurs all the time it might break other applications too.

Sounds like a bug in valgrind. dlerror's result is only guaranteed
until the next call to a dl* function.

--
Daniel Jacobowitz
CodeSourcery, LLC

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Thu, 3 Mar 2005 09:34:16 -0500
From: Daniel Jacobowitz <email address hidden>
To: wim delvaux <email address hidden>, <email address hidden>
Subject: Re: Bug#297798: libc6: dlerror valgrind error

On Thu, Mar 03, 2005 at 12:31:39AM +0100, wim delvaux wrote:
> Package: libc6
> Version: 2.3.2.ds1-20
> Severity: critical
> Justification: breaks unrelated software

That's not "unrelated" software, you're using libc6. By that
justification every bug in a library is critical.

> if i interpret this correctly then dlsym (used somewhere in the write
> function of valgrind), causes a free of the return string of a
> dlerror() which is still needed by my application because it wants
> to printf it.
>
> if that free occurs all the time it might break other applications too.

Sounds like a bug in valgrind. dlerror's result is only guaranteed
until the next call to a dl* function.

--
Daniel Jacobowitz
CodeSourcery, LLC

Revision history for this message
In , Justin Pryzby (justinpryzby-users) wrote : valgrind error

Hi,

Could you expand on the Debian bug #297798 which you reported against
libc6? It seems like you mean that applications using dlerror() break
when invoked by valgrind, because valgrind dlsym() frees its return
pointer. Is that a correct interpretation?

Thanks,
Justin

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <20050305172303.GB26754@andromeda>
Date: Sat, 5 Mar 2005 12:23:03 -0500
From: Justin Pryzby <email address hidden>
To: <email address hidden>
Subject: valgrind error

Hi,

Could you expand on the Debian bug #297798 which you reported against
libc6? It seems like you mean that applications using dlerror() break
when invoked by valgrind, because valgrind dlsym() frees its return
pointer. Is that a correct interpretation?

Thanks,
Justin

Revision history for this message
In , Pierre van den Oord (pierre-pckennis) wrote : Re: Bug#297798: valgrind error

Dear Justin,

Maybe you can help me out, I'm trying to get rid of this
bugmailing-list, it seems i'm receiving all kind of bugs. I can't find
the command to send to the list to stop my subscription. Can you help me
out?

Groet,
  Pierre

  Mail: <email address hidden>
  MSN : <email address hidden>
  ICQ : 68821143

Justin Pryzby wrote:
> Hi,
>
> Could you expand on the Debian bug #297798 which you reported against
> libc6? It seems like you mean that applications using dlerror() break
> when invoked by valgrind, because valgrind dlsym() frees its return
> pointer. Is that a correct interpretation?
>
> Thanks,
> Justin
>
>

Revision history for this message
In , u19809 (wim-delvaux) wrote :
Download full text (3.3 KiB)

On Saturday 05 March 2005 18:23, Justin Pryzby wrote:
> Hi,
>
> Could you expand on the Debian bug #297798 which you reported against
> libc6? It seems like you mean that applications using dlerror() break
> when invoked by valgrind, because valgrind dlsym() frees its return
> pointer. Is that a correct interpretation?

yes, that is correct ... (anyway that is what the guys from libc6 support tell
me that happens).

the following statement

     AC_RaiseExc( AC_Critical, AC_For(Myself),
          AC_Private( AC_9999 ),
          "Cannot load PEX %s of %s : %s",
              Fn, Name, dlerror() );

which basically serves as a printf

gives following valgrind error

==8220== Invalid read of size 1
==8220== at 0x1B906788: strlen (mac_replace_strmem.c:189)
==8220== by 0x1C0EB249: AC_vfnprintf (fnprintf_A.c:299)
==8220== by 0x1C0EAB39: AC_vfdprintf (fdprintf_A.c:9)
==8220== by 0x1C0EA02D: AC_VLog (ActivatorErrorHandling_A.c:136)
==8220== by 0x1C0EA3EC: AC_VRaiseExc (ActivatorErrorHandling_A.c:202)
==8220== by 0x1C0EA559: AC_RaiseExc (ActivatorErrorHandling_A.c:268)
==8220== by 0x1C5FDA8D: Repo2Pex_Load (PEX_A.c:35)
==8220== by 0x1B9192DA: Repo2Mgr_FindAndLoadParcelOfComponent
(P_Repo2Manager_A.c:759)
==8220== by 0x1B90CADE: TOREPO_FindAndLoadParcel (REPO.c:196)
==8220== by 0x1B90E8A9: ILoadComponent (StdRootManager.c:776)
==8220== by 0x1B90F763: CheckCompRefQuality (StdRootManager.c:995)
==8220== by 0x1B910DC8: FindBehavior (StdRootManager.c:1457)
==8220== by 0x1B9128BD: Wrap_FindBehavior (StdRootManager.c:2023)
==8220== by 0x1C0EBF42: AC_FindBehaviorByCID (ActivatorLoader_A.c:98)
==8220== by 0x804866D: main (main.c:8)
==8220== Address 0x1C4F5E58 is 0 bytes inside a block of size 74 free'd
==8220== at 0x1B907460: free (vg_replace_malloc.c:153)
==8220== by 0x1C1284FA: _dlerror_run (dlerror.c:140)
==8220== by 0x1C128153: dlsym (dlsym.c:51)
==8220== by 0x1C0FE263: write (vg_libpthread.c:2369)
==8220== by 0x1C0EFF1D: AC_WriteExt (ActivatorIo_A.c:112)
==8220== by 0x1C0EAAF8: AC_WriteToFd (fdprintf_A.c:4)
==8220== by 0x1C0EACAC: fmtout (fnprintf_A.c:63)
==8220== by 0x1C0EB8A9: AC_vfnprintf (fnprintf_A.c:506)
==8220== by 0x1C0EAB39: AC_vfdprintf (fdprintf_A.c:9)
==8220== by 0x1C0EAB70: AC_fdprintf (fdprintf_A.c:17)
==8220== by 0x1C0E9FB0: AC_VLog (ActivatorErrorHandling_A.c:118)
==8220== by 0x1C0EA3EC: AC_VRaiseExc (ActivatorErrorHandling_A.c:202)
==8220== by 0x1C0EA559: AC_RaiseExc (ActivatorErrorHandling_A.c:268)
==8220== by 0x1C5FDA8D: Repo2Pex_Load (PEX_A.c:35)
==8220== by 0x1B9192DA: Repo2Mgr_FindAndLoadParcelOfComponent
(P_Repo2Manager_A.c:759)
==8220== by 0x1B90CADE: TOREPO_FindAndLoadParcel (REPO.c:196)
==8220== by 0x1B90E8A9: ILoadComponent (StdRootManager.c:776)
==8220== by 0x1B90F763: CheckCompRefQuality (StdRootManager.c:995)
==8220== by 0x1B910DC8: FindBehavior (StdRootManager.c:1457)
==8220== by 0x1B9128BD: Wrap_FindBehavior (StdRootManager.c:2023)
==8220==

if i interpret this correctly then dlsym (used somewhere in the write
function of valgrind), causes a free of the return string of a
dlerror() which is still needed by my app...

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 05 Mar 2005 19:01:48 +0100
From: Pierre van den Oord <email address hidden>
To: Justin Pryzby <email address hidden>,
 <email address hidden>
Subject: Re: Bug#297798: valgrind error

Dear Justin,

Maybe you can help me out, I'm trying to get rid of this
bugmailing-list, it seems i'm receiving all kind of bugs. I can't find
the command to send to the list to stop my subscription. Can you help me
out?

Groet,
  Pierre

  Mail: <email address hidden>
  MSN : <email address hidden>
  ICQ : 68821143

Justin Pryzby wrote:
> Hi,
>
> Could you expand on the Debian bug #297798 which you reported against
> libc6? It seems like you mean that applications using dlerror() break
> when invoked by valgrind, because valgrind dlsym() frees its return
> pointer. Is that a correct interpretation?
>
> Thanks,
> Justin
>
>

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (3.5 KiB)

Message-Id: <email address hidden>
Date: Sat, 5 Mar 2005 19:24:19 +0100
From: wim delvaux <email address hidden>
To: Justin Pryzby <email address hidden>,
 <email address hidden>
Subject: Re: Bug#297798: valgrind error

On Saturday 05 March 2005 18:23, Justin Pryzby wrote:
> Hi,
>
> Could you expand on the Debian bug #297798 which you reported against
> libc6? It seems like you mean that applications using dlerror() break
> when invoked by valgrind, because valgrind dlsym() frees its return
> pointer. Is that a correct interpretation?

yes, that is correct ... (anyway that is what the guys from libc6 support tell
me that happens).

the following statement

     AC_RaiseExc( AC_Critical, AC_For(Myself),
          AC_Private( AC_9999 ),
          "Cannot load PEX %s of %s : %s",
              Fn, Name, dlerror() );

which basically serves as a printf

gives following valgrind error

==8220== Invalid read of size 1
==8220== at 0x1B906788: strlen (mac_replace_strmem.c:189)
==8220== by 0x1C0EB249: AC_vfnprintf (fnprintf_A.c:299)
==8220== by 0x1C0EAB39: AC_vfdprintf (fdprintf_A.c:9)
==8220== by 0x1C0EA02D: AC_VLog (ActivatorErrorHandling_A.c:136)
==8220== by 0x1C0EA3EC: AC_VRaiseExc (ActivatorErrorHandling_A.c:202)
==8220== by 0x1C0EA559: AC_RaiseExc (ActivatorErrorHandling_A.c:268)
==8220== by 0x1C5FDA8D: Repo2Pex_Load (PEX_A.c:35)
==8220== by 0x1B9192DA: Repo2Mgr_FindAndLoadParcelOfComponent
(P_Repo2Manager_A.c:759)
==8220== by 0x1B90CADE: TOREPO_FindAndLoadParcel (REPO.c:196)
==8220== by 0x1B90E8A9: ILoadComponent (StdRootManager.c:776)
==8220== by 0x1B90F763: CheckCompRefQuality (StdRootManager.c:995)
==8220== by 0x1B910DC8: FindBehavior (StdRootManager.c:1457)
==8220== by 0x1B9128BD: Wrap_FindBehavior (StdRootManager.c:2023)
==8220== by 0x1C0EBF42: AC_FindBehaviorByCID (ActivatorLoader_A.c:98)
==8220== by 0x804866D: main (main.c:8)
==8220== Address 0x1C4F5E58 is 0 bytes inside a block of size 74 free'd
==8220== at 0x1B907460: free (vg_replace_malloc.c:153)
==8220== by 0x1C1284FA: _dlerror_run (dlerror.c:140)
==8220== by 0x1C128153: dlsym (dlsym.c:51)
==8220== by 0x1C0FE263: write (vg_libpthread.c:2369)
==8220== by 0x1C0EFF1D: AC_WriteExt (ActivatorIo_A.c:112)
==8220== by 0x1C0EAAF8: AC_WriteToFd (fdprintf_A.c:4)
==8220== by 0x1C0EACAC: fmtout (fnprintf_A.c:63)
==8220== by 0x1C0EB8A9: AC_vfnprintf (fnprintf_A.c:506)
==8220== by 0x1C0EAB39: AC_vfdprintf (fdprintf_A.c:9)
==8220== by 0x1C0EAB70: AC_fdprintf (fdprintf_A.c:17)
==8220== by 0x1C0E9FB0: AC_VLog (ActivatorErrorHandling_A.c:118)
==8220== by 0x1C0EA3EC: AC_VRaiseExc (ActivatorErrorHandling_A.c:202)
==8220== by 0x1C0EA559: AC_RaiseExc (ActivatorErrorHandling_A.c:268)
==8220== by 0x1C5FDA8D: Repo2Pex_Load (PEX_A.c:35)
==8220== by 0x1B9192DA: Repo2Mgr_FindAndLoadParcelOfComponent
(P_Repo2Manager_A.c:759)
==8220== by 0x1B90CADE: TOREPO_FindAndLoadParcel (REPO.c:196)
==8220== by 0x1B90E8A9: ILoadComponent (StdRootManager.c:776)
==8220== by 0x1B90F763: CheckCompRefQuality (StdRootManager.c:995)
==8220== by 0x1B910DC8: FindBehavio...

Read more...

Revision history for this message
Matt Zimmerman (mdz) wrote :

Jeff, is this something we should be concerned about for Hoary?

Revision history for this message
In , Justin Pryzby (justinpryzby-users) wrote : valgrind test case

Have you tried to construct a minimal test case?

I tried to reproduce the problem with a trivial program, included.
Let me know if I'm missing something already known.

Thanks,
Justin

References

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297798

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <20050307171518.GA5688@andromeda>
Date: Mon, 7 Mar 2005 12:15:18 -0500
From: Justin Pryzby <email address hidden>
To: <email address hidden>
Subject: valgrind test case

--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Have you tried to construct a minimal test case?

I tried to reproduce the problem with a trivial program, included.
Let me know if I'm missing something already known.

Thanks,
Justin

References

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297798

--9jxsPFA5p3P2qPhR
Content-Type: text/x-csrc; charset=us-ascii
Content-Disposition: attachment; filename="vg.c"

#include <dlfcn.h>
#include <stdio.h>

print(char *s)
{
 fprintf(stderr, "%s\n", s);
}

int main()
{
 void *v=dlopen("/", RTLD_LAZY);
 print(dlerror());

 //void *dlsym(void *handle, const char *symbol);
 //int dlclose(void *handle);

 return 0;
}

--9jxsPFA5p3P2qPhR--

Revision history for this message
In , u19809 (wim-delvaux) wrote : Re: Bug#297798: valgrind test case

On Monday 07 March 2005 18:15, Justin Pryzby wrote:
> Have you tried to construct a minimal test case?
>
> I tried to reproduce the problem with a trivial program, included.
> Let me know if I'm missing something already known.
>
> Thanks,
> Justin
>
> References
>
> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297798

It seems the problem only occurs when the library has a missing symbol and not
when it is not found.

I have changed the vg.c as such ...

#include <dlfcn.h>
#include <stdio.h>

print(char *s)
{
 fprintf(stderr, "%s\n", s);
}

int main()
{
 void*v=dlopen("xyz.so", RTLD_NOW);
 printf("%s\n", dlerror());

 //void *dlsym(void *handle, const char *symbol);
 //int dlclose(void *handle);

 return 0;
}

where xyz.so is an existing library with a missing symbol

I tried with one of my own libs (which I molested a bit) and got the following
valgrind error

u19809@buro:.../tmp$ val ./vg
==19655== Memcheck, a memory error detector for x86-linux.
==19655== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==19655== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==19655== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==19655== For more details, rerun with: -v
==19655==
==19655== Invalid read of size 1
==19655== at 0x1B90C2E7: dlerror (dlerror.c:78)
==19655== by 0x80484E3: main (in /tmp/vg)
==19655== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==19655==
==19655== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- qc
==19655==
==19655== Process terminating with default action of signal 11 (SIGSEGV)
==19655== Access not within mapped region at address 0x0
==19655== at 0x1B90C2E7: dlerror (dlerror.c:78)
==19655== by 0x80484E3: main (in /tmp/vg)
==19655==
==19655== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 23 from 1)
==19655== malloc/free: in use at exit: 964 bytes in 5 blocks.
==19655== malloc/free: 17 allocs, 12 frees, 3374 bytes allocated.
==19655== For a detailed leak analysis, rerun with: --leak-check=yes
==19655== For counts of detected errors, rerun with: -v

running without val yields ... (long path is what I used for xxx.so ... don't
let the pex extension fool you)

u19809@buro:.../tmp$ ./vg
/mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcels/MSPApplication.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_TS.pex:
undefined symbol: AC_d_sprintf

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Tue, 8 Mar 2005 00:26:43 +0100
From: wim delvaux <email address hidden>
To: Justin Pryzby <email address hidden>,
 <email address hidden>
Subject: Re: Bug#297798: valgrind test case

On Monday 07 March 2005 18:15, Justin Pryzby wrote:
> Have you tried to construct a minimal test case?
>
> I tried to reproduce the problem with a trivial program, included.
> Let me know if I'm missing something already known.
>
> Thanks,
> Justin
>
> References
>
> [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297798

It seems the problem only occurs when the library has a missing symbol and not
when it is not found.

I have changed the vg.c as such ...

#include <dlfcn.h>
#include <stdio.h>

print(char *s)
{
 fprintf(stderr, "%s\n", s);
}

int main()
{
 void*v=dlopen("xyz.so", RTLD_NOW);
 printf("%s\n", dlerror());

 //void *dlsym(void *handle, const char *symbol);
 //int dlclose(void *handle);

 return 0;
}

where xyz.so is an existing library with a missing symbol

I tried with one of my own libs (which I molested a bit) and got the following
valgrind error

u19809@buro:.../tmp$ val ./vg
==19655== Memcheck, a memory error detector for x86-linux.
==19655== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==19655== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==19655== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==19655== For more details, rerun with: -v
==19655==
==19655== Invalid read of size 1
==19655== at 0x1B90C2E7: dlerror (dlerror.c:78)
==19655== by 0x80484E3: main (in /tmp/vg)
==19655== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==19655==
==19655== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- qc
==19655==
==19655== Process terminating with default action of signal 11 (SIGSEGV)
==19655== Access not within mapped region at address 0x0
==19655== at 0x1B90C2E7: dlerror (dlerror.c:78)
==19655== by 0x80484E3: main (in /tmp/vg)
==19655==
==19655== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 23 from 1)
==19655== malloc/free: in use at exit: 964 bytes in 5 blocks.
==19655== malloc/free: 17 allocs, 12 frees, 3374 bytes allocated.
==19655== For a detailed leak analysis, rerun with: --leak-check=yes
==19655== For counts of detected errors, rerun with: -v

running without val yields ... (long path is what I used for xxx.so ... don't
let the pex extension fool you)

u19809@buro:.../tmp$ ./vg
/mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcels/MSPApplication.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_TS.pex:
undefined symbol: AC_d_sprintf

Revision history for this message
In , Steve Langasek (vorlon) wrote : reassign 297798 to valgrind, severity of 297798 is important

# Automatically generated email from bts, devscripts version 2.8.10
reassign 297798 valgrind
severity 297798 important

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Tue, 8 Mar 2005 03:02:19 -0800
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: reassign 297798 to valgrind, severity of 297798 is important

# Automatically generated email from bts, devscripts version 2.8.10
reassign 297798 valgrind
severity 297798 important

Revision history for this message
In , GOTO Masanori (gotom-debian) wrote : Re: Bug#297798: libc6: dlerror valgrind error

reassign 297798 valgrind
severity 297798 normal
thanks

At Thu, 3 Mar 2005 09:34:16 -0500,
Daniel Jacobowitz wrote:
> On Thu, Mar 03, 2005 at 12:31:39AM +0100, wim delvaux wrote:
> > Package: libc6
> > Version: 2.3.2.ds1-20
> > Severity: critical
> > Justification: breaks unrelated software
>
> That's not "unrelated" software, you're using libc6. By that
> justification every bug in a library is critical.

I agreed. I downgrade it to normal.

> > if i interpret this correctly then dlsym (used somewhere in the write
> > function of valgrind), causes a free of the return string of a
> > dlerror() which is still needed by my application because it wants
> > to printf it.
> >
> > if that free occurs all the time it might break other applications too.
>
> Sounds like a bug in valgrind. dlerror's result is only guaranteed
> until the next call to a dl* function.

Maybe so.

I reassigned it to valgrind package. Valgrind maintainer, please look
at it. If you find it's glibc related problem, please reassign it
back to us.

Regards,
-- gotom

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 09 Mar 2005 16:56:03 +0900
From: GOTO Masanori <email address hidden>
To: Daniel Jacobowitz <email address hidden>, <email address hidden>
Cc: wim delvaux <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: Bug#297798: libc6: dlerror valgrind error

reassign 297798 valgrind
severity 297798 normal
thanks

At Thu, 3 Mar 2005 09:34:16 -0500,
Daniel Jacobowitz wrote:
> On Thu, Mar 03, 2005 at 12:31:39AM +0100, wim delvaux wrote:
> > Package: libc6
> > Version: 2.3.2.ds1-20
> > Severity: critical
> > Justification: breaks unrelated software
>
> That's not "unrelated" software, you're using libc6. By that
> justification every bug in a library is critical.

I agreed. I downgrade it to normal.

> > if i interpret this correctly then dlsym (used somewhere in the write
> > function of valgrind), causes a free of the return string of a
> > dlerror() which is still needed by my application because it wants
> > to printf it.
> >
> > if that free occurs all the time it might break other applications too.
>
> Sounds like a bug in valgrind. dlerror's result is only guaranteed
> until the next call to a dl* function.

Maybe so.

I reassigned it to valgrind package. Valgrind maintainer, please look
at it. If you find it's glibc related problem, please reassign it
back to us.

Regards,
-- gotom

Revision history for this message
In , Justin Pryzby (justinpryzby-users) wrote : valgrind error

Okay,

Still trying to make sure I understand precisely what you're doing.

It seems like you have a shared object called

  /mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcels/MSPApplication.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_TS.pex

which contains an undefined symbol.

  file /mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcels/MSPApplication.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_TS.pex

should say

  ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped

or something very similar. Right?

And you are using

        void *v=dlopen("/mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcels/MSPApplication.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_TS.pex", RTLD_NOW);

Thanks,
Justin

References

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297798

Revision history for this message
Jeff Bailey (jbailey) wrote :

Downgrading severity to match lowered severity in Debian. Will watch to see if
valgrind problems solves it.

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <20050309171435.GA30475@andromeda>
Date: Wed, 9 Mar 2005 12:14:35 -0500
From: Justin Pryzby <email address hidden>
To: <email address hidden>
Subject: valgrind error

Okay,

Still trying to make sure I understand precisely what you're doing.

It seems like you have a shared object called

  /mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcels/MSPApplication.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_TS.pex

which contains an undefined symbol.

  file /mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcels/MSPApplication.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_TS.pex

should say

  ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped

or something very similar. Right?

And you are using

        void *v=dlopen("/mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcels/MSPApplication.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_TS.pex", RTLD_NOW);

Thanks,
Justin

References

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297798

Revision history for this message
In , Andrés Roldán (aroldan) wrote : Unreproducible

Hi, I still can't reproduce this bug using the latest versions
of libc6 and valgrind available on Debian. This is what I did:

aroldan@volatile:~% cat xyz.c
#include <stdio.h>

int
main()
{
  something();
}
aroldan@volatile:~% cc -o xyz.so -shared xyz.c
aroldan@volatile:~% cat a.c
#include <dlfcn.h>
#include <stdio.h>

print(char *s)
{
 fprintf(stderr, "%s\n", s);
}

int main()
{
 void*v=dlopen("./xyz.so", RTLD_NOW);
 printf("%s\n", dlerror());

 //void *dlsym(void *handle, const char *symbol);
 //int dlclose(void *handle);

 return 0;
}
aroldan@volatile:~% cc -o a a.c -ldl
aroldan@volatile:~% ./a
./xyz.so: undefined symbol: something
aroldan@volatile:~% valgrind.bin --tool=memcheck ./a
==9779== Memcheck, a memory error detector for x86-linux.
==9779== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==9779== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==9779== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==9779== For more details, rerun with: -v
==9779==
/xyz.so: undefined symbol: something
==9779==
==9779== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)
==9779== malloc/free: in use at exit: 0 bytes in 0 blocks.
==9779== malloc/free: 9 allocs, 9 frees, 1007 bytes allocated.
==9779== For a detailed leak analysis, rerun with: --leak-check=yes
==9779== For counts of detected errors, rerun with: -v
aroldan@volatile:~% dpkg -l valgrind libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Estado=No/Instalado/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: mayúsc.=malo)
||/ Nombre Versión Descripción
+++-============================-============================-========================================================================
ii valgrind 2.2.0-4 A memory debugger for x86-linux
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries and Timezone data

--
Andrés Roldán

<email address hidden> / Fluidsignal Group S.A.
<email address hidden> / The Debian Project

Mobile: +57 300-7920981
GPG F/P: 0EE9 27C9 55F1 92E4 3809 B852 D8E0 724B B293 96EB
http://people.fluidsignal.com/~aroldan

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 09 Mar 2005 14:09:44 -0500
From: =?iso-8859-15?q?Andr=E9s_Rold=E1n?= <email address hidden>
To: <email address hidden>
Subject: Unreproducible

Hi, I still can't reproduce this bug using the latest versions
of libc6 and valgrind available on Debian. This is what I did:

aroldan@volatile:~% cat xyz.c
#include <stdio.h>

int
main()
{
  something();
}
aroldan@volatile:~% cc -o xyz.so -shared xyz.c=20=20=20=20=20=20=20=20=20=20
aroldan@volatile:~% cat a.c
#include <dlfcn.h>
#include <stdio.h>

print(char *s)
{
 fprintf(stderr, "%s\n", s);
}

int main()
{
 void*v=3Ddlopen("./xyz.so", RTLD_NOW);
 printf("%s\n", dlerror());

 //void *dlsym(void *handle, const char *symbol);
 //int dlclose(void *handle);

 return 0;
}
aroldan@volatile:~% cc -o a a.c -ldl=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20
aroldan@volatile:~% ./a
./xyz.so: undefined symbol: something
aroldan@volatile:~% valgrind.bin --tool=3Dmemcheck ./a
=3D=3D9779=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D9779=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward e=
t al.
=3D=3D9779=3D=3D Using valgrind-2.2.0, a program supervision framework for =
x86-linux.
=3D=3D9779=3D=3D Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward e=
t al.
=3D=3D9779=3D=3D For more details, rerun with: -v
=3D=3D9779=3D=3D=20
./xyz.so: undefined symbol: something
=3D=3D9779=3D=3D=20
=3D=3D9779=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 fr=
om 1)
=3D=3D9779=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D9779=3D=3D malloc/free: 9 allocs, 9 frees, 1007 bytes allocated.
=3D=3D9779=3D=3D For a detailed leak analysis, rerun with: --leak-check=3D=
yes
=3D=3D9779=3D=3D For counts of detected errors, rerun with: -v
aroldan@volatile:~% dpkg -l valgrind libc6
Desired=3DUnknown/Install/Remove/Purge/Hold
| Estado=3DNo/Instalado/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=3D(none)/Hold/Reinst-required/X=3Dboth-problems (Status,Err: may=FA=
 sc.=3Dmalo)
||/ Nombre Versi=F3n Descripci=
 =F3n
+++-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
ii valgrind 2.2.0-4 A memory debu=
gger for x86-linux
ii libc6 2.3.2.ds1-20 GNU C Library=
: Shared libraries and Timezone data

--=20
Andr=E9s Rold=E1n

<email address hidden> / Fluidsignal Group S.A.
<email address hidden> / The Debian Project

Mobile: +57 300-7920981
GPG F/P: 0EE9 27C9 55F1 92E4 3809 B852 D8E0 724B B293 96EB
http://people.fluidsignal.com/~aroldan

Revision history for this message
In , u19809 (wim-delvaux) wrote : Re: Bug#297798: valgrind error

On Wednesday 09 March 2005 18:14, Justin Pryzby wrote:
> Okay,
>
> Still trying to make sure I understand precisely what you're doing.
>
> It seems like you have a shared object called
>
>
> /mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcels/MSPApplic
>ation.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_TS.pex
>
> which contains an undefined symbol.
>
> file
> /mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcels/MSPApplic
>ation.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_TS.pex
>
> should say
>
> ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped

 correct, that file is just a rename of a .so file

>
> or something very similar. Right?
>
> And you are using
>
> void
> *v=dlopen("/mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcel
>s/MSPApplication.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_
>TS.pex", RTLD_NOW);

 yes. I must say that I did not try with RTLD_LAZY but with RTLD_NOW I get
the result you have.

 W

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Thu, 10 Mar 2005 01:06:01 +0100
From: wim delvaux <email address hidden>
To: Justin Pryzby <email address hidden>,
 <email address hidden>
Subject: Re: Bug#297798: valgrind error

On Wednesday 09 March 2005 18:14, Justin Pryzby wrote:
> Okay,
>
> Still trying to make sure I understand precisely what you're doing.
>
> It seems like you have a shared object called
>
>
> /mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcels/MSPApplic
>ation.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_TS.pex
>
> which contains an undefined symbol.
>
> file
> /mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcels/MSPApplic
>ation.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_TS.pex
>
> should say
>
> ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped

 correct, that file is just a rename of a .so file

>
> or something very similar. Right?
>
> And you are using
>
> void
> *v=dlopen("/mnt/buro/fs.permanent/home/u19809/projects/AP/MSP/Server/parcel
>s/MSPApplication.par/i686_Linux__Gnu.arch/debugthreaded_gcc3/MSPApplication_
>TS.pex", RTLD_NOW);

 yes. I must say that I did not try with RTLD_LAZY but with RTLD_NOW I get
the result you have.

 W

Jeff Bailey (jbailey)
Changed in glibc:
assignee: jbailey → nobody
Revision history for this message
Malcolm Parsons (malcolm-parsons) wrote :

Not a glibc bug.

Revision history for this message
Jonathan Anderson (jonathan-anderson) wrote :

Given the "yes. I must say that I did not try with RTLD_LAZY but with RTLD_NOW I get the result you have", I think that we can call this confirmed.

Changed in valgrind:
status: Unconfirmed → Confirmed
Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Thank you for posting this bug.

Does this occur in Lucid?

Changed in valgrind (Ubuntu):
status: Confirmed → Incomplete
Bug Watch Updater (bug-watch-updater)
Changed in valgrind (Debian):
status: New → Fix Released
Revision history for this message
Alessandro Ghedini (ghedo) wrote :

This should have been fixed around the 3.6.0 upstream release.

Changed in valgrind (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.