View Issue Details

IDProjectCategoryView StatusLast Update
0000894LDMud 3.5Efunspublic2021-09-08 21:14
Reporterparadox Assigned ToGnomi  
PrioritynormalSeveritycrashReproducibilityhave not tried
Status resolvedResolutionfixed 
Platformx86_64OSUbuntuOS Version21.04
Product Version3.5.4 
Fixed in Version3.5.5 
Summary0000894: efun::dump_driver_info crash - Illegal type: 0
DescriptionRunning `efun::dump_driver_info(DDI_OBJECTS);` on my production game instance caused a crash.

You can find a password protected zip file with more information here:

Please ask Paradox on the LPC Discord for the password if you don't already have it.

Inside is:

* ldout.crash.snip.txt - standard out log lines.
* lderr.crash.snip.txt - standard err log lines
* 2021.09.01.crash.dump - the core dump
* home/dune/dune/ldbin/ldmud - the LD binary we were running at the time of the core dump

At the time of the crash, on standard out we log:
2021.09.01 01:28:39 Illegal type: 0
2021.09.01 01:28:39 Current object was players/paradox/secure/.lpc/.tmp_code26

On standard err we log a disassembly trace and the line "2021.09.01 01:28:39 LDMud aborting on fatal error.". See `lderr.crash.snip.txt` for the full trace.

We are running LDMud 3.5.4, but with some slight customization.

* For the most part, it's Gnomi's 3.5.4 "35+python" branch from:
* (Shamefully) I also revert the `set_light` deprecation:
* At the time of the crash, we were running this SHA from my Dune LDMud branch:

In the password protected zip you can find the built production binary. Please take some care sharing this as it has a MySQL password "baked in" (on my TODO list to fix...).
Steps To ReproduceSimply run `efun::dump_driver_info(DDI_OBJECTS);`....

However, running `efun::dump_driver_info(DDI_OBJECTS);` on my QA instance, and in my development instance functions correctly and I have no observed a crash. I am hesitant to try to reproduce on production (my playerbase suffers when there are frequent reboots) but could schedule a test in ~20d if we are sufficiently stumped to need more data. Frustrating!
Additional InformationHere is a backtrace from the core dump:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
0000001 0x00007f6bac616859 in __GI_abort () at abort.c:79
0000002 0x00005595e991181c in dump_core () at simulate.c:616
0000003 0x00005595e9911ac8 in fatal (fmt=fmt@entry=0x5595e993837b "Illegal type: %d\n") at simulate.c:677
0000004 0x00005595e986afba in svalue_size (v=v@entry=0x7f6b949aa590, pTotal=pTotal@entry=0x7fffbd657238) at dumpstat.c:426
0000005 0x00005595e986ab75 in svalue_size (v=v@entry=0x7f6ba37e0b60, pTotal=pTotal@entry=0x7fffbd6572a0) at dumpstat.c:287
0000006 0x00005595e986b01f in svalue_size_map_filter (key=<optimized out>, values=0x7f6ba37e0b70, extra=0x7fffbd657350)
    at dumpstat.c:73
0000007 0x00005595e98beeef in walk_mapping (m=0x7f6ba9531888, func=func@entry=0x5595e986afc0 <svalue_size_map_filter>,
    extra=extra@entry=0x7fffbd657350) at mapping.c:2051
0000008 0x00005595e986ae50 in svalue_size (v=v@entry=0x7f6ba95657f0, pTotal=pTotal@entry=0x7fffbd6573c8) at dumpstat.c:136
0000009 0x00005595e986b330 in data_size (pTotal=<synthetic pointer>, ob=0x7f6ba95650d0) at dumpstat.c:460
0000010 dumpstat (fname=0x7f6b8f13c3c8, fname@entry=0x7f6bac03e508) at dumpstat.c:536
0000011 0x00005595e987d9ef in f_dump_driver_info (sp=0x5595e99c5b00 <value_stack_array+800>) at efuns.c:9297
0000012 0x00005595e989ec62 in eval_instruction (
    first_instruction=first_instruction@entry=0x7f6b967fdafa "\017\017\004\v]\031\b@]\251k\177",
    initial_sp=<optimized out>) at interpret.c:7696
0000013 0x00005595e98a6a56 in apply_low (fun=<optimized out>, fun@entry=0x7f6ba95d4008, ob=ob@entry=0x7f6b9bb77b28,
    num_arg=num_arg@entry=0, b_ign_prot=b_ign_prot@entry=false) at interpret.c:15872
#14 0x00005595e98a7a65 in int_apply (fun=0x7f6ba95d4008, ob=0x7f6b9bb77b28, num_arg=num_arg@entry=0,
    b_ign_prot=b_ign_prot@entry=false, b_use_default=b_use_default@entry=true) at interpret.c:16071
