Hi Eric, Yes, all the linux jdks (sparc, x86, and ppc) redefine all of the malloc related functions including free, malloc, realloc, calloc, etc. The really are 2 reasons for doing this: 1. make sure free, malloc, realloc, calloc, etc are all green_thread safe (i.e. we add locks around the standard free, malloc, etc) This explains the reason you get the OUCH: nested message: two or more user based threads are trying to use a malloc function at the same time (or one thread recursively). 2. having our own malloc functions allows us to more easily debug memory problems and provide work-arounds. For example, motif has some bugs that caused spurious frees and seg-faults which we finally tracked down and fixed, but most people's version of motif will not have these bug fixes. Using our own malloc, we can try and capture these problems and prevent corruption. The versions of the malloc related functions we use are all taken from Doug Lea's dl-malloc.c version 2.6.2, which he released into the public domain. A later version of this exact library with extensions made by some Germans (whose name or names I can't remember off the top of my head) is used to make the malloc functions linux-thread safe. It is actually used in the version of glibc used on Linux PowerPC and may be used by other glibc versions. I am sure you can find this file on the web someplace if you are interested in the implementations details. Theses malloc related functions do work well. If you want to, you can call these malloc routines directly, with out the locks that make them green_threads safe by prepending the word java_ to the front of each function (for example java_free). Please check this by using nm on libjava.so and you should see the java_ prefaced symbols listed someplace. Please be careful if you do that, these functions without the wrapping locks are not green_thread safe. I hope all of this helps. Please e-mail me directly if you want or need more info. Thanks, Kevin Hendricks LinuxPPC JDK Porting Team [EMAIL PROTECTED]
