Sponsored Content
Top Forums Programming memcpy segfaults, but not in windows Post 95625 by cjediknight on Thursday 12th of January 2006 08:16:55 PM
Old 01-12-2006
Yes I think your problem is the buffer variable, where dir you define it and how did you define it,

if you just defined it in a global variable like this,

char * buffer, then definetely you have a problem or they are right the buffer would be too small..

It run in windows because I experience some window based C/C++ compiler allow you to access memory that was not allocated or that is not belongs to you.
 

5 More Discussions You Might Find Interesting

1. Programming

Problem with memcpy

Hi , I am having records in a file like 00412772784705041008FRUITFUL STRWBRRY 00412772784703041008FRUITFUL STRWBERE 00000570632801448078 X i have declared a structure like typedef struct { char Uname; char Pname; ... (4 Replies)
Discussion started by: arunkumar_mca
4 Replies

2. Programming

Segmentation Fault by memcpy

Hello everybody, I'm coding a test program for ARP protocol, and i don't know why i'm getting a SIGSEGV, i traced it with gdb and it says it's due to the memcpy function from /lib/libc.so.6. Program received signal SIGSEGV, Segmentation fault. 0xb7e9e327 in memcpy () from /lib/libc.so.6 This... (5 Replies)
Discussion started by: Zykl0n-B
5 Replies

3. Programming

Segfaults on pointer deletion

Hey Everyone, I have a check similar to this: if (ptr) { delete ptr; ptr = null; }When I'm debugging in AIX (using dbx), if I attempt to print the value of 'ptr' it says "ptr is not defined" - however, it still enters that if block. So, I'm getting segfaults on the delete... (8 Replies)
Discussion started by: ctote
8 Replies

4. Programming

memcpy error

I am getting segmentation fault in memcpy.I have given sufficient memory but i dont know why it is occurring char *finalptr = ( char *)malloc(1048576* sizeof(char)); finaloffset=0;have=685516; memcpy(&(finalptr)+finaloffset,out,have); finaloffset=685516;have=359910;... (23 Replies)
Discussion started by: rajsekhar28
23 Replies

5. Shell Programming and Scripting

Undefined reference to memcpy@GLIBC_2.14

Dear All, I am trying to compile OpenFOAM-1.7.x in RHEL. I could not able to compile some of the applications because of libc version issues. It is saying undefined reference to memcpy@GLIBC_2.14 Can anybody look into it? Thanks & Regards, linuxUser_ (3 Replies)
Discussion started by: linuxUser_
3 Replies
MEMCPY(3)                                                    Linux Programmer's Manual                                                   MEMCPY(3)

NAME
memcpy - copy memory area SYNOPSIS
#include <string.h> void *memcpy(void *dest, const void *src, size_t n); DESCRIPTION
The memcpy() function copies n bytes from memory area src to memory area dest. The memory areas must not overlap. Use memmove(3) if the memory areas do overlap. RETURN VALUE
The memcpy() function returns a pointer to dest. ATTRIBUTES
For an explanation of the terms used in this section, see attributes(7). +----------+---------------+---------+ |Interface | Attribute | Value | +----------+---------------+---------+ |memcpy() | Thread safety | MT-Safe | +----------+---------------+---------+ CONFORMING TO
POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD. NOTES
Failure to observe the requirement that the memory areas do not overlap has been the source of significant bugs. (POSIX and the C stan- dards are explicit that employing memcpy() with overlapping areas produces undefined behavior.) Most notably, in glibc 2.13 a performance optimization of memcpy() on some platforms (including x86-64) included changing the order in which bytes were copied from src to dest. This change revealed breakages in a number of applications that performed copying with overlapping areas. Under the previous implementa- tion, the order in which the bytes were copied had fortuitously hidden the bug, which was revealed when the copying order was reversed. In glibc 2.14, a versioned symbol was added so that old binaries (i.e., those linked against glibc versions earlier than 2.14) employed a mem- cpy() implementation that safely handles the overlapping buffers case (by providing an "older" memcpy() implementation that was aliased to memmove(3)). SEE ALSO
bcopy(3), bstring(3), memccpy(3), memmove(3), mempcpy(3), strcpy(3), strncpy(3), wmemcpy(3) COLOPHON
This page is part of release 4.15 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/. 2017-09-15 MEMCPY(3)
All times are GMT -4. The time now is 08:01 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy