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 application because it wants
to printf it.

if that free occurs all the time it might break other applications too.


>
> Thanks,
> Justin