-
Notifications
You must be signed in to change notification settings - Fork 1
/
IT_CRASHED
130 lines (97 loc) · 4.4 KB
/
IT_CRASHED
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
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
It Crashed!!!
by Beek and Robocoder
***
*** Contents
***
1) Introduction
2) General Notes
3) Unattended operation/automation
4) Debugging core files
5) Notes for SAS/C Amiga users
***
*** Introduction
***
This file documents some methods of obtaining crash information which
the MudOS developers may find useful in tracking down hard to reproduce
crashers (serious bugs).
***
*** General Notes
***
Ok, if your driver crashes, and you want to be helpful, here's what you do:
1. recompile the driver with the -g flag. Turning off optimization
is a good idea too. [This can be done by doing a 'make neat' (or gmake),
reruning ./build.MudOS as follows: './build.MudOS debug', then recompile]
2. go to your bin dir and type 'gdb driver' where driver is the name of your
driver executable
3. It should startup, etc. When it's ready, type 'run config.foo' or
whatever you normally do to run the driver, with 'run' instead of the
driver executable name.
4. Wait for the driver to crash (or cause it to crash, if you know how)
5. gdb should give you a prompt again. type 'where'
6. Post the output of the where command along with anything you know
about where/how/why the driver crashed on the MudOS bug report board.
Stuff like example LPC source code, a tail of driver.err and/or
debug.log, etc may be helpful. In some cases the driver writes important
information to those files as it goes down.
If you actually get a traceback, it makes crashes somewhere between
10-100x easier to fix (at least!). Remember to also specify your
driver version (eg 0.9.19), operating system/architecture, and its
version (eg SunOS 5.3).
Note:
If you didn't use 'gcc', but 'cc' instead (for example), to compile the
driver, you will have to use 'dbx' (if you have it). The same
instructions as above apply...just replace instances of 'gdb' with 'dbx'.
***
*** Unattended operation/automation
***
If you want to automate the process of collecting this crash information,
something you can stick this into your startmud script, read this section.
Begin by creating a batchfile with the following contents:
run config.foo >driver.err
where
Replace 'config.foo' with the name of your config file, and 'driver.err'
with whatever you've set up for redirecting the driver's stderr to.
Where you have 'driver' (or whatever you named the executable) in your
startmud script, use (depending on the compiler used):
gdb -batch -x batchfile driver >report
or:
dbx -i driver <batchfile >report
If/when it crashes, send us a copy of the report.
***
*** Debugging core files
***
This section applies to you, if the driver has crashed, leaving a
core file behind. A large core file is a good sign. =) Some users or
systems may set a resource limit on the size of core files, eg
limit coredumpsize 0
preventing them from debugging from the core file. Remove the limit
or skip this section. HP/Apollo (Domain OS) users may be able to use
'/com/tb' to get traceback information.
Using dbx: Using gdb:
dbx driver core gdb driver core
where where
quit quit
Replace 'driver' with the path of your driver executable.
Another useful command is 'print', which can be used to print the
values of variables in the current function, eg
print str
'dbx' users can also use the 'dump' command to display the names and
variable values in a function, eg
dump main >file
***
*** SAS/C (Amiga)
***
If you are using SAS/C, compile with Debug=Symbol and link with AddSym.
It's a good to turn off optimizations with NoOpt and NoOptPeep.
You can use either 'cpr' or 'tb'. For 'cpr', use:
cpr -line -command "where -a; register" driver config.foo >report
Using 'tb' is a bit more involved. In building the driver, you must:
slink with catch.o or catchnr.o to generate snapshot files
so that if/when the driver crashes, the 'tb' utility can be used to process
the snapshot file. catch.o will ask first before creating a snapshot file,
while catchnr.o will not ask -- if the system is in a bad state, and
catchnr.o is unable to complete writing the snapshot file, the filesystem
can be potentially corrupted. Once you have a 'Snapshot.TB' file, use:
tb -l
to obtain detailed traceback information
--- EOF ---