having a small problem, i am trying to find out how this mumbled garbage is getting printed to my logfiles. what i did was make it so what file and line called the log_string function, and then made it so no line can print to the file stderr without going through the log string function. however i still have junk getting printed to my logfiles.
however i still couldn't figure out how this junk was getting into my logfile, so i commented everything in log_string out, so that none of my code is printing to the stderr file at all. however my logfiles are still getting the same junk printed to them.
so i figured none of my code is to blame for my bloated logfiles full of crap. does anyone have any idea how the smaug code is printing to the logfile or has anyone ran into this?
By garbage, do you mean completely random symbols? That means that somewhere you are not terminating a string correctly with a \0 at the end.
Have you tried grepping for all places that print to stderr? That would at least let you figure out where the culprit might be. You'd have to work backwards from there.
Are the garbage lines completely garbage, or are parts of them correct? That would be an even better hint as to where the problem is.
i already did grep for stderr and changed every single line to go through log_string so that i could see what file and line number the call was coming from in an effort to find out which string was not being done properly. and in some cases its random characters, or its the same thing over and over, like some random ip address, or the word endif over and over and over. and also what is being printed to the logfile does not have the file and line number next to it, so its not coming through the log_string function.
Yes, that definitely sounds like a problem with not terminating the string. Is the first part of these bad lines valid? Again that would give a very good hint as to where you should be looking for the culprit.
ok upon further review it looks like the garbage might be getting sent from the function PERROR. i grepped and found about a hundred matches, so the hunt begins.
Well, like I said, the best thing to do is look at the prefix of the line. Find the part that's not garbage. Search for that, and see where the string is generated. If the point of generation is not broken, simply follow all functions it gets passed through. That will get you the culprit fairly quickly. This assumes that the first part of the line isn't garbage as well; if it is then you have other concerns because you're printing out a purely garbage string somewhere.
i rerouted PERROR to my log_string function and the junk still got printed and no line numbers got printed. so i commented out log_string again with everyhting being rerouted there nothing should be getting printed in theory, but the junk is still being printed. so i am back to square one, and have no clue where it is coming from. and it is nonsensical, nothin leads me to where it might be coming from.
Could you please answer my question: is or is not the first part of the line something you expect to see?
As for the rest, well, all I can say is grep for things like:
printf
fprintf
warn
error
perror
etc.
and make sure that everything looks like it should be there. If you comment out **all** of those lines, and you still are getting stuff, well, you need to look more! :-)
Have you tried using valgrind? It's a very good tool for this kind of problem.
There's a program you can run call strace that traces all system calls a program makes. You'll get a lot of uninteresting information, but you will also get to see which call is being made to print stuff to the screen.
i am not trying to rude but if the stuff being printed was interrupting that was supposed to be being printed to the logfiles, i would have simply gone to that section of the code. unfortunately wolfpaw are morons, i sent them numerous emails about getting valgrind installed and they never responded, so that is a dead alley.
Well, ok, but you should have just said straight off that there was no interruption. :)
Anyhow, you can try using strace as I mentioned which will list the system calls. (ltrace does the same thing but for dynamic links e.g. the C runtime library) This is not ideal as it does not give you the line of code that made the system call, however, it will at least tell you which system calls you should be looking for in the code.
I mean, you claim to have commented out every single line that prints something, and yet stuff is still being printed, so something was missed somewhere. These diagnostic tools can help you pinpoint what was called where.
Here is some sample output running ltrace on my MUD:
i can't tell where the call is coming from though. i turned off the requests pipe and it seemed to remove the problem. but i can't figure out how the requests pipe is writing this crap to the logfiles.
OK. The line write(1, "if\n\rendif\n\rndif\n\rendif\n\rndif\n\ren"..., 4096)
is a problem. The '1' as the first argument means file descriptor #1, which is standard output. The second argument is the string to write. The third argument is how much to write. Somehow, you are printing out that string very shortly after opening the requests pipe. ("that string" being something basically random from memory)
What you need to do is to trace the code starting at that open syscall -- the one that opens the request pipe -- and look for *any* line that could *possibly* issue a call down the line to the write system call. Note that functions like printf are not system calls but library calls; basically you need to look for anything that prints anything anywhere.
If you don't feel like tracing line by line, you can try putting in bogus calls to the "open" system call, and narrow down where that write call is being made. (This is basically printf debugging, but using strace! Whee!)
well i finally found the problem, well at least the function which is the source of the problem. when i turned off the webwho updater, which is located in the requests part, the crap stopped coming into my logs. so its somewhere in my WHO command. now the hard part of tracking it down.