Fluffos Crash bug

[sarak]

In my bid to get intermud3 going on my slowly evolving DGD based library, I've been throwing together some save_variable and restore_variable functions.  To test them, I've been making use of DS 2.8.4 with the bundled fluffos driver to compare the output of the various functions.  Anyway,  the following is enough to crash Fluffos

> eval return restore_variable("\"\\\"123");

The line is meant to cause an error - I wanted to see just what was and wasn't valid.  Apparently this goes beyond being invalid and into the realm of morally offensive to the driver as it promptly responded with this: -

Code:

******** FATAL ERROR: Segmentation fault
FluffOS driver attempting to exit gracefully.
(current object was /secure/daemon/master)
--- trace ---
Object: /secure/save/creators/s/sarak, Program: <driver>
   in <fake>() at
Object: /secure/save/creators/s/sarak, Program: /lib/command.c
   in cmdAll() at /lib/command.c:162
Object: /secure/cmds/creators/eval, Program: /secure/cmds/creators/eval.c
   in cmd() at /secure/cmds/creators/eval.c:61
Object: /secure/tmp/sarak_CMD_EVAL_TMP_FILE, Program: /secure/tmp/sarak_CMD_EVAL_TMP_FILE.c
   in eval() at /secure/tmp/sarak_CMD_EVAL_TMP_FILE.c:21
Object: /secure/daemon/master, Program: /secure/daemon/master.c
   in error_handler() at /secure/daemon/master.c:535
Object: /secure/sefun/sefun, Program: /secure/sefun/sefun.c
   in find_object() at /secure/sefun/sefun.c:271
Object: /secure/daemon/master, Program: /secure/daemon/master.c
   in valid_apply() at /secure/daemon/master.c:238
'   check_access' in '/secure/daemon/master.c' ('/secure/daemon/master') /secure/daemon/master.c:284

The first couple of times the driver gave me some nice GDB style stack traces but then changed to the style above.  No idea why it changed it's output.  Either way, I've upset it tremendously.  I've having trouble replicating this behaviour in DGD 

Cheers,

Sarak.

[cratylus]

I can't get it to happen for me:

Dead Souls Zayin /domains/examples/room >
eval return restore_variable("\"\\\"123")
Result = "\"123"

Dead Souls Zayin /domains/examples/room >

Did you change your local_options? Which are you using?
What OS?

-Crat

[cratylus]

Actually, I tried it with a different char and it did crash.

Interesting.

-Crat

edit:

Program received signal SIGSEGV, Segmentation fault.
0xfed84ba2 in t_splay () from /lib/libc.so.1
(gdb) bt
#0  0xfed84ba2 in t_splay () from /lib/libc.so.1
#1  0xfed84a80 in t_delete () from /lib/libc.so.1
#2  0xfed847ba in realfree () from /lib/libc.so.1
#3  0xfed84dc3 in cleanfree () from /lib/libc.so.1
#4  0xfed842df in _malloc_unlocked () from /lib/libc.so.1
#5  0xfed84208 in malloc () from /lib/libc.so.1
#6  0x0809ff8c in debugmalloc (size=200009, tag=1065,
    desc=0x80f5252 "f_replace_string: 2") at mallocwrapper.c:68
#7  0x080acb8d in int_new_string (size=200000,
    tag=0x80f5252 "f_replace_string: 2") at stralloc.c:341
#8  0x080a5c15 in f_replace_string () at efuns_main.c:2516
#9  0x0807ae42 in eval_instruction (p=0x826beb3 "@") at interpret.c:3740
#10 0x0807c328 in call_direct (ob=0x824d6ac, offset=104, origin=8, num_arg=1)
    at interpret.c:4546
#11 0x080c7fa8 in call_simul_efun (index=102, num_arg=1) at eoperators.c:1158
#12 0x0807a701 in eval_instruction (p=0x83cb220 "\017|\016\rrk")
    at interpret.c:3604
