24 Nov, 2009, Mudder wrote in the 1st comment:
Votes: 0
I've tried toying around with it a bit but don't know enough about gdb to work it out. However typing ban with any arguments at all will crash the MUD every time.

I also checked the old ban system of Ice and while nothing crashed, when I banned myself and other characters it added to the list, but did not do anything.
24 Nov, 2009, JohnnyStarr wrote in the 2nd comment:
Votes: 0
Here's what I would do:
bash %> gdb (your exe)
gdb %> break do_ban
gdb %> run

If this is the name of the command function, it will place a breakpoint there.
When you hit run, you should see ROMs output saying it's up and running.
Use another terminal to login and type the "ban" command.
The game should stop, then you can go to your other terminal running gdb.
Type either 'step' or 'next' to go down the line of code.

step: will 'step in' to any functions that are in the current block of code
next: will 'step over' any functions that are in the current block of code

You can type p (variable) to 'print' the value of variable. (keep in mind to print the value of a pointer,
you must use the * to print what it points to: p *variable)

Once you've done that, you can either paste it here for us to help you review it, or fix it if it's obvious.
Hope that helps get you started.

BTW, check out "cgdb" it has syntax highlighting, plus a code buffer window so you can see whats going on more clearly.

EDIT: To run gdb with ROM (depending on the distro) you may need to move the executable to the ../area
folder.
25 Nov, 2009, Runter wrote in the 3rd comment:
Votes: 0
Naw, you just use gdb from your area directory.

gdb ../src/exe
25 Nov, 2009, Mudder wrote in the 4th comment:
Votes: 0
Thanks, that was really cool. This is only my second time trying to use gdb. While I read a lot about it, your quick and easy summary was nice.

It seems the problem is with this:

BAN_DATA               *new_ban( void )
{
static BAN_DATA ban_zero;
BAN_DATA *ban = NULL;

if ( ban_free == NULL )
ban = ( BAN_DATA * ) alloc_perm( sizeof( *ban ) );
else
{
ban = ban_free;
ban_free = ban_free->next;
}

*ban = ban_zero;
VALIDATE( ban );
ban->name.erase();
return ban;
}


It was fine right until I hit step after *ban = ban_zero; then I got a segmentation fault.

EDIT: Actually I run my .exe from the area directory.
25 Nov, 2009, JohnnyStarr wrote in the 5th comment:
Votes: 0
Good old recycle.c, I'm not a fan of the whole *_zero idea.
Are you 100% sure that's what crashes it?
Can you post the crash output?
25 Nov, 2009, Mudder wrote in the 6th comment:
Votes: 0
I put a breakpoint in new_ban and ran the program. This is what I saw.

53		static BAN_DATA		ban_zero;

>step <– My one command entered

224 __gnu_cxx::__atomic_add<&this_>_M_refcount, 1);

69 ~new_allocator() throw() ()

198 { return reinterpret_cast<_CharT*>(this +1);

236 : _Alloc(__a), _M_p(__dat) { }

53 static BAN_DATA ban_zero;

56 if ( ban_free == NULL )
57 ban = ( BAN_DATA * ) alloc_perm( sizeof( *ban ) );

Program received signal SIGSEGV, Segmentation fault.
0x004849c9 in __gnu_cxx::__exchange_and_add ()


I typed this out by hand so I added in spaces for readability. Not sure what some of this means :redface: ..It'll be nice when I can gain competence with this debugger though.

EDIT: Weird. I could have sworn the first time I allocated memory, but I've checked it multiple times and it seems allocating memory is where things screw up.
25 Nov, 2009, JohnnyStarr wrote in the 7th comment:
Votes: 0
I'm afraid I'm not well versed in C++ debugging. I wonder why they didn't change "alloc_perm" with "new" in your project?
It's RaM right?
25 Nov, 2009, Mudder wrote in the 8th comment:
Votes: 0
I don't think they got around to it. Not sure really.

RaM fire, yes.
25 Nov, 2009, JohnnyStarr wrote in the 9th comment:
Votes: 0
I would probably have to play with it to get it to work.
That or see more of the system itself. We have some RaM guys here on MB, I'm sure they would know. :biggrin:
25 Nov, 2009, Mudder wrote in the 10th comment:
Votes: 0
Yeah, thanks for helping out. :smile:

On the up side, this part of the forum hasn't seen so many posts in ages!
25 Nov, 2009, JohnnyStarr wrote in the 11th comment:
Votes: 0
lol, that's always a plus.
0.0/11