#15 0x00005595e989b094 in eval_instruction (
    first_instruction=first_instruction@entry=0x7f6b8f6c6a9d "c\037\006~\v\220~\f\220p\017",
    initial_sp=<optimized out>) at interpret.c:15277
#16 0x00005595e99149e9 in catch_instruction (flags=2, offset=<optimized out>,
    i_sp=i_sp@entry=0x5595e9a78f78 <inter_sp>, i_pc=i_pc@entry=0x7f6b8f6c6a9d "c\037\006~\v\220~\f\220p\017",
    i_fp=i_fp@entry=0x5595e99c5910 <value_stack_array+304>, reserve_cost=8000, i_context=0x0) at simulate.c:461
#17 0x00005595e989e9fc in eval_instruction (
    first_instruction=first_instruction@entry=0x7f6b8f6c5e62 "b\001\005\017\003;(\002\n", initial_sp=<optimized out>)
    at interpret.c:9086
#18 0x00005595e98a6a56 in apply_low (fun=<optimized out>, fun@entry=0x7f6ba9b5b920, ob=ob@entry=0x7f6b99e15d78,
    num_arg=num_arg@entry=1, b_ign_prot=b_ign_prot@entry=false) at interpret.c:15872
#19 0x00005595e98a7a65 in int_apply (fun=0x7f6ba9b5b920, ob=0x7f6b99e15d78, num_arg=num_arg@entry=1,
    b_ign_prot=b_ign_prot@entry=false, b_use_default=b_use_default@entry=true) at interpret.c:16071
#20 0x00005595e989b094 in eval_instruction (
    first_instruction=first_instruction@entry=0x7f6ba972d002 "b\001\001c\b\255\017\003;~\001)\a#d=(\006\b\255\037\001>=l\001\031c\b\255\037\001>\n\332\037", initial_sp=<optimized out>) at interpret.c:15277
#21 0x00005595e98a6a56 in apply_low (fun=<optimized out>, fun@entry=0x7f6ba9719b00, ob=ob@entry=0x7f6ba1330070,
    num_arg=num_arg@entry=1, b_ign_prot=b_ign_prot@entry=false) at interpret.c:15872
#22 0x00005595e98a7a65 in int_apply (fun=fun@entry=0x7f6ba9719b00, ob=ob@entry=0x7f6ba1330070,
    num_arg=num_arg@entry=1, b_ign_prot=b_ign_prot@entry=false, b_use_default=b_use_default@entry=true)
    at interpret.c:16071
#23 0x00005595e98a7f03 in sapply_int (fun=0x7f6ba9719b00, ob=ob@entry=0x7f6ba1330070, num_arg=num_arg@entry=1,
    b_find_static=b_find_static@entry=false, b_use_default=b_use_default@entry=true) at interpret.c:16233
#24 0x00005595e9917e8a in execute_callback (cb=cb@entry=0x7f6b9aad8f70, nargs=nargs@entry=1, keep=keep@entry=true,
    toplevel=toplevel@entry=true) at simulate.c:4088
#25 0x00005595e983f125 in parse_command (buff=buff@entry=0x7fffbd658120 "lpc dump_driver_info(0);",
    from_efun=from_efun@entry=false) at actions.c:1005
#26 0x00005595e9840db2 in execute_command (str=str@entry=0x7fffbd658120 "lpc dump_driver_info(0);", ob=0x7f6ba1330070)
    at actions.c:1161
#27 0x00005595e984c907 in backend () at backend.c:967
#28 0x00005595e983d946 in main (argc=<optimized out>, argv=0x7fffbd65e3d8) at main.c:705

Looking at frame 0000007 I was able to identify the mapping that caused the problem. In frame 0000005 we're calculating the svalue_size for a closure value from the mapping and everything seems OK. In Frame 0000004 we find an lvar with type 0 and abort. All frames above that are related to processing the abort condition.

For what it's worth, the mapping key and value that caused this problem are from some fairly complex code implementing "moustache" templating in LPC. It might be tickling something off the beaten path but I wasn't able to spot the problem with my level of driver-fu.
TagsNo tags attached.



2021-09-08 21:13

manager   ~0002656

This is already fixed in

This commit is marked for the upcoming 3.5.5 and 3.6.5 release. Therefore closing this bug.

As a workaround either don't create lambdas with more than 256 values or refrain from using DDI_OBJECTS or OI_DATA_SIZE.

Issue History

Date Modified Username Field Change
2021-09-08 00:00 paradox New Issue
2021-09-08 00:45 zesstra View Status private => public
2021-09-08 21:13 Gnomi Note Added: 0002656
2021-09-08 21:14 Gnomi Assigned To => Gnomi
2021-09-08 21:14 Gnomi Status new => assigned
2021-09-08 21:14 Gnomi Status assigned => resolved
2021-09-08 21:14 Gnomi Resolution open => fixed
2021-09-08 21:14 Gnomi Fixed in Version => 3.5.5