View Issue Details

IDProjectCategoryView StatusLast Update
0000414LDMud 3.3Compilation, Installationpublic2018-01-29 21:57
ReporterGnomi Assigned Tolars 
PrioritynormalSeveritycrashReproducibilityunable to reproduce
Status closedResolutionfixed 
Platformi686OSDebian GNU/LinuxOS Version3.1
Product Version3.3 
Fixed in Version3.3 
Summary0000414: Null pointer in parse_command while searching for the marker
DescriptionUNItopia got a segfault:

Core was generated by `bin/ldmud-3.3.709.U006 --define UNItopia --define AUTO_CO
UNTOB --mudlib /UNItop'.
Program terminated with signal 11, Segmentation fault.
#0 parse_command (buff=0xbfffddc8 "entzuende bombe", from_efun=0)
    at actions.c:1145
1145 ; (s = *pp) != (sentence_t *)marker_sent;
(gdb) bt
#0 parse_command (buff=0xbfffddc8 "entzuende bombe", from_efun=0)
    at actions.c:1145
0000001 0x0804c28f in execute_command (str=0xbfffddc8 "entzuende bombe",
    ob=0xb084050) at actions.c:1259
0000002 0x08052486 in backend () at backend.c:680
0000003 0x080ade92 in main (argc=58, argv=0xbffff764) at main.c:615
(gdb) print s
$1 = (sentence_t *) 0x0
(gdb) print pp
$2 = (sentence_t **) 0x0
(gdb) print *((word_t*)marker_sent-7)@7
$3 = {1744833032, 839130950, 0, 685, 209059990, 135226784, 1074}
(gdb) print *marker_sent
$4 = {sent = {next = 0x0, type = 227575548}, verb = 0xc763f80, ob = 0x6e,
  shadow_ob = 0xd9086fc, function = 0x9, short_verb = 0}

Interesting is, that marker_sent is not allocated (at least the magic word is from the sfmagic list) und was a lambda closure before ((char*)135226784 is "closure.c").

The command_object has destructed itself during the action, the command_giver is sill alive. Beside the bomb there was also a torch, that also had a "entzuende" action, which came before the bomb's action. The 'next' pointer is not NULL and its sentence still exists in the player's list, just the marker is missing (and of course the actions of the destructed object).

I haven't got any idea yet, how this could happen...
Greetings,
Gnomi.
TagsNo tags attached.

Activities

Gnomi

2005-11-17 08:41

manager   ~0000406

I deleted my previous comment, this example wasn't the cause the crash, but a 'test' action in my workroom (leftover from experiments weeks ago). It just does
return efun::notify_fail(unbound_lambda(0,"Yes\n")); and results in a fatal "Popped out of the control stack". But this hasn't to do anything with this bug.

Gnomi

2005-11-17 08:57

manager   ~0000407

Okay, now I can reproduce exactly this crash. You need two objects with the following shadow:

void init_shadow(object ob)
{
    shadow(ob, 1);
}

void init()
{
    add_action("test","test");
}

int test(string str)
{
    if(!query_notify_fail())
    return notify_fail("Nothing.\n");
    // The second action get's through.

    object owner = query_shadowing(this_object());
    unshadow();
    efun::move_object(owner, environment(owner));
    destruct(this_object());

    return 1;
}

Both objects should be the last objects in the room. Then executing 'test' will lead to the crash in parse_command while searching for the marker_sent.

Gnomi

2005-11-17 09:23

manager   ~0000408

And the reason for the crash is very simple: When exchanging marker_sent with the next sentence, the shadow_ob entry isn't cleared. And so this marker is removed by a following remove_shadow_action_sent. The following patch fixes this:

Index: trunk/src/actions.c
===================================================================
--- trunk/src/actions.c (Revision 1907)
+++ trunk/src/actions.c (Arbeitskopie)
@@ -1045,6 +1045,7 @@
         marker_sent->sent.type = SENT_MARKER;
         marker_sent->verb = NULL;
         marker_sent->function = NULL;
+ marker_sent->shadow_ob = NULL;
 
         /* Push the argument and call the command function.
          */
@@ -1170,6 +1171,7 @@
     marker_sent->sent.type = SENT_MARKER;
     marker_sent->verb = NULL;
     marker_sent->function = NULL;
+ marker_sent->shadow_ob = NULL;
     command_marker = marker_sent;
 
     /* If the command was not found, notify the failure */

lars

2005-11-24 11:21

reporter   ~0000410

Thanks for the patch - it's in r2221.

Issue History

Date Modified Username Field Change
2005-11-12 21:09 Gnomi New Issue
2005-11-17 08:41 Gnomi Note Added: 0000406
2005-11-17 08:57 Gnomi Note Added: 0000407
2005-11-17 09:23 Gnomi Note Added: 0000408
2005-11-24 11:21 lars Status new => resolved
2005-11-24 11:21 lars Fixed in Version => 3.3
2005-11-24 11:21 lars Resolution open => fixed
2005-11-24 11:21 lars Assigned To => lars
2005-11-24 11:21 lars Note Added: 0000410
2006-02-28 20:05 lars Status resolved => closed
2010-11-16 09:42 lars Source_changeset_attached => ldmud.git master cd9b8d22
2018-01-29 18:59 lars Source_changeset_attached => ldmud.git master cd9b8d22
2018-01-29 21:57 lars Source_changeset_attached => ldmud.git master cd9b8d22