On Tuesday 29 March 2005 02:00, Paul Smith wrote: > Hi all; > > I'm seeing a strange problem. I have a UML kernel that was compiled on > a Red Hat 8.0 host system (kernel 2.4.18-19.8.0--I know, old eh? :-/). Well,for the host kernel it's not a so big problem. Out-of-date UML instead are much less reliable (for instance, we had to fix UML to let it run on 2.6 host kernel, or to cope with a recent glibc bug). > The UML kernel is 2.4.22. > > When I run the UML instance on any Red Hat 8.0 host system, it works > fine. > > When I take the SAME UML kernel and SAME root filesystem, etc., and run > it on a Red Hat Enterprise Linux 3 system, it works _almost_ fine. But > there are some odd things. Not all of them I've tracked down (some > could be something with our environment), but here's one I have:
> I compile valgrind 2.4.0 against the contents of the UML rootfs, and > then run it from inside UML on the RH8.0 host, and it works fine on the > RH8.0 host system. > > I take that exact same compilation of valgrind (and same rootfs, same > UML kernel) and start it on the RHEL host system, and when I use the > memcheck tool (the default) it dumps core inside valgrind, in a strange > way. No matter what app I try to use it with: even something like > "valgrind /bin/echo hi". The other valgrind tools (addrcheck, etc.) all > seem to work fine, and most other basic tools. > > I'm pursuing this with the valgrind folks as well, but given the > situation I have to assume it's some kind of interaction between the UML > kernel process and the host distribution: either the kernel, or libc, or > something. I didn't expect that the UML kernel would need to be > recompiled for different host systems, at least not in general. > Is this > an expected situation that I need to look out for, or is this unusual > and normally I wouldn't have to do this? Have you investigated the first hypotesis for this case, i.e. that Valgrind compiled on RH8.0 does not work on a RHEL 3, because of some particular dependencies / bugs somewhere (not in UML)? In the above description, there is nothing specific to UML (for this particular problem), unless I'm overlooking something. I assume such a old UML kernel *must* have some problems when run on a RHEL 3 host, and it would have a lot more if run on a 2. An example of why RHEL 3 wouldn't support Valgrind could be, for instance, a bug into the NPTL libraries (try running Valgrind without TLS libraries, i.e. either export LD_ASSUME_KERNEL=2.4.1 or move away temporarily, just for the test, /lib/tls). Yes, I've experienced such situations with UML itself (the bug wasn't in RHEL but in NPTL glibc itself). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
