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

Members: 0
Guests: 8
Stats
Files
Topics
Posts
Members
Newest Member
481
3,734
19,366
618
Micheal64X
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » General Discussions » CREATE() failed and crashed t...
Forum Rules | Mark all | Recent Posts

CREATE() failed and crashed the mud?
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 May 16, 2006, 4:15 pm   Last edited May 16, 2006, 4:58 pm by Halcyon
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

I was examining a core from a crash we had quite at random, and it returned the oddest thing I'd ever seen... Somehow, the CREATE() macro seems to have led to some kind of data corruption, and I honestly don't know why.

Here's the backtrace, and some information I managed to pull from it:

#0  0x0068618b in malloc_consolidate () from /lib/tls/libc.so.6
(gdb) bt
#0  0x0068618b in malloc_consolidate () from /lib/tls/libc.so.6
#1  0x006871c3 in _int_malloc () from /lib/tls/libc.so.6
#2  0x00688cf6 in calloc () from /lib/tls/libc.so.6
#3  0x080ca364 in create_mobile (pMobIndex=0x929b798) at db.c:2705
#4  0x08134ce6 in do_mpmload (ch=0x9203a48, argument=0xbf8b41d8 "5116 1";) at mud_comm.c:572
#5  0x080fa9b7 in interpret (ch=0x9203a48, argument=0xbf8b41d8 "5116 1";) at interp.c:473
#6  0x0813c3dd in mprog_do_command (cmnd=0xbf8b4e84 "mpmload 5116 1", mob=0x9203a48, actor=0x95f5688, obj=0x0, vo=0x0, rndm=0x95f5688, 
    ignore=0 '\0', ignore_ors=0 '\0') at mud_prog.c:1835
#7  0x0813bd64 in mprog_driver (
    com_list=0x92a97e0 "mpmload 5116 1\n\rmpechoaround $n _red A hologram appears.\n\rmea $n _red A hologram appears.\n\r", mob=0x9203a48, 
    actor=0x95f5688, obj=0x0, vo=0x0, single_step=0 '\0') at mud_prog.c:1533
#8  0x0813eea1 in rprog_wordlist_check (arg=0xbf8b9458 "begin", mob=0x9203a48, actor=0x95f5688, obj=0x0, vo=0x0, type=2, room=0x92a9660)
    at mud_prog.c:3076
#9  0x0813eb1d in rprog_speech_trigger (txt=0xbf8b9458 "begin", ch=0x95f5688) at mud_prog.c:3001
#10 0x0804d94b in do_say (ch=0x95f5688, argument=0xbf8b9458 "begin";) at act_comm.c:1625
#11 0x080fa9b7 in interpret (ch=0x95f5688, argument=0xbf8b9458 "begin";) at interp.c:473
#12 0x080b6bb8 in game_loop () at comm.c:970
#13 0x080b5ead in main (argc=3, argv=0xbf8b9924) at comm.c:528
(gdb) f 3
#3  0x080ca364 in create_mobile (pMobIndex=0x929b798) at db.c:2705
2705        CREATE( mob, CHAR_DATA, 1 );
(gdb) p pMobIndex->name
There is no member named name.
(gdb) p pMobIndex->shortdescr
There is no member named shortdescr.
(gdb) f 10
#10 0x0804d94b in do_say (ch=0x95f5688, argument=0xbf8b9458 "begin";) at act_comm.c:1625
1625        rprog_speech_trigger( argument, ch ); 
(gdb) p ch->name
$1 = 0x95f08c8 "Sarbnitrof"
(gdb) p ch->in_room->vnum
$2 = 5151
(gdb) f 3
#3  0x080ca364 in create_mobile (pMobIndex=0x929b798) at db.c:2705
2705        CREATE( mob, CHAR_DATA, 1 );
(gdb) p mob
$3 = (CHAR_DATA *) 0x0
(gdb) p CHAR_DATA
Attempt to use a type name as an expression
(gdb) f 6
#6  0x0813c3dd in mprog_do_command (cmnd=0xbf8b4e84 "mpmload 5116 1", mob=0x9203a48, actor=0x95f5688, obj=0x0, vo=0x0, rndm=0x95f5688, 
    ignore=0 '\0', ignore_ors=0 '\0') at mud_prog.c:1835
