View Issue Details

IDProjectCategoryView StatusLast Update
0000886LDMud 3.6Runtimepublic2021-04-06 23:30
Reportergorgar Assigned ToGnomi  
PrioritynormalSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
Fixed in Version3.6.4 
Summary0000886: crash when mssp enabled
DescriptionGame 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 InformationLDMUD 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
TagsNo tags attached.

Activities

Gnomi

2021-03-30 08:45

manager   ~0002558

I think this crash may have been fixed in LDMud 3.6.2. Could you verify that with an updated version of LDMud?

Gnomi

2021-03-30 12:28

manager   ~0002559

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?

Gnomi

2021-03-30 14:08

manager   ~0002560

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.

gorgar

2021-03-30 14:20

reporter   ~0002561

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.

Gnomi

2021-03-30 17:46

manager   ~0002563

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

Issue History

Date Modified Username Field Change
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