You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Adds a function to create a core dump on demand
Signed-off-by: Simon Davies <[email protected]>
* Add gdb script and update docs
Signed-off-by: Simon Davies <[email protected]>
---------
Signed-off-by: Simon Davies <[email protected]>
## Dumping the guest state to an ELF core dump when an unhandled crash occurs
210
+
## Dumping the guest state to an ELF core dump
211
211
212
-
When a guest crashes because of an unknown VmExit or unhandled exception, the vCPU state is dumped to an `ELF` core dump file.
212
+
When a guest crashes because of an unknown VmExit or unhandled exception, the vCPU state can be optionally dumped to an `ELF` core dump file.
213
213
This can be used to inspect the state of the guest at the time of the crash.
214
214
215
-
To make Hyperlight dump the state of the vCPU (general purpose registers, registers) to an `ELF` core dump file, enable the `crashdump`
216
-
feature and run.
215
+
To make Hyperlight dump the state of the vCPU (general purpose registers, registers) to an `ELF` core dump file, enable the `crashdump` feature and run.
217
216
The feature enables the creation of core dump files for both debug and release builds of Hyperlight hosts.
218
217
By default, Hyperlight places the core dumps in the temporary directory (platform specific).
219
218
To change this, use the `HYPERLIGHT_CORE_DUMP_DIR` environment variable to specify a directory.
@@ -227,6 +226,39 @@ To selectively disable this feature for a specific sandbox, you can set the `gue
227
226
cfg.set_guest_core_dump(false); // Disable core dump for this sandbox
228
227
```
229
228
229
+
## Creating a dump on demand
230
+
231
+
You can also create a core dump of the current state of the guest on demand by calling the `generate_crashdump` method on the `InitializedMultiUseSandbox` instance. This can be useful for debugging issues in the guest that do not cause crashes (e.g., a guest function that does not return).
232
+
233
+
This is only available when the `crashdump` feature is enabled and then only if the sandbox
234
+
is also configured to allow core dumps (which is the default behavior).
235
+
236
+
### Example
237
+
238
+
Attach to your running process with gdb and call this function:
239
+
240
+
```shell
241
+
sudo gdb -p <pid_of_your_process>
242
+
(gdb) info threads
243
+
# find the thread that is running the guest function you want to debug
244
+
(gdb) thread <thread_number>
245
+
# switch to the frame where you have access to your MultiUseSandbox instance
246
+
(gdb) backtrace
247
+
(gdb) frame <frame_number>
248
+
# get the pointer to your MultiUseSandbox instance
249
+
# Get the sandbox pointer
250
+
(gdb) print sandbox
251
+
# Call the crashdump function with the pointer
252
+
# Call the crashdump function
253
+
call sandbox.generate_crashdump()
254
+
```
255
+
The crashdump should be available `/tmp` or in the crash dump directory (see `HYPERLIGHT_CORE_DUMP_DIR` env var). To make this process easier, you can also create a gdb script that automates these steps. You can find an example script [here](../scripts/dump_all_sandboxes.gdb). This script will try and generate a crashdump for every active thread except thread 1 , it assumes that the variable sandbox exists in frame 15 on every thread. You can edit it to fit your needs. Then use it like this:
256
+
257
+
```shell
258
+
(gdb) source scripts/dump_all_sandboxes.gdb
259
+
(gdb) dump_all_sandboxes
260
+
```
261
+
230
262
### Inspecting the core dump
231
263
232
264
After the core dump has been created, to inspect the state of the guest, load the core dump file using `gdb` or `lldb`.
0 commit comments