|
Home > Archive > Unix Programming > May 2005 > strange behaviour?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
strange behaviour?
|
|
| ltllee@gmail.com 2005-05-26, 2:53 am |
| hello,
I am developing C on HP UX 11v2 with native c compiler. I cannot
understand why below program do not produce core dump / segmentation
fault.
void main(void)
{
char buf[10];
strcpy(buf,
" 0123456789012345678901234567890123456789
0123456789012345678901234567890123456789
0123456789012345678901234567890123456789
0123456789012345678901234567890123456789
012345678901234567890123456789");
printf("content of buf: %s\n", buf);
}
It is strange to me that instead of core dump, the program truncate the
string and produce the following output:
$ ./test
content of buf:
0123456789012345678901234567890123456789
012345678901234567890123
any idea about this strange behaviour?
| |
| Pascal Bourguignon 2005-05-26, 2:53 am |
| ltllee@gmail.com writes:
> hello,
>
> I am developing C on HP UX 11v2 with native c compiler. I cannot
> understand why below program do not produce core dump / segmentation
> fault.
>
> void main(void)
> {
> char buf[10];
>
> strcpy(buf,
> " 0123456789012345678901234567890123456789
0123456789012345678901234567890123456789
0123456789012345678901234567890123456789
0123456789012345678901234567890123456789
012345678901234567890123456789");
>
> printf("content of buf: %s\n", buf);
> }
>
>
> It is strange to me that instead of core dump, the program truncate the
> string and produce the following output:
> $ ./test
> content of buf:
> 0123456789012345678901234567890123456789
012345678901234567890123
>
> any idea about this strange behaviour?
Anything may happen, so anything does happen.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
| |
| Kurtis D. Rader 2005-05-26, 2:53 am |
| On Wed, 25 May 2005 20:17:51 -0700, ltllee wrote:
> I am developing C on HP UX 11v2 with native c compiler. I cannot
> understand why below program do not produce core dump / segmentation
> fault.
You are performing what is commonly known as an "undefined operation";
that is, an act whose results are not defined by any standard. So anything
can happen, including the behavior you observed. The string you saw
displayed is 64 bytes --- a 2^n length, and therefore somewhat special.
Since the buffer you are overrunning is on the stack it is likely
there is something special about the placement of the buffer relative to
the page of memory containing that variable and how HP-UX handles stack
overflows.
| |
| ltllee@gmail.com 2005-05-26, 2:53 am |
| thank you so much Kurtis,
I also noticed the 2^n length, so I suspected there is sth. about heap
allocation.
In fact I've tried insert variables of different types and length, and
found it can only over-run neighbouring variables but restricted in the
2^n memory (or page in your term).
| |
| ltllee@gmail.com 2005-05-26, 2:53 am |
| thank you so much Kurtis,
I also noticed the 2^n length, so I suspected there is sth. about heap
allocation.
In fact I've tried insert different variables of type and length, and
found it can only over-run neighbouring variables but restricted in the
2^n memory (or page in your term).
| |
| John Gordon 2005-05-26, 6:00 pm |
| In <1117077471.426608.132560@g43g2000cwa.googlegroups.com> ltllee@gmail.com writes:
> It is strange to me that instead of core dump, the program truncate the
> string and produce the following output:
> $ ./test
> content of buf:
> 0123456789012345678901234567890123456789
012345678901234567890123
> any idea about this strange behaviour?
You got "lucky". The memory that got overwritten was all within the
address space of your program, so there was no segmentation fault.
(I put lucky in quotes because, really, this is UNlucky behavior. If
memory is being overwritten, you *want* to see a core dump, to let you
know that something is obviously amiss.)
--
John Gordon "It's certainly uncontaminated by cheese."
gordon@panix.com
|
|
|
|
|