0000443: Inherited lfun closures are wrongly looked up - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0000443	LDMud 3.3	Runtime	public	2006-02-04 14:52	2018-01-29 21:57

Reporter	Gnomi	Assigned To	~~lars~~
Priority	normal	Severity	crash	Reproducibility	always
Status	closed	Resolution	fixed
Platform	i686	OS	Debian GNU/Linux	OS Version	3.1
Product Version	3.3.712
Fixed in Version	3.3.714

Summary	0000443: Inherited lfun closures are wrongly looked up
Description	Calling d->fun() crashes (also in 3.2.12-dev.724 and 3.4.0): --- a.c: --- string fun() { return "fun"; } --- b.c: --- string dummy() {return "dummy"; } --- c.c: --- inherit "a"; string fun() { return apply(#'::fun); } --- d.c: --- inherit "b"; inherit "c"; I think that's because in the closure the inherit index relative to 'c.c' (=lambda->prog_ob) is saved, but the lookup (in setup_inherited_call) is done relative to 'd.c' (=lambda->ob->prog). Greetings, Gnomi.
Tags	No tags attached.

Gnomi 2006-02-04 18:11 manager ~0000474	I have no idea, how this can be fixed easily. Imagine an inherit structure like: A B private C D E private C D If C creates #'D::fun, the closure knows only the blueprint of the program C, the inherit index within C and function index within D. From these infos you can't decide, wether B::C::D::fun or E::C::D::fun is meant. So the variable index has to be saved also. For restore_ and save_object/value the full inherit chain has to be printed and read.

Gnomi 2006-02-05 17:58 manager ~0000475	The driver output from the crash is: 2006.02.06 00:52:31 'illegal' instruction encountered. 2006.02.06 00:52:31 Current object was w/gnomi/inhcl2/i/d ... bfffd6f0: 406 call_resolved (3: 23) line 0 w/gnomi/inhcl2/i/d w/gnomi/inhcl2/i/c.c line 3 905a71e: 97 save_arg_frame (0: 23) line 3 905a71f: 22 65536 closure (1: 24) 905a724: 402 apply (2: 25) 8b07267: 56 8 60 9 113 28 240 170 ' z_call' in 'i/zauberstab/zauberstab.c (/i/zauberstab/zmarker.inc)' (' obj/zauberstab#9') line 354 #'call_resolved for ' obj/zauberstab.c' (' obj/zauberstab#9') ' fun' in 'w/gnomi/inhcl2/i/c.c' (' w/gnomi/inhcl2/i/d') line 3 <lambda 0x8b07264> in 'w/gnomi/inhcl2/i/d.c' (' w/gnomi/inhcl2/i/d') offset 1 2006.02.06 00:52:31 LDMud aborting on fatal error. Program received signal SIGFPE, Arithmetic exception. 0x080fc6cf in dump_core () at simulate.c:586 (tgdb) bt #0 0x080fc6cf in dump_core () at simulate.c:586 0000001 0x080f43ae in fatal (fmt=0x811f520 "'illegal' instruction encountered.\n") at simulate.c:649 0000002 0x0808ed60 in eval_instruction (first_instruction=0x8b07266 "", initial_sp=0x8160f60) at interpret.c:7808 0000003 0x080a40ca in int_call_lambda (lsvp=0x8160bb0, num_arg=0, allowRefs=0) at interpret.c:17693 0000004 0x080a86a6 in v_apply (sp=0x8160bb0, num_arg=1) at interpret.c:20123 0000005 0x08090103 in eval_instruction (first_instruction=0x905a71e "a\026", initial_sp=0x8160ba0) at interpret.c:8124 0000006 0x080a291e in apply_low (fun=0x900c96c, ob=0x926c3fc, num_arg=0, b_ign_prot=0, allowRefs=0) at interpret.c:16732 0000007 0x080a2adc in int_apply (fun=0x924f1c0, ob=0x926c3fc, num_arg=0, b_ign_prot=0, b_use_default=1) at interpret.c:16810 0000008 0x080a898c in int_call_resolved (b_use_default=1, sp=0x8160ba0, num_arg=3) at interpret.c:20263 0000009 0x080a8a9e in v_call_resolved (sp=0x8160ba0, num_arg=3) at interpret.c:20300 0000010 0x08090103 in eval_instruction (first_instruction=0xbfffd6f0 "\a\a\030\b", initial_sp=0x8160ba0) at interpret.c:8124 0000011 0x080a47cf in int_call_lambda (lsvp=0x8160b88, num_arg=3, allowRefs=0) at interpret.c:17957 0000012 0x080a86a6 in v_apply (sp=0x8160ba0, num_arg=4) at interpret.c:20123 0000013 0x08090103 in eval_instruction (first_instruction=0x928b7d6 "`\001\021a\017\003@\036", initial_sp=0x8160b78) at interpret.c:8124 #14 0x080a291e in apply_low (fun=0x9221068, ob=0x9264ca0, num_arg=1, b_ign_prot=0, allowRefs=0) at interpret.c:16732 #15 0x080a2adc in int_apply (fun=0x9221068, ob=0x9264ca0, num_arg=1, b_ign_prot=0, b_use_default=1) at interpret.c:16810 #16 0x080a2f08 in sapply_int (fun=0x9221068, ob=0x9264ca0, num_arg=1, b_find_static=0, b_use_default=1) at interpret.c:16971 #17 0x0804c8b0 in parse_command (buff=0xbfffde60 "zc d->fun()", from_efun=0) at actions.c:1094 #18 0x0804cd54 in execute_command (str=0xbfffde60 "zc d->fun()", ob=0x91bf4d0) at actions.c:1258 #19 0x08054a2c in backend () at backend.c:697 #20 0x080b86e2 in main (argc=16, argv=0xbffff894) at main.c:615 Version is 3.3.712, build 2255 with patches for bug 0000394, 0000422, 0000431 and 0000441.

~~lars~~ 2006-03-14 22:35 reporter ~0000495	lfun closures now track to which program they belong - this also fixes bug 0000444. Provided by Gnomi.

Date Modified	Username	Field	Change
2006-02-04 14:52	Gnomi	New Issue
2006-02-04 18:11	Gnomi	Note Added: 0000474
2006-02-05 17:58	Gnomi	Note Added: 0000475
2006-03-14 22:35	~~lars~~	Status	new => resolved
2006-03-14 22:35	~~lars~~	Fixed in Version	=> 3.3.714
2006-03-14 22:35	~~lars~~	Resolution	open => fixed
2006-03-14 22:35	~~lars~~	Assigned To	=> lars
2006-03-14 22:35	~~lars~~	Note Added: 0000495
2007-10-06 19:55	~~lars~~	Status	resolved => closed
2010-11-16 09:42	~~lars~~	Source_changeset_attached	=> ldmud.git master 790d211f
2018-01-29 18:59	~~lars~~	Source_changeset_attached	=> ldmud.git master 790d211f
2018-01-29 21:57	~~lars~~	Source_changeset_attached	=> ldmud.git master 790d211f