User Name:


Forgot your password?
Vote for Us!
AFKMud 2.2.2
Mar 3, 2019 5:35 pm
By Samson
Nov 28, 2018 12:10 pm
By Keirath
First Immortal
Oct 12, 2018 2:02 pm
By GatewaySysop
Bug in do_climb( )
Jun 5, 2018 7:31 pm
By joeyfogas
question on overland code
May 31, 2018 12:03 pm
By joeyfogas
SmaugFUSS 1.9.3
Author: Various
Submitted by: Samson
AFKMud 2.2.2
Author: AFKMud Team
Submitted by: Samson
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
Users Online

Members: 0
Guests: 11
Newest Member
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds » 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 4: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 >>