Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Segmentation fault (strcat_sse2_unaligned) while calling a function

Reply
Thread Tools

Segmentation fault (strcat_sse2_unaligned) while calling a function

 
 
Rudra Banerjee
Guest
Posts: n/a
 
      06-12-2013
Hello friends,
Please refer to the question http://www.gtkforums.com/viewtopic.p...196942#p196942.

As commented by errol, the seg fault is caused by
"Your error is in the use of strcat() in gs_open() and how you declared buffer.

If you declared buffer as
Code:
char *buffer = "";
Your use of strcat() would case a buffer overflow. The initial buffer is only 1 byte in size and that contains the '\0' terminator. Also if buffer has been used before the contents or even the pointer could also be mangled giving you more problems."

can I get some insight?

 
Reply With Quote
 
 
 
 
Noob
Guest
Posts: n/a
 
      06-12-2013
Rudra Banerjee wrote:

> can I get some insight? [using strcat]


http://man7.org/linux/man-pages/man3/strcat.3.html

Here's a small example.

#include <string.h>
#include <stdio.h>

int main(void)
{
const char s1[] = "hello";
const char s2[] = "world";

char s3[80];
sprintf(s3, "%s, %s!", s1, s2);
printf("%s\n", s3);

memset(s3, 0, sizeof s3);
strcpy(s3, s1);
strcat(s3, s2);
printf("%s\n", s3);

return 0;
}

 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      06-12-2013
On 06/12/2013 03:58 AM, Rudra Banerjee wrote:
> Hello friends,
> Please refer to the question http://www.gtkforums.com/viewtopic.p...196942#p196942.
>
> As commented by errol, the seg fault is caused by
> "Your error is in the use of strcat() in gs_open() and how you declared buffer.
>
> If you declared buffer as
> Code:
> char *buffer = "";
> Your use of strcat() would case a buffer overflow. The initial buffer is only 1 byte in size and that contains the '\0' terminator. Also if buffer has been used before the contents or even the pointer could also be mangled giving you more problems."
>
> can I get some insight?
>


"" is an empty string literal. Since C strings are null terminated, it
implicitly contains one null character. The use of a string literal
causes the creation of an unnamed array long enough to contain the
string. The string literal itself is converted into a pointer to the
first element of the unnamed array, and the value of that pointer is
stored in buffer. In other words, the above code is functionally
equivalent to:

char unnamed[1] = {'\0'};
char *buffer = &unnamed[0];

When you call strcat(buffer, gs_text), it tries to catenate the string
pointed at by gs_text onto the end of the string contained in the array
pointed at by buffer. If gs_text is also an empty string, this is fine;
the catenation of two empty strings is an empty string, which needs only
a terminating null character. However, if gs_text isn't empty, which is
presumably the normal case, then it will contain at least two
characters: the first character of that string and the terminating null
character. The array pointed at by buffer isn't big enough to hold that
many characters, and bad things can happen (and apparently did happen)
when strcat() attempts to put more characters into that array than there
is room for. The behavior is undefined in that case, so in principle
just about anything could happen. In your case, strcat() tried to write
into the locations in memory that come after the unnamed array. At least
part of that memory didn't belong to your program, so your attempt to
write to that location triggered a segment violation which aborted your
program. Your operating system works on a policy that says that a
program which attempts to write to memory that it doesn't have a right
to is too dangerous to be allowed to continue running.
If the memory after the end of the array does belong to your program ,
then other kinds of bad behavior are possible. The write will, in
general, cause whatever variables your program is storing in that
location to change their value, causing unpredictable errors in the way
your program behaves. DONT DO THIS.

Always make sure that the first pointer that you pass to strcat() points
to an array that is long enough to store the entire length of the
catenated strings, including the terminating null character.
--
James Kuyper
 
Reply With Quote
 
Heinrich Wolf
Guest
Posts: n/a
 
      06-12-2013

"Noob" <root@127.0.0.1> schrieb im Newsbeitrag
news:kp9atj$7bq$(E-Mail Removed)...
> Rudra Banerjee wrote:
>
>> can I get some insight? [using strcat]

>
> http://man7.org/linux/man-pages/man3/strcat.3.html
>
> Here's a small example.
>
> #include <string.h>
> #include <stdio.h>
>
> int main(void)
> {
> const char s1[] = "hello";
> const char s2[] = "world";
>
> char s3[80];
> sprintf(s3, "%s, %s!", s1, s2);
> printf("%s\n", s3);


This printf will likely lead to a segmentation fault. s3 is not initialized
and I doubt that one of it's 80 chars is 0. So printf will read beyond the
end of s3.

> memset(s3, 0, sizeof s3);


This memset should have been placed before printf. Here it is completely
useless. The strcpy in the next line of code initializes s3 as well as
memset, even if it does not pad it to the end with 0's.

> strcpy(s3, s1);
> strcat(s3, s2);
> printf("%s\n", s3);
>
> return 0;
> }
>


Heiner

 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      06-12-2013
Heinrich Wolf wrote:

> Noob wrote:
>
>> #include <string.h>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> const char s1[] = "hello";
>> const char s2[] = "world";
>>
>> char s3[80];
>> sprintf(s3, "%s, %s!", s1, s2);
>> printf("%s\n", s3);

>
> This printf will likely lead to a segmentation fault. s3 is not initialized
> and I doubt that one of its 80 chars is 0.


Would you like to bet on it?

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      06-12-2013
On 6/12/2013 4:23 AM, Noob wrote:
> Rudra Banerjee wrote:
>
>> can I get some insight? [using strcat]

