0000894: efun::dump_driver_info crash - Illegal type: 0 - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0000894	LDMud 3.5	Efuns	public	2021-09-07 22:00	2021-09-08 19:14

Reporter	paradox	Assigned To	Gnomi
Priority	normal	Severity	crash	Reproducibility	have not tried
Status	resolved	Resolution	fixed
Platform	x86_64	OS	Ubuntu	OS Version	21.04
Product Version	3.5.4
Fixed in Version	3.5.5

Summary	0000894: efun::dump_driver_info crash - Illegal type: 0
Description	Running `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: https://dunemud.net/lib/exe/fetch.php/dunemud.dump_driver_info.details.zip 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: https://github.com/amotzkau/ldmud/tree/35+python * (Shamefully) I also revert the `set_light` deprecation: https://github.com/dune-mud/ldmud/commit/3b896cacfd2e80169907727bae8d1ab3d3052f8c * At the time of the crash, we were running this SHA from my Dune LDMud branch: https://github.com/dune-mud/ldmud/commit/3f250aa67e9930b03fbb689f19c7065afeb114f5 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 Reproduce	Simply 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 Information	Here 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.
Tags	No tags attached.

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