View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000886||LDMud 3.6||Runtime||public||2021-03-30 04:38||2021-04-06 23:30|
|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|
[xerq] read: Success
2021.03.29 20:58:47 [xerq] Demon exiting.
2021.03.29 20:58:46 (terminal_colour) indent 259 > wrap 80
core and ldmud file:
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
|2021-03-30 04:38||gorgar||New Issue|
|2021-03-30 08:45||Gnomi||Note Added: 0002558|
|2021-03-30 12:28||Gnomi||Note Added: 0002559|
|2021-03-30 14:08||Gnomi||Note Added: 0002560|
|2021-03-30 14:20||gorgar||Note Added: 0002561|
|2021-03-30 17:06||Gnomi||Assigned To||=> Gnomi|
|2021-03-30 17:06||Gnomi||Status||new => assigned|
|2021-03-30 17:46||Gnomi||Note Added: 0002563|
|2021-04-06 23:30||Gnomi||Status||assigned => resolved|
|2021-04-06 23:30||Gnomi||Resolution||open => fixed|
|2021-04-06 23:30||Gnomi||Fixed in Version||=> 3.6.4|