Njamd v0.8 Release Notes (Euphemism for "BUGS and Which OS's Suck" :) The front end is ncurses-only and pretty sloppy. If anyone wants to write a better one, or a GTK version, be my guest! The groundwork is already layed for you. Have a look at docs/DESIGN and docs/njamd.txt for an overview of the system. Portability chart: Platform Ver Features ~~~~~~~~ ~~~ ~~~~~~~~ Linux/x86 2.0 All Linux/x86 2.2 All Linux/x86 2.4 All Linux/MIPS 2.2 FAIL :( Solaris/Sparc 2.6 No static code stack trace Solaris/Ultra64 2.7 " FreeBSD/x86 3.3 No MT, no dlopen FreeBSD/x86 4.0 No MT NetBSD/x86 1.4P No MT OpenBSD/x86 2.6 " + No PRELOAD OpenBSD/Sparc 2.6 " + " + No static code stack trace IRIX/MIPS 6.2 No dlopen, no stack trace. HPUX B.10.20 Barely works. No MT, no PRELOAD, no retaddrs at ALL AIX 3.2.5 (OLD) Also barely works. Ret addrs tho. I. OS Specific Notes Linux/kernel: The Linux kernel unfortunately places a limit of 65536 on the max number of mappings you can have. One person cited a security reason, but I can't see anything that you can do with lots of mappings that RLIMIT_AS can't fix. At any rate, I wrote two sets of patches, one that sets the max limit to number of maps in the address space, and another that allows it to be controlled by proc or sysctl (/proc/sys/vm/max_map_count & vm.max_map_count). Sorry I had to do this, but there really isn't a way around it. If you know someone on the inside of the Linux VM team, see if you can do a little arm twisting to get this included in the main tree :) Also, setting NJAMD_CHK_FREE=none may help a little, but then you lose functionality. You will need this patch to debug Mozilla. Linux/GDB: I have heard reports that gdb 5.0 is having problems with NJAMD. I'm not sure what causes this, but I do know that using a gdb snapshot will fix it. If you can reproduce this bug on a major distribution that ships with gdb 5 (RedHat 7.0), please let me know and/or contact them. Send me code snippets, please! Linux/MIPS: Linux/MIPS is going to have to be filed under unsupported. I broke something MIPS-related and the MIPS system I have access to is horribly out of date and is missing key development tools (gdb, g++), so it's a big pain in the ass to perform any debugging. If anyone has an up-to-date Linux/MIPS system and would like to give me an temporary account, I'd be happy to fix it. Same goes for any other platform. *BSD: The framework for *BSD MT support is in place, and libnjamd_r.so gets built, but for some reason, our malloc is only used by the pthread routines. Once main is entered, libc malloc is used. I thought it had something to do with libtool insisting on linking against libc and libc_r. But I forced it to only link with libc_r, and it still doesn't work.. What's worse is that in the MT libs, writing to stderr seems to not have any effect before main, so it's hard to trace. Lookin to you F/OBSD guru's to shed some light on the subject :) FreeBSD is also very dumb about dumping core. I think I fix this in the source. Let me know if you still get huge coredumps. For OpenBSD and other a.out systems, you will have to link with the library at compile time. Solaris: For Solaris 2.6 and gdb 4.17, programs being debugged with LD_PRELOAD halt somewhere in the init code complaining about unable to find fd 8 in /proc. This is obviously not our problem, and appears to be harmless. Simply issue 'cont' to continue. II. API Notes The sigaction(2) flags (with the exception of SA_SIGINFO) and mask will not work right for SIGSEGV, USR1, TERM, BUS, or INT with this release. For now, signal handlers and actions for these signals behave as if they used the SA_RESTART and BSD style (non-ONESHOT) flags, regardless of what you specify. All other signals are unaffected. Possible issues with globally initialized classes in C++ may exist. III. Application specific notes When using OmniORB with NJAMD (or in general, for best results), you must reorder the ldflags so -lpthread (and -ltcpwrapGK) come before -lomnithread. See http://www.uk.research.att.com/omniORB/archives/2000-07/0133.html (and the rest of the thread) for more info. netscape crashes mysteriously, and as far as I can tell, before it even enters our code. They're probably doing something unsane with their own threads implementation, not too much unlike OmniORB I imagine. IV. GCC Flags When programs are compiled with -fomit-frame-pointer (insane levels of -O will do this too) they will not have any return address information in them (and will segfault in return_address in util.c). The gcc manpages explicitly warn not to define this flag if you are planning on debugging, unfortunately at least one library (libfftw) defines this optimization. If you want to debug programs using libfftw, either take -fomit-frame-pointers from the Makefile and rebuild libfftw, or export NJAMD_NO_TRACE=1. V. Features to expect by 1.0 See TODO Mail mikepery@fscked.org with questions, bugs, suggestions, patches and news of of new architecture's sucess rates.