View Issue Details

IDProjectCategoryView StatusLast Update
0000443LDMud 3.3Runtimepublic2018-01-29 21:57
ReporterGnomi Assigned Tolars 
PrioritynormalSeveritycrashReproducibilityalways
Status closedResolutionfixed 
Platformi686OSDebian GNU/LinuxOS Version3.1
Product Version3.3.712 
Fixed in Version3.3.714 
Summary0000443: Inherited lfun closures are wrongly looked up
DescriptionCalling 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.
TagsNo tags attached.

Activities

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.

Issue History

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