Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
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
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl, Sogou, Yandex, DotBot

Members: 0
Guests: 8
Stats
Files
Topics
Posts
Members
Newest Member
481
3,739
19,386
625
OmarHarrim
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

Xerix
Fledgling
GroupMembers
Posts15
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)


malloc.c:4065
  mem = _int_malloc(av, sz);


malloc.c:4628
        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 >>