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).
==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.
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 strmem. c:189) Handling_ A.c:136) Handling_ A.c:202) Handling_ A.c:268) FindAndLoadParc elOfComponent _A.c:759) FindAndLoadParc el (REPO.c:196) .c:776) .c:995) .c:1457) .c:2023) ByCID (ActivatorLoade r_A.c:98) malloc. c:153) c:2369) A.c:112) Handling_ A.c:118) Handling_ A.c:202) Handling_ A.c:268) FindAndLoadParc elOfComponent _A.c:759) FindAndLoadParc el (REPO.c:196) .c:776) .c:995) .c:1457) .c:2023)
==8220== at 0x1B906788: strlen (mac_replace_
==8220== by 0x1C0EB249: AC_vfnprintf (fnprintf_A.c:299)
==8220== by 0x1C0EAB39: AC_vfdprintf (fdprintf_A.c:9)
==8220== by 0x1C0EA02D: AC_VLog (ActivatorError
==8220== by 0x1C0EA3EC: AC_VRaiseExc (ActivatorError
==8220== by 0x1C0EA559: AC_RaiseExc (ActivatorError
==8220== by 0x1C5FDA8D: Repo2Pex_Load (PEX_A.c:35)
==8220== by 0x1B9192DA: Repo2Mgr_
(P_Repo2Manager
==8220== by 0x1B90CADE: TOREPO_
==8220== by 0x1B90E8A9: ILoadComponent (StdRootManager
==8220== by 0x1B90F763: CheckCompRefQuality (StdRootManager
==8220== by 0x1B910DC8: FindBehavior (StdRootManager
==8220== by 0x1B9128BD: Wrap_FindBehavior (StdRootManager
==8220== by 0x1C0EBF42: AC_FindBehavior
==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_
==8220== by 0x1C1284FA: _dlerror_run (dlerror.c:140)
==8220== by 0x1C128153: dlsym (dlsym.c:51)
==8220== by 0x1C0FE263: write (vg_libpthread.
==8220== by 0x1C0EFF1D: AC_WriteExt (ActivatorIo_
==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 (ActivatorError
==8220== by 0x1C0EA3EC: AC_VRaiseExc (ActivatorError
==8220== by 0x1C0EA559: AC_RaiseExc (ActivatorError
==8220== by 0x1C5FDA8D: Repo2Pex_Load (PEX_A.c:35)
==8220== by 0x1B9192DA: Repo2Mgr_
(P_Repo2Manager
==8220== by 0x1B90CADE: TOREPO_
==8220== by 0x1B90E8A9: ILoadComponent (StdRootManager
==8220== by 0x1B90F763: CheckCompRefQuality (StdRootManager
==8220== by 0x1B910DC8: FindBehavior (StdRootManager
==8220== by 0x1B9128BD: Wrap_FindBehavior (StdRootManager
==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