1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
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.
|
