I have been having a serious glitch for awhile now, basically tons of wierd characters are getting printed into my logs. I have no idea where it is coming from, and when i grepped for the function that prints to the logs, there are over 130 calls to the function, what I want to know is how can I figure out where the function is being called from so I can figure out where the glitch is coming from. I am not sure, but I think if I used that __FILE__ and __LINE__ thing in the actual function, it would merely print the file and line number of the file the function is merely in, and i don't need to know that.
This thing is happening quite often, which is making my logs hit high in the megabytes fairly quickly. i should also note i am not seeing these glitches in the mud anywhere, strictly in the logs.
That's correct, __FILE__ and __LINE__ will show the exact file and line number where they appear, not where the function caller appeared.
What you can do is add additional, optional arguments to your log function that indicate file and line number.
Here's an example, in psuedo-C:
void log_string(const char * str, int lineNumber, const char * file)
{
int len;
char * buf;
len = strlen(str) + strlen(file) + 100; // get a lot of extra room, just in case.
// Should technically only need strlen + strlen + floor(log(lineNumber)) + 1 + 11, but better safe than sorry.
buf = (char*) malloc(len);
sprintf(buf, "%s (%s, line %d)", str, file, lineNumber);
log_string(buf);
free(buf);
}
You would then use this new version of log_string in places where you want to log line numbers as well.
This should work because, IIRC, the macro LINE_LOG_STRING will be expanded, and *then* __LINE__ and __FILE__ are evaluated, which means that they will be evaluated in the file using the macro, not the file defining the macro.
Well besides that crap, I am now noticing a huge trend now that i can see file and line numbers, that is act_wiz.c:4006, when i look into that its the monitor_chan() snippet i inputed a long time ago. here is what that part looks like:
void monitor_chan( const char *message, int channel, sh_int level_mon )
{
char buf[MAX_STRING_LENGTH];
char buf3[MAX_STRING_LENGTH];
DESCRIPTOR_DATA *d;
int a;
int level = MAX_LEVEL;
for ( a = 0; monitor_table[a].min_level != 0; a++ )
if ( monitor_table[a].channel == channel )
{
level = monitor_table[a].min_level;
break;
}
for ( d = first_descriptor; d; d = d->next )
{
if ( d->connected == CON_PLAYING
&& !IS_NPC( d->character )
&& IS_SET( d->character->pcdata->monitor, channel )
&& level_mon <= get_trust( d->character ) )
{
stc( buf, d->character );
}
}
}
However, I see no glitches on the mud. Can anyone see anything wrong with that? While I am at it, just in case its the actual log function itself, here it is:
void log_string_plus2( const char *str, sh_int log_type, sh_int level, int lineNumber, const char *file )
{
char *strtime;
int offset;
yeah i'm lazy and shortened send_to_char to stc, but i don't see how the functions calling that one would do anything, if message was broken, i would see the extra characters in the mud too wouldn't I? Because I don't see ANY extra characters.
Doesn't Smaug strip any of those characters from being viewable on screen? That would be why you aren't seeing them displayed but they show up in the logs.
The only reason I can think of off hand at this hour that would cause a mess like this is an uninitialized value for the "a" variable causing it to grab random memory.
Not necessarily. ctime returns a pointer to its own static buffer, and so this would work. It's completely unsafe for threading, but for single threaded applications it's probably fine.
Gohan, if you could please edit your code post to use the code tag, that would make reading and debugging it much easier.
Hmm. I don't really see anything else it could possibly be though. Gohan, want to try that and see if it fixes it? :P It *should* work as you have it now, but it might be the reason.
It certainly was on a function I had to fix up on my mud the other day. *cough*.
Just kind of want to update on my progress. I don't know if this is stock smaug or if the people that gave me the smaug codebase way back when modified it, but for some reason there was a global char called log_buf, which apparently was being used around 56 times in my codebase in some of the various calls to log_string. I removed that global definition and added the definitions to each of the functions, and that alleviated around 60% of my memory glitches. I do however still have some, so I am going to try out Valgrind and see what it gives me.
Yes. The global definition of the static variable log_buf doesn't really help much. One of the reasons I ended up removing it myself for pretty much the same reasons.