1835      interpret( mob, buf );  
(gdb) p mob
$4 = (CHAR_DATA *) 0x9203a48
(gdb) p mob->name
$5 = 0x92a9700 "&WLevel &YS&Oe&Yv&Oe&Yn&Ot&Ye&Oe&Yn &WTraining Room"
(gdb) f 2
#2  0x00688cf6 in calloc () from /lib/tls/libc.so.6


Nothing super-helpful. =/ Is this something the new CREATE() macros in FUSS would have fixed? I hadn't applied those at the time (have now), so I wonder if those could be it.
       
Post is unread #2 May 16, 2006, 4:24 pm
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

       
Post is unread #3 May 16, 2006, 4:57 pm   Last edited May 16, 2006, 5:13 pm by Halcyon
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

I suppose the most helpful thing about any of that is just to tell me that I'm SOL. =/

In any case, it's obviously got nothing to do with the macros because the only difference between the ones that were there and the ones in FUSS are how error messages are handled when there's something wrong with a pointer.

It does make me think I should consider running it through Valgrind... It's someone's elses codebase, I just do some of the coding for them, and it's a real mess.

Edit: ...The only problem being that I don't have Linux and Valgrind apparently just "doesn't do" Cygwin. XD Might have to consider setting up a seperate Linux environment, it seems.
       
Post is unread #4 May 16, 2006, 7:11 pm
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

Wait, so this is consistent? Does it happen often?

I haven't had any of those malloc/calloc crashes in a while.
       
Post is unread #5 May 16, 2006, 8:34 pm
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

No, no, it's not consistent. At least, I don't believe. I only just recently became a coder there, so I don't have a long history of crashes to look at. I just meant it could probably use a run through Valgrind for its own sake anyway.
       
Post is unread #6 May 17, 2006, 4:59 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

The fact that it shows up on more than one person's codebase means it isn't a random thing, but it could be that there's a very specific set of circumstances that triggers it. I've never had a problem with CREATE() or the underlying calloc() call in the entire time I've been coding. So far only you and Zeno have ever even reported this kind of thing that I can find. But with more than one person documenting the case, maybe we can find some commonalities?

What OS was being uses?
What compiler versions?
Were there any RAM/CPU/disk/etc restrictions in place?
If so, were any of these close to being exceeded when it happened?
Are there any other common functions where it fails? I notice both of you have a report from a failed mpmload() call.
Did this happen with a specific version of Smaug?
Has Valgrind been brought in to diagnose it? Did it have any interesting results?

Edge case bugs like this are such a pain :P
       
Post is unread #7 May 18, 2006, 3:28 pm
Go to the top of the page
Go to the bottom of the page

starlick

GroupMembers
Posts6
JoinedMay 16, 2006

If calloc or malloc are crashing the mud, that means you have some nasty heap corruption. You should go through the code double/triple checking everything.
You can find heap managers out there than help you find parts of programs that are corrupting the heap.
Where is the code in question?
       
Post is unread #8 May 25, 2006, 3:46 pm
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

I had another one of these crashes, and something occurs to me.

We had two crashes today... One was the malloc/calloc crash, and the other was SUPPOSEDLY unrelated. When I was developing a certain feature, I was trying to decide if I wanted to go with hashed/un-hashed macros, and it would seem that I left one of the wrong macros in place. Obviously, this made it have a hissy fit.

I checked some dates... My only recorded instances of these crashes was actually after I threw in the code and the boo-boo therein. So I'm wondering now... Is this malloc/calloc issue possibly just a result of memory corrupted by macro mismatches that rears its ugly head when memory starts getting recycled, perhaps? Both of my crashes end in "malloc consolidate" (And seeing how the strings are SUPPOSED to be hashed, this would make some sense) and I think I noticed that Zeno's don't (Meaning it might be that there's a select few hashed macros where unhashed were intended). It's just a thought, and if this were the case, perhaps it's time we toss one or the other of the methods and just stick with a single macro set? The hash/no-hash issue seems like a real stumbling block for developers. I figure just about everyone's done it once or twice. This could help to alleviate some of that if we could just toss one or the other altogether.
       
Post is unread #9 May 25, 2006, 6:46 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,873
JoinedJul 26, 2005

