View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000886 | LDMud 3.6 | Runtime | public | 2021-03-30 02:38 | 2021-04-06 21:30 |
Reporter | gorgar | Assigned To | Gnomi | ||
Priority | normal | Severity | crash | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Fixed in Version | 3.6.4 | ||||
Summary | 0000886: crash when mssp enabled | ||||
Description | Game is crashing under rather odd circumstances: 1. mssp recently configured and may not be configured perfectly 2. user pastes a very long message to a channel via discord with raw text from mssp values (from client) 3. mud crashes few seconds later Despite the oddness and possible misconfiguration with mssp, didn't think that should justify a crash. | ||||
Additional Information | LDMUD 3.6.0-22-g42134c1f err: [xerq] read: Success 2021.03.29 20:58:47 [xerq] Demon exiting. debug.log: 2021.03.29 20:58:46 (terminal_colour) indent 259 > wrap 80 core and ldmud file: https://drive.google.com/drive/folders/1UF1vMUsewDXwc7opX8jvDILgXETGcxVc?usp=sharing Note: ldmud is symlinked to dev-ldmud | ||||
Tags | No tags attached. | ||||
|
I think this crash may have been fixed in LDMud 3.6.2. Could you verify that with an updated version of LDMud? |
|
Disregard my last comment. The terminal_colour message is just an error message, not a fatal error. But it seems, the binary and core file do not match. I can't get any information from the core file. Are there any more messages before the '[xerq] read: Success' line? |
|
As I said I can't get much, because the binary does not seem to match. This is what I could gather from the core file alone: The crash happened in an object named '/guilds/channel_d', in the function SendChannel. The function calls a lambda, which calls the efun terminal_colour() with a string, that seems like MSSP info, a mapping for colouring, a width of 80 and indent of 259. As the indent is wider than the width, terminal_colour will throw an error. This error is not yet handled, a call trace was not generated and the master not called, yet. So my guess is that the problem might lie within get_line_number_if_any(), but I couldn't reproduce it. |
|
The core should match but the binary is symlinked to dev-ldmud. Did upgrade to 3.6.2 last nite but havent reproduced the crash yet. |
|
The reason was an out-of-bounds write into a buffer for the name of the lambda. Normally this wouldn't crash the driver, but in this case the driver was compiled with -D_FORTIFY_SOURCE which leads to an abortion with a message "*** buffer overflow detected ***" on standard error. Fixed it in https://github.com/amotzkau/ldmud/commit/f2238d7170ac1065f10f83934e1be6303de36720 |
Date Modified | Username | Field | Change |
---|---|---|---|
2021-03-30 02:38 | gorgar | New Issue | |
2021-03-30 06:45 | Gnomi | Note Added: 0002558 | |
2021-03-30 10:28 | Gnomi | Note Added: 0002559 | |
2021-03-30 12:08 | Gnomi | Note Added: 0002560 | |
2021-03-30 12:20 | gorgar | Note Added: 0002561 | |
2021-03-30 15:06 | Gnomi | Assigned To | => Gnomi |
2021-03-30 15:06 | Gnomi | Status | new => assigned |
2021-03-30 15:46 | Gnomi | Note Added: 0002563 | |
2021-04-06 21:30 | Gnomi | Status | assigned => resolved |
2021-04-06 21:30 | Gnomi | Resolution | open => fixed |
2021-04-06 21:30 | Gnomi | Fixed in Version | => 3.6.4 |