#13 0x0807bae5 in apply_low (fun=0x81d969c "cmd", ob=0x82d1ccc, num_arg=1)
    at interpret.c:4235
#14 0x080a0b79 in f__call_other () at efuns_main.c:239
#15 0x0807ae42 in eval_instruction (p=0x824dbec "D") at interpret.c:3740
#16 0x080cec83 in call_function_pointer (funp=0x8492a7c, num_arg=1)
    at function.c:300
---Type <return> to continue, or q <return> to quit---
#17 0x080d1019 in user_parser (
    buff=0x8149be0 "eval return restore_variable(\"\\\"\\\\\\\"123\")")
    at add_action.c:363
#18 0x080d120c in parse_command (
    str=0x8149be0 "eval return restore_variable(\"\\\"\\\\\\\"123\")",
    ob=0x84bdc6c) at add_action.c:441
#19 0x08096024 in process_input (ip=0x83d91f4,
    user_command=0x83d9228 "eval return restore_variable(\"\\\"\\\\\\\"123\")")
    at comm.c:1831
#20 0x080962cd in process_user_command () at comm.c:1917
#21 0x0808834c in backend () at backend.c:161
#22 0x0806fbb0 in main (argc=2, argv=0x80468ac) at main.c:428
(gdb) cont
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.

[sarak]

Did you change your local_options? Which are you using?
What OS?

It probably doesn't matter now that you can reproduce it but I don't recall changing any options when getting ds2 up and running - just straight out of the box. I'm running Gentoo Linux 2.6.25-r5.

Sarak.

[cratylus]

Confirmed on Solaris with vanilla FluffOS 2.12 (only modified to
be able to run in develop mode)

using config file: mudos.cfg
Initializing internal tables....
----------------------------------------------------------------------------
Dead Souls Zayin (FluffOS v2.12) starting up on Solaris - Tue Aug 12 10:10:31 2008


System Error: init_addr_server: connect:Connection refused

Loading preloaded files ...
]Preloading: /secure/daemon/autoexec...](0.0)
]Preloading: /secure/daemon/resolv...](0.0)
]Preloading: /daemon/intermud...](0.0)
]Preloading: /secure/daemon/update...](0.0)
]Preloading: /domains/default/room/pod...](0.0)
]Preloading: /domains/default/room/furnace...](0.0)
]Preloading: /lib/sentient...](0.0)
]Preloading: /lib/std/table...](0.0)
]Preloading: /daemon/soul...](0.0)
]Preloading: /lib/player...](0.0)
]Preloading: /secure/daemon/players...](0.0)
]Preloading: /secure/daemon/remotepost...](0.0)
]Preloading: /secure/daemon/localpost...](0.0)
]Preloading: /secure/daemon/letters...](0.0)
]Preloading: /secure/daemon/folders...](0.0)
]Preloading: /secure/daemon/events...](0.0)
]Preloading: /daemon/seasons...](0.0)
]Preloading: /secure/daemon/economy...](0.0)
]Preloading: /daemon/verbs...](0.0)
]Preloading: /daemon/command...](0.0)
]Preloading: /secure/daemon/preload_check...](0.0)
]Preloading: /daemon/decay...](0.0)
]Preloading: /daemon/types...](0.0)
]Preloading: /secure/daemon/ping...](0.0)
]Preloading: /secure/room/arch...](0.0)
]Preloading: /secure/daemon/snoop...](0.0)
]Preloading: /secure/daemon/log...](0.0)
]Preloading: /secure/daemon/file...](0.0)
]Preloading: /secure/daemon/reload...](0.0)
]Preloading: /secure/daemon/inet...](0.0)
]Preloading: /secure/daemon/imc2...](0.0)
]Preloading: /secure/daemon/chat...](0.0)
]Preloading: /secure/daemon/i3router/server...](0.0)
Initializations complete.

Accepting connections on port 6666.
Autoexec daemon loaded.

