View Issue Details

IDProjectCategoryView StatusLast Update
0000741LDMud 3.5Runtimepublic2010-03-27 06:17
Reporterzesstra Assigned Tozesstra  
Status resolvedResolutionfixed 
Platformi686OSGNU/LinuxOS Version4.0
Target Version3.5.0Fixed in Version3.5.0 
Summary0000741: Crash in closure_location()
DescriptionWe had two crash in Morgengrauen in closure_location() during a errorf(), called by check_function_args(). I had no time for a closer look so far, but I have a stacktrace (it is the same for both crashes):

(gdb) bt
#0 0x0805fd7a in closure_location (l=0xffffffef) at closure.c:5652
0000001 0x08088efb in get_line_number_if_any (name=0xffff8d88) at interpret.c:18959
0000002 0x080e6b2f in errorf (fmt=<value optimized out>) at simulate.c:908
0000003 0x08088227 in check_function_args (fx=<value optimized out>,
    progp=<value optimized out>, funstart=0x9654b8a "\002\003a\002\002??l\001\031\b")
    at interpret.c:6536
0000004 0x080a37cb in int_call_lambda (lsvp=0x81541a0, num_arg=1, allowRefs=false,
    external=true) at interpret.c:18160
0000005 0x080a3e2f in v_funcall (sp=0x81541a8, num_arg=2) at interpret.c:20716
0000006 0x080992ef in eval_instruction (first_instruction=0x98bc5a4 "a\003\tb\036",
    initial_sp=0x8154058) at interpret.c:8480
0000007 0x080a3c2c in int_call_lambda (lsvp=0x8153ff8, num_arg=3, allowRefs=false,
    external=true) at interpret.c:18164
0000008 0x080a3e2f in v_funcall (sp=0x8154010, num_arg=4) at interpret.c:20716
0000009 0x080992ef in eval_instruction (
    first_instruction=0x9b2723c "a\004\002?\003<&\b?\017", initial_sp=0x8153f08)
    at interpret.c:8480
0000010 0x080a2e12 in apply_low (fun=0x9502c54, ob=0xe147584, num_arg=4, b_ign_prot=false,
    allowRefs=false) at interpret.c:17188
0000011 0x08091110 in int_apply (fun=0x9502c54, ob=0x11f704a0, num_arg=0, b_ign_prot=false,
    b_use_default=true) at interpret.c:17266
0000012 0x080993d2 in eval_instruction (first_instruction=0xc8eb348 "bp",
    initial_sp=0x8153dc0) at interpret.c:16517
0000013 0x080a323c in call_function (progp=0xc92f1dc, fx=286) at interpret.c:18629
#14 0x080831c4 in call_heart_beat () at heartbeat.c:289
#15 0x08057610 in backend () at backend.c:845
#16 0x080b091f in main (argc=3, argv=0xffffbbc4) at main.c:678
TagsNo tags attached.



2010-03-26 18:17

administrator   ~0001816

The reason for this bug is a peculiar behaviour of int_call_lambda(): when executing closures from another object, an additional dummy frame with funstart==0 is pushed onto the control stack. check_function_args() pops a frame from the stack to attribute the error to the caller. In case of an error upon calling such a closure, this leaves the dummy frame and get_line_if_any() does not cope well with funstart==0. For now, check_function_args() must pop this dummy frame as well.

The long-term solution (also for some other problems) would be to call check_function_args() before pushing a control frame, but we first have to change the way to calculate and set funstart, progp, function_offset, variable_offset (separate the calculation of these from the actual update of the global variables).


2010-03-27 06:17

administrator   ~0001817

This is fixed in r2897 by removing the dummy frame in check_function_args().

The long-term solution is planned (also for improving handling of 'deprecated' and possibly other things), but will take some time.

Issue History

Date Modified Username Field Change
2010-03-26 10:30 zesstra New Issue
2010-03-26 18:17 zesstra Note Added: 0001816
2010-03-26 18:17 zesstra Assigned To => zesstra
2010-03-26 18:17 zesstra Status new => assigned
2010-03-27 06:17 zesstra Note Added: 0001817
2010-03-27 06:17 zesstra Status assigned => resolved
2010-03-27 06:17 zesstra Fixed in Version => 3.5.0
2010-03-27 06:17 zesstra Resolution open => fixed