View Issue Details

IDProjectCategoryView StatusLast Update
0000908LDMud 3.7Implementationpublic2023-10-15 18:11
Reporterparadox Assigned ToGnomi  
Status assignedResolutionopen 
Summary0000908: add_action with some efun operator closure args produces segfault
DescriptionI 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 Reproduce1. create an object that uses `add_action(#'switch, "cmd");` but has no 'switch' lfun.
2. invoke 'cmd' as a living
3. observe crash
Additional InformationHere's a unit test that can be added to the driver test suite to demonstrate the crash:

#include "/inc/"
#include "/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"

    connect_self("run_server", "run_client");

string *epilog(int eflag)
    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.
TagsNo tags attached.


There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2023-10-14 19:27 paradox New Issue
2023-10-15 18:11 Gnomi Assigned To => Gnomi
2023-10-15 18:11 Gnomi Status new => confirmed
2023-10-15 18:11 Gnomi Status confirmed => assigned