Program received signal SIGSEGV, Segmentation fault.
0xfed84ba2 in t_splay () from /lib/libc.so.1
(gdb) bt
#0  0xfed84ba2 in t_splay () from /lib/libc.so.1
#1  0xfed84a80 in t_delete () from /lib/libc.so.1
#2  0xfed847ba in realfree () from /lib/libc.so.1
#3  0xfed84dc3 in cleanfree () from /lib/libc.so.1
#4  0xfed842df in _malloc_unlocked () from /lib/libc.so.1
#5  0xfed84208 in malloc () from /lib/libc.so.1
#6  0x0809feb8 in debugmalloc (size=112, tag=1067,
    desc=0x80fad50 "make_functional_funp") at mallocwrapper.c:68
#7  0x080ce56b in make_functional_funp (num_arg=1, num_local=0, len=10,
    args=0x813b528, flag=0) at function.c:187
#8  0x080c8120 in f_function_constructor () at eoperators.c:1217
#9  0x08077b32 in eval_instruction (p=0x826a852 "\003\030\017q\005\001\n")
    at interpret.c:2549
#10 0x0807c309 in call_direct (ob=0x8245c0c, offset=273, origin=8, num_arg=0)
    at interpret.c:4545
#11 0x080c7ed4 in call_simul_efun (index=271, num_arg=0) at eoperators.c:1158
#12 0x0807a6e2 in eval_instruction (
    p=0x8391dea "E\0067\023\002\002\206Eh\025\b") at interpret.c:3603
#13 0x0807c309 in call_direct (ob=0x8362464, offset=12, origin=1, num_arg=0)
    at interpret.c:4545
#14 0x08088809 in call_heart_beat () at backend.c:373
#15 0x080aa6db in call_out () at call_out.c:288
#16 0x08088353 in backend () at backend.c:167
---Type <return> to continue, or q <return> to quit---
#17 0x0806fbb0 in main (argc=2, argv=0x80468ac) at main.c:428
(gdb) cont
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)

eval return restore_variable("\"\\\"123")
---
2008.08.12-10.10,44
*restore_object(): Illegal string format.
Object: /secure/tmp/cratylus_CMD_EVAL_TMP_FILE at line 21

'<fake>' at /secure/save/creators/c/cratylus (/<driver>) at line 0
'cmdAll' at /secure/save/creators/c/cratylus (/lib/command.c) at line 162
'cmd' at /secure/cmds/creators/eval at line 61
'eval' at /secure/tmp/cratylus_CMD_EVAL_TMP_FILE at line 21
Trace written to /log/runtime
% Connection lost

Strange that it didn't happen for me the first time I tried it.

-Crat

[cratylus]

Just confirmed it on MudOS 22.2b14

Not strictly a FluffOS bug though that's largely an academic point,
since it affects FluffOS muds.

I think I've isolated the problem to this block of code in
restore_string() in object.c.

Code:

        case '\\':
            {
                char *news = cp - 1;

                if ((*news++ = *cp++)) {
                    while ((c = *cp++) != '"') {
                        if (c == '\\') {
                            if (!(*news++ = *cp++)) return ROB_STRING_ERROR;
                        }
                        else {
                            if (c == '\r')
                                *news++ = '\n';
                            else *news++ = c;
                        }
                    }
                    if ((c == '\0') || (*cp != '\0')) return ROB_STRING_ERROR;
                    *news = '\0';
                    newstr = new_string(news - start,
                                              "restore_string");
                    strcpy(newstr, start);
                    sv->u.string = newstr;
                    sv->type = T_STRING;
                    sv->subtype = STRING_MALLOC;
                    return 0;
                }
                else return ROB_STRING_ERROR;
            }

Bracketing that in #if 0/#endif makes the problem
go away. I used some debugs to figure out what it's
doing, and it appears to be recursing but using
the same variables in the recurse, thereby stepping
on itself.

That's my theory anyway, I'm not a C guy.

Until someone who knows what they're talking about
steps up, this seems like a good enough workaround.

-Crat

[wodan]

fixed in cvs!