Personaly on any string i use STRALLOC and STRFREE now days, you cant just toss the str_dup and DISPOSE nor the other way around. Using STRALLOC and STRFREE are great to keep down memory usage. str_dup and DISPOSE are needed though if you are using valgrind and have stuff left over in the hash since it will make valgrind actually pinpoint each part thats left in memory instead of always pointing to other data in the hash. Just my thought on it but personaly I say to switch all strings to STRALLOC and STRFREE, if you are ever running it in valgrind you can turn off the hash so that it uses str_dup and DISPOSE in place of STRALLOC and STRFREE with a simple change to mud.h :) Later.
       
Post is unread #10 May 26, 2006, 2:07 am   Last edited May 26, 2006, 2:09 am by Halcyon
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

Hm. What about void variables? Is it safe to STRFREE or STRALLOC on those? Unsigned chars? I'm really not all that familiar with string hashing or how it works, so I'd like to get that sort of thing cleared up. Are there any places that it's outright *not safe* to be hashing your strings?
       
Post is unread #11 May 26, 2006, 8:37 am
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,873
JoinedJul 26, 2005

Typicaly STRALLOC and STRFREE are only used on 'char *' types I think. While I've never tried it personaly I think that if you tried it on other types it's likly to complain.
       
Post is unread #12 May 26, 2006, 10:53 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

For obvious reasons, you should not be attempting to use string manipulation macros on data which is not a string. Strings in this sense are:
char*
unsigned char*

Anything else and the compiler should pitch a fit. If it doesn't, then you'll get burned by it in the form of crashes soon enough.

Also, as far as I know there's no reason that all strings can't be hashed. Worst case is you only have one copy of a particular string in there, but in the end you save more memory. It's perfectly safe to hash them all.
       
Post is unread #13 May 26, 2006, 11:48 am
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

So, say, in a time command like "bury," where ch->dest_buf is used to store a character's arguments for the command between usage, since dest_buf is void, should that or should that not be dealt with using hashed string macros?

Also, I converted to all hashed for a MUD this morning, and as it happened, the place started crashing off its happy ass before long. I had to disable string hashing to stop it, so that leads me to ask: If a string is hashed, then the structure the string was in tossed without the string being removed from the hash, I'm going to have trouble, aren't I? I'm finding all kinds of such surprises with this code... It's someone else's, and it seems they were less than thorough about some things. >.<
       
Post is unread #14 May 26, 2006, 1:26 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,873
JoinedJul 26, 2005

I have mine use STRALLOC and STRFREE for the ch->alloc_ptr and havent had any problems out of it.
Did get a bug message from do_dig since I have my hash not allocate empty strings it instead sets them to NULL lol so in the case '1' check for do_dig it complained about ch->alloc_ptr being NULL, simple enough to fix though :)

I checked to see if I used STRALLOC and STRFREE for ch->dest_buf and the answer is no. I think I'd done that once before and found it would cause alot of issues, so naturally this time when I was doing the changing I left those alone :).
       
Post is unread #15 May 27, 2006, 9:35 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

It's not a good idea to use STRALLOC/STRFREE on a void* pointer. As I said, you should only use it on known string types. Anything else should be allocated a different way.
       
Post is unread #16 May 27, 2006, 6:50 pm
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

Well, that still leaves me wondering why it started crashing rapidly. So, again, is it because if you toss a pointer that contains hashed strings without first removing all those strings from the hash, is it going to crash itself silly? That's the only thing I can think of that could cause that, because it wasn't tripping on people using timer commands, it was tripping on clean_char and the like.
       
Post is unread #17 May 28, 2006, 1:24 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,873
JoinedJul 26, 2005

Well yes, if you have like 5 of the same thing in the string and the first time its removed its DISPOSED of instead of subtracted from the links to it in the hash it will make other things that used the same string point to invalid data in the memory.
       
Post is unread #18 May 28, 2006, 3:03 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

So, again, is it because if you toss a pointer that contains hashed strings without first removing all those strings from the hash, is it going to crash itself silly?


Yes, you've pretty much got it. DISPOSE a hashed string, you get rid of the memory block pointing to that string, but you haven't adjusted the hash count, so you have other things in the mud that still think the hash data is valid, then it all goes boom when the data is accessed.
       
Pages:<< prev 1 next >>