Member Discussions

I have a problem usually when editing Object's name, short description, and long description. After naming each, exiting the editor, and saving the changes, I will go back and sometimes get scrambled text where the name, short, long desc of the object should be. Sometimes it won't do this..but along the way when the objects are loaded in it crashes. GDB gives me this:

Program received signal SIGSEGV, Segmentation fault.
alloc_mem (sMem=4) at db.c:2230
2230 rgFreeList[iList] = * ((void **) rgFreeList[iList]);
(gdb) bt
#0 alloc_mem (sMem=4) at db.c:2230
#1 0x004027a0 in show_list_to_char (list=0x101280d4, victim=0x0,
ch=0x10127b40, fShort=0 '\0', fShowNothing=0 '\0') at act_info.c:116
#2 0x00403a35 in do_look (ch=0x10127b40, argument=0x10125f0a '')
at act_info.c:591
#3 0x00423c56 in interpret (ch=0x10127b40, argument=0x10125f09 'l')
at interp.c:1506
#4 0x00413c39 in game_loop_unix (control=4) at comm.c:746
#5 0x0041372a in main (argc=1, argv=0x10021950) at comm.c:384

Line 116 in act_info.c:
prgnShow = alloc_mem( count * sizeof(int) );

This is Godwars Deluxe OLC, may have problems that I never was aware of and might have been answered in previous discussions. If so, my apologies.

-Wurmknight

P.S. Reply here or IM me at Wurmknight DFC
My Email is not working at the moment.

>#1 0x004027a0 in show_list_to_char (list=0x101280d4, victim=0x0,

Not sure if the problem is here, but the victim seems to point to uninitialized memory. Check how victim is defined in do_look.

The problem could also be in the alloc_mem function, so you might post some code from it -most likely this would mean that for some reason, whatever internal buffer used would be running out of memory (or just otherwise out of bounds.)

.

Actually, I added the *victim parameter to carry over the victim info for some quick checks. I just removed it and still run into the same problem. Let me just post this next backtrace from GDB and the alloc_mem function:

Program received signal SIGSEGV, Segmentation fault.
alloc_mem (sMem=5) at db.c:2230
2230 rgFreeList[iList] = * ((void **) rgFreeList[iList]);
(gdb) bt
#0 alloc_mem (sMem=5) at db.c:2230
#1 0x00419bda in str_dup (str=0x22ccf0 'door') at db.c:2312
#2 0x00428116 in oedit (ch=0x101260f8, argument=0x10125781 'long door')
at olc.c:1940
#3 0x00413c3e in game_loop_unix (control=4) at comm.c:755
#4 0x004136ea in main (argc=1, argv=0x10021950) at comm.c:384

void *alloc_mem( int sMem )
{
void *pMem;
int iList;

for ( iList = 0; iList < MAX_MEM_LIST; iList++ )
{
if ( sMem <= rgSizeList[iList] )
break;
}

if ( iList == MAX_MEM_LIST )
{
bug( 'Alloc_mem: size %d too large.', sMem );
exit( 1 );
}

if ( rgFreeList[iList] == NULL )
pMem = alloc_perm( rgSizeList[iList] );
else
{
pMem = rgFreeList[iList];
rgFreeList[iList] = * ((void **) rgFreeList[iList]);
}
return pMem;
}

-Wurmknight

Possible caused by a memory corruption somewhere else. Running your mud in valgrind might give you more information, but mostly doesn't offer much help either.

What is the value of rgFreeList[iList] ?

The segfault is happening because it's trying to read data from an invalid or protected memory address. Given the line where it crashes, the only explanation can be that rgFreeList[iList] is some crazy value (it can't be NULL, the code already checks that and copes).

Now, why the freelist is getting corrupted like this is another matter entirely... My best guess would be that one of the strings you tried to write in the OLC is overrunning its bounds and spamming into the memory after it, and the memory after it just happens to belong to the freelist.

G

>Running your mud in valgrind might give you more information, but mostly doesn't offer much help either

You might want to try to set up a watchpoint for that memory array or better yet, if it seems it always happens with the same index (iList) value, create a debug pointer to that alone. This should tell you when and how the values there change.

Another offhand comment, although it may just be the early hour speaking, goes towards the actual assignment.. to me it looks like you're doing this: a[i] = * (void **) a[i], which would mean that value of a[i], x, is a pointer to a pointer y or then a multidimensional array and you're dereferencing that x, yielding y, leaving x = y. I don't understand why?

.

(Comment added by muir on Tue Jan 6 11:20:41 2004)

Err.. what I was trying to say was that rgFreeList seems to be an array of void**'s, and that when you do that assignment, the value at rgFreeList[iList] isn't a void** or indeed a pointer at all (or then it's corrupted.) Find out the type of rgFreeList, and post it here.. then start with the GDB watchpoints and valgrind.

rgFreeList is likely a void* array, the pointer of the previously freed memory block is copied to the to be freed memory block, rgFreeList holding a pointer to the last freed memory block?

From alittle more testing, I've found that everything is fine til I edit the object in OLC then load the object and purge it. Once I purge it I go back into the editor and get strange strings for name, short_descr and long_descr. All I could assume is that extract_char was doing something to it..but i've looked through extract_char, free_string, fix_string functions and haven't found anything that I can notice wrong. The same problems happens with a totally stock Godwars Deluxe code, thus it can't be anything i've added in the past. Surely someone that has used the Godwars Deluxe code has ran into this problem, if not I'll keep trying to find the problem and fix it.

-Wurmknight

What I think that happens is:

You give the obj index a name using str_dup (unique string created), you load the obj (another unique string created), you purge the obj (unique string is being deleted), except that the string deleted is not of the obj, but of the obj index.
You'll have to rewrite your string hash routines to get olc to work if I'm right. Editing all objects, saving the area, and doing a copyover, before loading objects is an option as well ofcourse.

If I'm not mistaken the same problem will occure with mobiles as well.

> If I'm not mistaken the same problem will occure with mobiles as well.

You are right, they do.

I am still confused as why it deletes the string in the obj index, for now I have been doing copyover's if an object needs to be loaded. But whenever the MUD opens this might be a problem. I guess i'll dig deeper and come up with a way to fix it.

-Wurmknight

Basicly str_dup is the problem, instead you need to use
the code found in fread_string in db.c where strings are
hashed with fBootDb being TRUE (assuming the routine
pretty much works like merc 2.1)

If you can figure out how the string hash routine works it
shouldn't be too much trouble, but since this can be sort
of tricky if you're new to coding I guess you could try to
pursuade a godwars coder into spending some time writing a
snippet.

Each free block of memory contains as its first sizeof(void*) bytes, the address of the next free block, thus creating a linked list of free memory blocks. What the code is effectively doing is saying "freelist head = freelist head->next".

It is quite valid, it just looks scary :)

That's what I said =]

I believe this problem was fixed in the later versions of Dystopia by Jobo. You might want to download a copy of it and have a peek in if you get stuck.

Just checked the godwars code, the str_dup implementation
is different then the one I had in mind.

To fix the problem: go to create_mob in db.c and change:

mob->name = pMobIndex->player_name;
mob->short_descr = pMobIndex->short_descr;
mob->long_descr = pMobIndex->long_descr;
mob->description = pMobIndex->description;

to:

mob->name = str_dup(pMobIndex->player_name)
and the same for the others 3.

Same story for create_object.

Hope this helps.

This did help, thanks again for yours and everyone elses help.

-Wurmknight