>
> http://man7.org/linux/man-pages/man3/strcat.3.html
>
> Here's a small example.
>
> #include <string.h>
> #include <stdio.h>
>
> int main(void)
> {
> const char s1[] = "hello";
> const char s2[] = "world";
>
> char s3[80];
> sprintf(s3, "%s, %s!", s1, s2);
> printf("%s\n", s3);
>
> memset(s3, 0, sizeof s3);


Why?

> strcpy(s3, s1);
> strcat(s3, s2);
> printf("%s\n", s3);
>
> return 0;
> }


--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
Heinrich Wolf
Guest
Posts: n/a
 
      06-12-2013

"Noob" <root@127.0.0.1> schrieb im Newsbeitrag
news:kp9pop$f4k$(E-Mail Removed)...
> Heinrich Wolf wrote:
>
>> Noob wrote:
>>
>>> #include <string.h>
>>> #include <stdio.h>
>>>
>>> int main(void)
>>> {
>>> const char s1[] = "hello";
>>> const char s2[] = "world";
>>>
>>> char s3[80];
>>> sprintf(s3, "%s, %s!", s1, s2);
>>> printf("%s\n", s3);

>>
>> This printf will likely lead to a segmentation fault. s3 is not
>> initialized
>> and I doubt that one of its 80 chars is 0.

>
> Would you like to bet on it?


Statistics tells me a chance of 73% for segmentation fault. But I did not
consider that the memory after s3 might also be readable.

 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      06-12-2013
Eric Sosman wrote:

> Noob wrote:
>
>> #include <string.h>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> const char s1[] = "hello";
>> const char s2[] = "world";
>>
>> char s3[80];
>> sprintf(s3, "%s, %s!", s1, s2);
>> printf("%s\n", s3);
>>
>> memset(s3, 0, sizeof s3);

>
> Why?


[What's up with the bike sheds?!]

I thought the OP might get confused by the remnants
of the previous operation if they examined s3 in a
step-by-step debugger.

Regards.

 
Reply With Quote
 
Heinrich Wolf
Guest
Posts: n/a
 
      06-12-2013

"Heinrich Wolf" <(E-Mail Removed)> schrieb im Newsbeitrag
news:kp9oqh$tjr$(E-Mail Removed)-online.net...
>
> "Noob" <root@127.0.0.1> schrieb im Newsbeitrag
> news:kp9atj$7bq$(E-Mail Removed)...
>> Rudra Banerjee wrote:
>>
>>> can I get some insight? [using strcat]

>>
>> http://man7.org/linux/man-pages/man3/strcat.3.html
>>
>> Here's a small example.
>>
>> #include <string.h>
>> #include <stdio.h>
>>
>> int main(void)
>> {
>> const char s1[] = "hello";
>> const char s2[] = "world";
>>
>> char s3[80];
>> sprintf(s3, "%s, %s!", s1, s2);


I'm sorry!
I did not read carefully enough.
I thought of printf("%s, %s!", in place of sprintf(s3, "%s, %s!",

>> printf("%s\n", s3);

>
> This printf will likely lead to a segmentation fault. s3 is not
> initialized and I doubt that one of it's 80 chars is 0. So printf will
> read beyond the end of s3.
>
>> memset(s3, 0, sizeof s3);

>
> This memset should have been placed before printf. Here it is completely
> useless. The strcpy in the next line of code initializes s3 as well as
> memset, even if it does not pad it to the end with 0's.
>
>> strcpy(s3, s1);
>> strcat(s3, s2);
>> printf("%s\n", s3);
>>
>> return 0;
>> }
>>

>
> Heiner


 
Reply With Quote
 
Angel
Guest
Posts: n/a
 
      06-12-2013
On 2013-06-12, Heinrich Wolf <(E-Mail Removed)> wrote:
>
> "Noob" <root@127.0.0.1> schrieb im Newsbeitrag
> news:kp9pop$f4k$(E-Mail Removed)...
>> Heinrich Wolf wrote:
>>
>>> Noob wrote:
>>>
>>>> #include <string.h>
>>>> #include <stdio.h>
>>>>
>>>> int main(void)
>>>> {
>>>> const char s1[] = "hello";
>>>> const char s2[] = "world";
>>>>
>>>> char s3[80];
>>>> sprintf(s3, "%s, %s!", s1, s2);
>>>> printf("%s\n", s3);
>>>
>>> This printf will likely lead to a segmentation fault. s3 is not
>>> initialized
>>> and I doubt that one of its 80 chars is 0.

>>
>> Would you like to bet on it?

>
> Statistics tells me a chance of 73% for segmentation fault. But I did not
> consider that the memory after s3 might also be readable.


I can't find offhand if it's standard or not, but the glibc implementation
of sprintf() writes a terminating null to the output buffer, so if it is
compiled against glibc this program will not segfault.

http://www.gnu.org/software/libc/man...Functions.html

Function: int sprintf (char *s, const char *template, ...)

This is like printf, except that the output is stored in the
character array s instead of written to a stream. A null character
is written to mark the end of the string. [...]


--
I survived the end of the world and I didn't even get a lousy T-shirt!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
segmentation fault while using ctypes sanket Python 11 04-15-2009 05:53 PM
segmentation fault while deleting a pointer in a destructor H.S. C++ 9 08-13-2008 11:18 AM
calling a function (passed as a pointer) causing segmentation fault sandwich_eater@hotmail.com C++ 1 07-22-2005 07:58 PM
std::basic_string<wchar_t>: segmentation fault while accessing any member functions mufasa C++ 1 07-21-2005 08:50 AM
Segmentation fault with file io while closing main Atulvid C Programming 2 08-11-2003 08:59 PM



Advertisments