Thread: Strangeness

Hello guys,

I have the following buffer:

Code:

char buf[63];

And sometimes the data is perfectly copied into the buffer and others it gets perfectly copied at some point and them it shows up garbage characters (memory?).

Example:

'ThisIsANiceBufferContent'

'ThisIsANiceB^AOq^D^B'

Any ideas on what could be causing this?

Thanks in advance.

Well, who knows what you're doing? (Hint: not us.) Provided what you're doing is null terminated, things should get copied more-or-less properly. However, things won't get copied past the null terminator.

Yes, I'm sorry, my bad.

So, I have a home-made strncpy() and sprintf().

Could these be the source of the problem?

The strange thing about this is that it triggers this behavior randomly and during the operation of the application.

Like, for example:

- Application receives the order to copy the buffer (and does it nicely);
- After awhile when I check up the buffer, it's mangled;

Still, any ideas?

Any other references that you would like me to make, just tell me.

Even if the behavior is random?

Why does it assume that behavior?

The functions aren't mine and can be found here (line 58) and
here (the whole file).

Originally Posted by rags_to_riches

Code:

char* strncpy_irc(char* s1, const char* s2, size_t n)
{
  char* endp = s1 + n;
  char* s = s1;
  while (s < endp && (*s++ = *s2++))
    ;
  return s1;
}

Yeah, unless you're NULL-terminating the return value yourself, that's a problem there.

So, I guess, doing

Code:

char* strncpy_irc(char* s1, const char* s2, size_t n)
{
  char* endp = s1 + n;
  char* s = s1;
  while (s < endp && (*s++ = *s2++))
    ;
  *--s = '\0';
  return s1;
}

would fix the problem.

I was able to track down the nasty bug and do a nice squishing sound.

This problem wasn't related to strncpy_irc() or ircsprintf(), its seems that memory leaks can be pretty much random. I wasn't really expecting this behaviour, but this was a nice lesson and I really loved learning from it.

Thank you very much for all of your input on this. I'm much appreciated to you guys and I'm sorry for the initial lack of information (sudden numbness of some sort).

What I meant was that their behaviour can be random.

I was able to track down the bugger and squished it right.

The code that triggered this behaviour was something like this (example):

Code:

 struct the_whale
 {
    char buf[63];
 };
 (...)
 free(willy);
 free(willy->the_whale);

The strange thing about this is that the process didn't crash. Shouldn't this be reason enough for the process to crash?

Anyways, this problem is solved and gone.

Once again, thanks to all of you who helped me with this.

This is more or less the main reason behind destructors in C++. It will theoretically fix these problems though I should note the use of the word theoretically since the problem is not in the nature of dynamic memory allocation but rather in the carelessness of the person writing the code.

On a side note, and refering back to the initial problem: sometimes it helps to do an fwrite() to a file or pipe stdout to a file or something in order to visually see what is actually going on. Experience will typically help you recognize when a null character is not properly being inserted into a string. But sometimes its not quite that simple. At least if you can view the binary version of whatever was printed you can see that your whole string was probably there and alive and well... But because of other characters such as \b, \a, \r, \n etc. also being present, you got all sorts of other crap that ended up looking like part of the string even though it was in all probability stuff that just got backspaced into the position it printed to. Or carriage returned too... Out of curiosity, did it print a \a? (The one character that you would know if it printed without even looking at the screen).