-
Notifications
You must be signed in to change notification settings - Fork 0
/
TEXT_PROTOCOL
196 lines (151 loc) · 7.77 KB
/
TEXT_PROTOCOL
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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
Text data protocol
------------------
The text data is generated by post-processor and resolver. It
contains the binary data in human readable format plus additional
information added during post-processing and resolving.
1. Header
Header consists of key=value pairs specifying general information
about the report. It is the first line in the report containing
key-value pairs in format:
<key>=<value>[,<key>=<value>[,...]]
Where keys can be:
<version> - the format version
<arch> - the report origin system architecture
<timestamp> - the report creation time
<process> - the tracked process name
<pid> - the tracked process identifier
<filter> - the applied filters. Currently the following
filters are supported:
leaks - freed resources removal
compress - log compression by grouping
calls by backtraces
resolve - backtrace resolving
<backtrace depth> - the maximum number of stack frames in backtraces
<origin> - the initial log generator tool
2. Memory map
Contains executable and library memory mapping information used to
resolve names. Usually written in beginning of the report, but can
be anywhere (it must be written before its address range is used in
backtraces):
: <module path> => <start address>-<end address>
Where:
<module path> - full path to the mapped file
<start address> - the start address in hexadecimal format (0x...)
<end address> - the end address in hexadecimal format (0x...)
3. Comments
Contains any additional information reported by the tracing tool,
but not used in the post-processing. For example libleaks style
heap status information or functracer debug information. Can be
anywhere in the report file.
Post-processing utilities can parse comments to retrieve some
additional information, but unrecognized comments must be passed
through unmodified (if post-processing keeps the same output
format).
Comments usually start with '#' character for better recognition,
but it's not a requirement. All lines, not recognized as other
record types, will be interpreted as comments.
Comments where # is followed with ' ' (space) are treated as
temporary comments and discarded by the next post-processor run:
<information>
Where:
<information> - any additional information reported by the tracing tool.
4. Allocation report
Contains information about resource (memory, file descriptors etc)
allocation:
<index>. [@<context id>] \[<timestamp>\] <function name>\<<resource type>\>
(<resource size>) = <resource id>
<bactrace>
Where:
<index> - the allocation/deallocation report index.
<context id> - an optional context id
(omitted if no contexts are set during the allocation).
<timestamp> - optional timestmap, absent if the header 'timestamps'
option is set to 'no' (in HH:MM:SS.ssssss format).
<function name> - the function name, allocator of the resource.
<resource type> - an optional resource type id
(omitted if only one resource type is being tracked).
<resource size> - the size of the allocated resource
(whenever it's possible to calculate it).
<resource id> - the resource identifier returned by allocator function
and used to uniquely identify the allocated resource
(in hexadecimal format 0x...).
<arguments> - A list of function arguments (see the arguments record
description for full specification).
<backtrace> - a backtrace of the allocator function call (see the
backtrace description for full specification).
5. Deallocation report
Contains information about resource freeing:
<index>. [@<context id>] \[<timestamp>\] <function name>\<<resource type>\>(<resource id>)
<arguments>
<bactrace>
Where:
<index> - the allocation/deallocation report index.
<context id> - an optional context id
(omitted if no contexts are set during the dealocation).
<timestamp> - optional timestmap, absent if the header 'timestamps'
option is set to 'no' (in HH:MM:SS.ssssss format).
<function name> - the function name, allocator of the resource.
<resource type> - an optional resource type id
(omitted if only one resource type is being tracked).
<resource id> - the resource identifier returned by allocator function
and used to uniquely identify the allocated resource
(in hexadecimal format 0x...).
<arguments> - A list of function arguments (see the arguments record
description for full specification).
<backtrace> - a backtrace of the allocator function call (see the
backtrace description for full specification).
6. Backtrace
Contains stack trace of the caller function (with resolved or unresolved
names). The backtrace format is similar to gdb backtrace format:
<tab><address>[ in <function>()][ from <module>| at <source location>]
...
<tab><address>[ in <function>()][ from <module>| at <source location>]
Where:
<tab> - a tabulation character for readibility and recognition.
<module> - name of the function module.
<function> - name of the function itself (optional, might be absent
if name resolving was not enabled).
<address> - the actual return address (in hexadecimal format).
<source location> - the function location in source file -
<line:line number>.
7. Context registry
Contains information about used allocation contexts. Allocation
contexts are used to mark allocations done during some time period
(usually while some specific task is completed). Context registry
lists the used allocation ID's and their names:
@ <context id> : <context name>
Where:
<context id> - the allocation context id (context id basically is
bit value to be set in allocation record context).
<context name> - user friendly context name.
8. Function argument list
The function argument list is optional and is treated as comments
by most post-processing scripts. Contains a list of function
argument values:
$1 = <value>
$2 = <value>
...
$n = <value>
Where:
1...n - the argument number
<value> - the argument value. Could have complex value for
structure and array values.
9. Resource registry
Contains information about tracked resource types. The resource
types are used to identify resources when multiple modules or a
mudule, tracking multiple resources is used:
\<<id>\> : <type> (<desc>) [\[<flag1>[|<flag2>]...\]]
Where:
<id> - the resource id.
<type> - the resource type name.
<desc> - the resource type description.
<flag1>, <flag2> .. - the resource behaviour flags.
refcount - specifies that the resource allocs/frees use
reference counting.
10. File attachment
Contains information about custom data files attached to the report:
& <name> : <path>
Where:
<name> - the attachment name. Used to identify different
attachments.
<path> - name of the attached file.