Under what circumstances will this use of strncpy fail?

R

Ron

#define MAX_SIZE 512

char mybuffer[MAX_SIZE+1];

void myfunction( const char* src )
{
if( src == null ) { return; }

/* A core dump is occuring here */
strncpy( mybuffer, src, MAX_SIZE );
mybuffer[ MAX_SIZE ] = 0;
}


A core dump is occuring on line 10. If src is not null when I call
strncpy, is there anything about its contents that could cause strncpy
to fail? My guess is that there is no way the contents of src could
cause the core, so the pointer itself is bad, even if it is not null.
However, inspecting the calling code, src looks fine. The only thing
I can't inspect (easily) is the contents of src. I can't think of any
way the contents can be the root cause, but maybe someone reading this
knows better.
 
E

Eric Sosman

Ron wrote On 03/09/07 14:44,:
#define MAX_SIZE 512

char mybuffer[MAX_SIZE+1];

void myfunction( const char* src )
{
if( src == null ) { return; }

/* A core dump is occuring here */
strncpy( mybuffer, src, MAX_SIZE );
mybuffer[ MAX_SIZE ] = 0;
}


A core dump is occuring on line 10. If src is not null when I call
strncpy, is there anything about its contents that could cause strncpy
to fail? My guess is that there is no way the contents of src could
cause the core, so the pointer itself is bad, even if it is not null.
However, inspecting the calling code, src looks fine. The only thing
I can't inspect (easily) is the contents of src. I can't think of any
way the contents can be the root cause, but maybe someone reading this
knows better.

What is `null' and where is it defined -- or have
you posted a paraphrase instead of the actual code?

If there really is a `null' floating around, maybe
someone has called myfunction(NULL) and the test fails
to detect it.

But if `null' is really `NULL' and <string.h> has
been #included, I can only guess that `src' points to
someplace bogus, to an address that isn't even part of
your program. Or perhaps to an address within MAX_SIZE
bytes of the end of a chunk of your program's memory,
with no '\0' between it and the edge of the world. You
might also get into trouble if `src' points to a location
somewhere inside `mybuffer'.

Just guessing, I'm afraid ...
 
R

Ron

What is `null' and where is it defined -- or have
you posted a paraphrase instead of the actual code?

Sorry, I've been programming in java alot lately. I meant NULL, and
I'm not suspicious of the validation of the src pointer.
But if `null' is really `NULL' and <string.h> has
been #included, I can only guess that `src' points to
someplace bogus ...
Just guessing, I'm afraid ...

Actually, I appreciate your guesses! I draw the same conclusion -
somehow src must be bad.

Unfortunatley I can't see a problem through inspection. The caller
uses new to allocate an array of char for src. The caller then fills
src with data from a stream, and null terminates src. All of these
operations seem to be properly validated and range checked. I cannot
see any way that memory for src was delete'd or that src was
intentionally reassigned before the call to myfunction. So...

If the value of the src pointer does not change between caller's new
operation and my strncpy, is it possible that the caller could have
successfully used src without causing a core dump there?

If the answer to that is 'no' (and I think it is), I think that means
src was good while the caller was using it, but was unintentionally
changed after that, but before the call to strncpy, such as by a
memory trampling bug or some such. This is the only explanation I can
come up with.

Ahem - I forgot to mention that the problem is intermittent. :) To
give more context, the caller is reading records from a stream, and
myfunction needs to copy one of the strings in the record. Many
records will get processed before the core dump. I have no control
over the code that writes or reads these records, or how src is
initialized or used before it gets to myfunction. But strncpy is
where the core dump happens, so I get to debug. :)

I guess my purpose for posting is to confirm that the only thing that
can go wrong here is the caller gives myfunction a bad pointer (i.e.
myfunction is written correctly and the contents of src don't matter).
 
I

Ian Collins

Ron said:
Ahem - I forgot to mention that the problem is intermittent. :) To
give more context, the caller is reading records from a stream, and
myfunction needs to copy one of the strings in the record. Many
records will get processed before the core dump. I have no control
over the code that writes or reads these records, or how src is
initialized or used before it gets to myfunction. But strncpy is
where the core dump happens, so I get to debug. :)
Odds are, something else completely unrelated to your function is doing
something nasty to the head. The problem just happens to reveal its
self in your code.

If your implementation supports it, use a memory bounds checker.
 
R

Richard Tobin

Ron said:
Unfortunatley I can't see a problem through inspection. The caller
uses new to allocate an array of char for src.

There is no such thing as "new" in C. Presumably this is C++.

-- Richard
 
I

Ian Collins

Ian said:
Odds are, something else completely unrelated to your function is doing
something nasty to the head. The problem just happens to reveal its
self in your code.
"something nasty to the heap"
 
E

Eric Sosman

Ron wrote On 03/09/07 16:46,:
What is `null' and where is it defined -- or have
you posted a paraphrase instead of the actual code?


Sorry, I've been programming in java alot lately. I meant NULL, and
I'm not suspicious of the validation of the src pointer.

But if `null' is really `NULL' and <string.h> has
been #included, I can only guess that `src' points to
someplace bogus
...

Just guessing, I'm afraid ...


Actually, I appreciate your guesses! I draw the same conclusion -
somehow src must be bad.

Unfortunatley I can't see a problem through inspection. The caller
uses new to allocate an array of char for src [...]

Aha! You are using That Other Language, the one with
the C-ish-but-not-quite-C rules, the one that puts your
helpless program at the mercy of ravenous "destructors."
You want comp.lang.c++, down the hall to the left.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top