On Tue, 5 Feb 2002, Paul Sargent wrote: > This might not be classed as a debian problem per-se, but I'm > wondering if anybody here has any suggestions to get me out of this > hole, a hole which is probably more political than technical. Maybe > somebody else has been in a similar situation.
It looks to me like a library incompatibility issue. Differences in the way the libc handles malloc can cause weird problems for programs that have memory allocation bugs. Since glibc changes the behavior of malloc on a quite regular basis, and redhat likes to patch their stuff anyway, it's quite possible that the bug-tolerance is different between the two. The simplest thing IMO is to just keep them on separate boxes :} A worse problem is a kernel difference. Although I think this is unlikely due to the nature of the error. The possible good news here is that it's likely that you can find a kernel that will run both applications, although it might not be supported by one of the developers. Look into the possibility that the kernel you are using suffers from one of the miscellaneous Athlon bugs (or rather, Athlon motherboard bugs). I doubt this is the problem, but it wouldn't hurt to check. Installing a hard drive containing their supported system and booting that would allow you to rule out a hardware problem. Another option is to just put the entire RedHat system into a directory tree on your Debian system, use chroot to access it, and see if that works. If it does, it rules out a kernel problem and it rules out any problems with running system services. On the other hand, it will create new problems pertaining to the Jekyll-and-Hyde nature of a system that has two /etc/passwd files, etc. etc. You might consider having Vendor B send you a completely statically linked binary that doesn't use dynamically linked anything, including (or rather especially) libc. This is marginally less efficient in terms of memory use, but if it runs on your system, you know the problem is a library incompatibility. (the memory wastage is pretty small; unless you run a lot of simultaneous copies of the application, you probably don't have to worry about it - unless it's a really big X application, and maybe not even then given the size of your system). Or, you might copy the libraries off of the supported system into /usr/local/lib/redhat, or some such. Use LD_LIBRARY_PATH to cause Application B to use this set of libraries, instead of the regular ones. It's not necessarily just libc that could be at fault. Any system library might be responsible - the X libraries tend to be a nuisance as well. > and the other hide it? My guess is that it's to do with the memory > setup (see below) changing the address space that the app is living > in, but that's just a guess. There should be no problems resulting from address space. The app should see the address space the same regardless of the situation with the physical memory (if my understanding of the large-memory patches is correct). > Has anybody else ever found themselves in a similar situation? Any > suggestions for how to get out? It is a continous and ongoing nuisance in HP/UX :}
