View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000741 | LDMud 3.5 | Runtime | public | 2010-03-26 09:30 | 2010-03-27 05:17 |
| Reporter | zesstra | Assigned To | zesstra | ||
| Priority | high | Severity | crash | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Platform | i686 | OS | GNU/Linux | OS Version | 4.0 |
| Target Version | 3.5.0 | Fixed in Version | 3.5.0 | ||
| Summary | 0000741: Crash in closure_location() | ||||
| Description | We 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 | ||||
| Tags | No tags attached. | ||||
|
|
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). |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-03-26 09:30 | zesstra | New Issue | |
| 2010-03-26 17:17 | zesstra | Note Added: 0001816 | |
| 2010-03-26 17:17 | zesstra | Assigned To | => zesstra |
| 2010-03-26 17:17 | zesstra | Status | new => assigned |
| 2010-03-27 05:17 | zesstra | Note Added: 0001817 | |
| 2010-03-27 05:17 | zesstra | Status | assigned => resolved |
| 2010-03-27 05:17 | zesstra | Fixed in Version | => 3.5.0 |
| 2010-03-27 05:17 | zesstra | Resolution | open => fixed |
