User Name:


Forgot your password?
Vote for Us!
auth_update crash
Dec 23, 2017, 10:15 pm
By Remcon
Dec 18, 2017, 7:21 pm
By Remcon
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex

Members: 0
Guests: 3
Newest Member
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SWFOTE FUSS » Troubles a brewin
Forum Rules | Mark all | Recent Posts

Troubles a brewin
< Newer Topic :: Older Topic > Possible bugs?

Pages:<< prev 1 next >>
Post is unread #1 Apr 29, 2011, 2:42 am
Go to the top of the page
Go to the bottom of the page

JoinedDec 2, 2009

Fri Apr 29 02:23:52 2011 :: Cynthia (TL-118) destroyed by No CH: flew into sun.

Fri Apr 29 02:23:52 2011 :: Ship Deleted: Cynthia (TL-118)

Program received signal SIGSEGV, Segmentation fault.
_int_malloc (av=0xba13a0, bytes=112) at malloc.c:4628
4628		size = chunksize(victim);
(gdb) bt
#0  _int_malloc (av=0xba13a0, bytes=112) at malloc.c:4628
#1  0x00a8d0e9 in __libc_calloc (n=1, elem_size=112) at malloc.c:4065
#2  0x08165633 in mprog_driver (
    com_list=0x8461f08 "laugh\n\rmpsleep 10\n\rchuckle\n\r", mob=0x85f0418, 
    actor=0x0, obj=0x0, vo=0x0, single_step=false) at mud_prog.c:1403
#3  0x08166c7e in mprog_percent_check (mob=0x85f0418, actor=0x0, obj=0x0, 
    vo=0x0, type=4) at mud_prog.c:1998
#4  0x081676b9 in mprog_random_trigger (mob=0x85f0418) at mud_prog.c:2279
#5  0x081fd99c in mobile_update () at update.c:1273
#6  0x0820190c in update_handler () at update.c:2679
#7  0x080df5bd in game_loop () at comm.c:591
#8  0x080de8c5 in main (argc=2, argv=0xbffff464) at comm.c:249

This boggles me, as I'm just a hobbist at the most when it comes to coding.
It seems to happen anytime a ship is destroyed.
Running a copy of swfotefuss1.4, and upon an "accidental" :lol: crash into
a sun the mud crashed. So put it in gdb and tried it again, and again, and again.
No matter the situation this happens. Its not just crashing into the sun either.

I would really like advice on this from peeps that know much more about the built in functionality,
as I have relatively little knowledge about them. Hopefully someone has already fixed this and/or
can get this to reproduce.

mud_prog.c:1398 - 1403
       * mpsleep - Check if we should sleep -rkb 
      if( !str_prefix( "mpsleep", cmnd ) )
         CREATE( mpsleep, MPSLEEP_DATA, 1 );

mud.h:3318 - 3327
#define CREATE(result, type, number)                                    \
do                                                                      \
{                                                                       \
   if (!((result) = (type *) calloc ((number), sizeof(type))))          \
   {                                                                    \
      perror("malloc failure" );                                         \
      fprintf(stderr, "Malloc failure @ %s:%d\n", __FILE__, __LINE__ ); \
      abort();                                                          \
   }                                                                    \
} while(0)

  mem = _int_malloc(av, sz);

        size = chunksize(victim);

Also, don't have the gdb info or I would post it as well, it seems that when I run swfotefuss1.4 in gdb
for an extended period of time, there is always a broken pipe. It will usually occur when someone(random)
idles out. Then the seg happens. It doesn't do it if the mud is running normally though.
Just really thought I should bring this up as well, because its a nuisance and I think it should be fixed.
If you would like anymore info on either of these, just let me know. I'll gladly post anything from my own mud
that you ask of, but its a fairly fresh copy...I will say that.
look forward to a reply, eagerly.
Pages:<< prev 1 next >>