|
From: Christoph B. <bar...@or...> - 2005-09-28 14:50:47
|
Hi, I use the latest subversion revision and get during the execution the following error: bzip2: error while loading shared libraries: /lfs/user/bartosch/software/vg-test/lib/valgrind/vg_preload_core.so: cannot open shared object file: No such file or directory The main application forks and execs bzip2 when this error appears. The mentioned file exists of course. What could be wrong? Chrisotoph Bartoschek |
|
From: Tom H. <to...@co...> - 2005-09-28 15:07:07
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> wrote:
> I use the latest subversion revision and get during the execution the
> following error:
>
> bzip2: error while loading shared
> libraries: /lfs/user/bartosch/software/vg-test/lib/valgrind/vg_preload_core.so:
> cannot open shared object file: No such file or directory
>
>
> The main application forks and execs bzip2 when this error appears. The
> mentioned file exists of course.
Is the file the right type though? What does file say about it?
The reason I ask is that the dynamic linker ignores 32 bit libraries
while running a 64 bit program and vice versa, so you can get that
message if the library exists but is the wrong format.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christoph B. <bar...@or...> - 2005-09-28 16:36:34
|
Am Mittwoch, 28. September 2005 17:06 schrieb Tom Hughes: > Is the file the right type though? What does file say about it? > > The reason I ask is that the dynamic linker ignores 32 bit libraries > while running a 64 bit program and vice versa, so you can get that > message if the library exists but is the wrong format. > > Tom bzip2 is 32bit and vg_preload_core.so is 64bit. Therefore I assume that I can ignore the message because it is only generated by the linker as a warning. However valgrind later seems to hang in an endless loop because it stalls at a location which is normally executed within tens of a second and the backtrace has more than 60000 frames. Is this possible? How to verify or debug such a situation? Christoph |
|
From: Tom H. <to...@co...> - 2005-09-28 16:45:44
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> wrote:
> Am Mittwoch, 28. September 2005 17:06 schrieb Tom Hughes:
>
> > Is the file the right type though? What does file say about it?
> >
> > The reason I ask is that the dynamic linker ignores 32 bit libraries
> > while running a 64 bit program and vice versa, so you can get that
> > message if the library exists but is the wrong format.
>
> bzip2 is 32bit and vg_preload_core.so is 64bit. Therefore I assume that I
> can ignore the message because it is only generated by the linker as a
> warning.
You shouldn't ignore it as it means that the preload library won't
have been injected into the client. I think the only effect of that
is to stop the C library resources being freed on exit though.
There is obviously something badly wrong however as it looks like
you are trying to valgrind a 32 bit program with a 64 bit valgrind
except that you shouldn't be able to do that - it should complain
and exit if you try as that doesn't work.
Presumably this is a 64 bit machine - how exactly did you configure
valgrind? Did you intend it to be a 32 or 64 bit valgrind?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christoph B. <bar...@or...> - 2005-09-28 21:36:54
|
> > You shouldn't ignore it as it means that the preload library won't > have been injected into the client. I think the only effect of that > is to stop the C library resources being freed on exit though. > > There is obviously something badly wrong however as it looks like > you are trying to valgrind a 32 bit program with a 64 bit valgrind > except that you shouldn't be able to do that - it should complain > and exit if you try as that doesn't work. > > Presumably this is a 64 bit machine - how exactly did you configure > valgrind? Did you intend it to be a 32 or 64 bit valgrind? I am trying to valgrind a 64bit program on a 64bit machine. However this programm forks off bzip2 to compress a log file it writes out. bzip2 is 32bit on this machine. 64bit valgrind cannot analyse 32bit applications right now. That's why the main program is not run with --trace-children=yes. Christoph |
|
From: Tom H. <to...@co...> - 2005-09-28 22:53:33
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> wrote:
> > You shouldn't ignore it as it means that the preload library won't
> > have been injected into the client. I think the only effect of that
> > is to stop the C library resources being freed on exit though.
> >
> > There is obviously something badly wrong however as it looks like
> > you are trying to valgrind a 32 bit program with a 64 bit valgrind
> > except that you shouldn't be able to do that - it should complain
> > and exit if you try as that doesn't work.
> >
> > Presumably this is a 64 bit machine - how exactly did you configure
> > valgrind? Did you intend it to be a 32 or 64 bit valgrind?
>
> I am trying to valgrind a 64bit program on a 64bit machine. However this
> programm forks off bzip2 to compress a log file it writes out. bzip2 is 32bit
> on this machine. 64bit valgrind cannot analyse 32bit applications right now.
> That's why the main program is not run with --trace-children=yes.
Ah right. Now I understand.
The problem seems to be that LD_PRELOAD is not being cleared when
a program is execed and --trace-children is not set. That is a bug.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-09-28 23:52:31
|
> The problem seems to be that LD_PRELOAD is not being cleared when > a program is execed and --trace-children is not set. That is a bug. That should be done by m_libcproc.c:VG_(env_remove_valgrind_env_stuff). However, looking at that I see there is some confusion in what the .so's are really called. Christoph, m_libcproc.c:206 should look like this: VG_(sprintf)(buf, "%s*/vgpreload_core.so", VG_(libdir)); If you change that to VG_(sprintf)(buf, "%s*/vg_preload_core.so", VG_(libdir)); and rebuild, is there any difference in behaviour? Note, don't mess with line 208 (yes, I know this is inconsistent). J |
|
From: Nicholas N. <nj...@cs...> - 2005-09-29 00:19:23
|
On Thu, 29 Sep 2005, Julian Seward wrote: > That should be done by m_libcproc.c:VG_(env_remove_valgrind_env_stuff). > > However, looking at that I see there is some confusion in what the > .so's are really called. > > Christoph, m_libcproc.c:206 should look like this: > > VG_(sprintf)(buf, "%s*/vgpreload_core.so", VG_(libdir)); > > If you change that to > > VG_(sprintf)(buf, "%s*/vg_preload_core.so", VG_(libdir)); > > and rebuild, is there any difference in behaviour? Note, don't > mess with line 208 (yes, I know this is inconsistent). I think this got screwed up by the ASPACEM merge. I renamed vg_preload_core.so to vgpreload_core.so in r4514 (in the trunk) to make it consistent with the tool file names (eg. vgpreload_memcheck.so). So line m_libcproc.c:206 is right, it's the Makefiles that refer to vg_preload_core.so that are wrong. I'll commit a fix for it shortly. Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-09-29 00:32:35
|
On Wed, 28 Sep 2005, Nicholas Nethercote wrote: > I think this got screwed up by the ASPACEM merge. I renamed > vg_preload_core.so to vgpreload_core.so in r4514 (in the trunk) to make it > consistent with the tool file names (eg. vgpreload_memcheck.so). So line > m_libcproc.c:206 is right, it's the Makefiles that refer to > vg_preload_core.so that are wrong. I'll commit a fix for it shortly. Ok, it's committed. Christoph, can you try it, and let it know if it works? Thanks. Nick |
|
From: Christoph B. <bar...@or...> - 2005-09-29 10:28:51
|
Am Donnerstag, 29. September 2005 02:32 schrieb Nicholas Nethercote: > On Wed, 28 Sep 2005, Nicholas Nethercote wrote: > > I think this got screwed up by the ASPACEM merge. I renamed > > vg_preload_core.so to vgpreload_core.so in r4514 (in the trunk) to make > > it consistent with the tool file names (eg. vgpreload_memcheck.so). So > > line m_libcproc.c:206 is right, it's the Makefiles that refer to > > vg_preload_core.so that are wrong. I'll commit a fix for it shortly. > > Ok, it's committed. Christoph, can you try it, and let it know if it > works? Thanks. The current version does not show the message anymore. However valgrind still seems to stall at one position. I suspect an endless loop there. Christoph |