View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000908 | LDMud 3.7 | Implementation | public | 2023-10-14 17:27 | 2023-10-15 16:11 |
| Reporter | paradox | Assigned To | Gnomi | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Summary | 0000908: add_action with some efun operator closure args produces segfault | ||||
| Description | I was writing an object that used `add_action` with a closure argument and noticed I could reliably segfault 3.6.7 (also 3.6.6 and 3.6.5) if the initial closure arg to 'efun::add_action' was given a particular efun operator closure as argument, instead of the intended lfun (e.g. because the lfun was accidentally omitted, or had the wrong name). The choice of efun closure appears to matter. Using a normal efun closure like #'write, or #'notify_fail doesn't crash. Using an operator efun closure like #'switch, #',, or #'= does crash reliably. | ||||
| Steps To Reproduce | 1. create an object that uses `add_action(#'switch, "cmd");` but has no 'switch' lfun. 2. invoke 'cmd' as a living 3. observe crash | ||||
| Additional Information | Here's a unit test that can be added to the driver test suite to demonstrate the crash: ``` #include "/inc/base.inc" #include "/inc/client.inc" #include "/sys/configuration.h" #include "/sys/input_to.h" void run_server() { add_action(#'write, "test"); } void run_client() { call_out(#'switch, __ALARM_TIME__ + 0, "test\n"); } void run_test() { msg("\nRunning test for crash when add_action w/ efun closure arg:\n" "-----------------------------------------------\n"); connect_self("run_server", "run_client"); } string *epilog(int eflag) { run_test(); return 0; } ``` Here's the backtrace from an instance of the crash: ``` (gdb) bt #0 0x00000000004168d0 in closure_location (cl=0xffffffffffffffcc) at closure.c:5975 0000001 0x0000000000459336 in get_line_number_if_any (name=name@entry=0x7fffffff3840) at interpret.c:22405 0000002 0x00000000004d2af5 in errorf (fmt=<optimized out>, fmt@entry=0x509804 "Uncallable closure\n") at simulate.c:980 0000003 0x000000000046fc5c in int_call_lambda (lsvp=<optimized out>, num_arg=0, external=<optimized out>, bind_ob=<optimized out>) at interpret.c:21783 0000004 0x00000000004d5efe in execute_callback (cb=cb@entry=0x7ffff7711460, nargs=nargs@entry=0, keep=keep@entry=true, toplevel=<optimized out>) at simulate.c:4414 0000005 0x0000000000406a78 in parse_command (buff=buff@entry=0x7fffffff4590 "crash", from_efun=from_efun@entry=false) at actions.c:999 0000006 0x00000000004086bf in execute_command (str=str@entry=0x7fffffff4590 "crash", ob=0x7ffff7bbc0b8) at actions.c:1143 0000007 0x0000000000411551 in backend () at backend.c:979 0000008 0x000000000040576b in main (argc=<optimized out>, argv=<optimized out>) at main.c:704 ``` I can provide a core dump/binary if needed but the core is ~10mb and too large for the issue tracker. Since the issue is so easy to reproduce it didn't seem like it would be very helpful anyway. | ||||
| Tags | No tags attached. | ||||
