2014-10-29 5 views
0

이상한 문제가 있습니다. 나는 gyp 프로젝트를 사용하여 생성 된 exe 파일을 가지고 있으며 common.gypi는 32 및 64 비트 리눅스 용 exe 파일을 빌드 할 수 있도록 지원됩니다. 그러나, 내가 64 비트 리눅스를 빌드하고 memcpy가 코드 내의 한 지점에서 호출 될 때, 그 내용은 제로가된다. -m32 플래그를 사용하여 32 비트 플랫폼 용으로 빌드하면이 문제가 발생하지 않습니다. 프로젝트의 헤더 파일이 32 비트 및 64 비트 플랫폼 모두에 공통적이므로 헤더에 문제가있을 수 있습니다. 누군가이 문제를 해결할 수있는 방법을 알려줄 수 있습니까? 바이너리는 동적으로 링크되며 GLIBC lgcc, lc 및 lm을 사용합니다. 이 영역의 모든 포인터는 크게 감사하겠습니다. 추가 정보를 제공해 드리겠습니다. 감사합니다. .64 비트 리눅스 용 memcpy를 사용하면 내용이 0으로 바뀝니다.

UPDATE : 코드의 약간은 :

dst->flags   = src->flags; 
src->b = dst->b; 
and few more assignments 
memcpy(dst, src, size here is 152); 
size of dst is 224 and size of src is 496. 

문제는 초기에 방어 적이기를 호출 한 후 제로가 DST에 복사 된 플래그의 값이 : 이 코드의 기본 조각입니다. 32 비트 용으로 빌드 할 때와 동일한 로직이 정상적으로 작동합니다.

+0

불특정 질문에 대답 할 수 없습니다. Memcpy는 메모리를 복사합니다. 그것이 나타나지 않는 경우 - 다른 곳에 버그가 있습니다. valgrind를 사용하여 메모리 액세스 버그를 추적 할 수 있습니다. – keltar

+0

필자는 실제로 32 비트 셋업을 64 비트로 이식했고, 64 비트 빌드 용 프로젝트에서 -m32 플래그를 제거했다. 아마도 valgrind에게 샷을 줄 수는 있지만 메모리 누수를 결정하지 않아도 될까요? memcpy 함수를 직접 사용하여 문자열 헤더 파일을 포함하여 시도했지만 여전히 문제를 해결하지 못했습니다. src와 dest의 크기가 다르고 정의가 어딘가에 구조가 망가져 있기 때문에 내가 의심하는 유일한 것입니다. –

+0

이전에 문제가 눈에 띄지 않았다면 거기에 없었 음을 의미하지는 않습니다. 또는 코드가 64 비트 체계에 맞지 않습니다. 그것은 sizeof (size_t) == sizeof (int)를 의미합니다. Valgrind에는 많은 도구가 있습니다. 여기서 필요한 도구는 memcheck입니다. – keltar

답변

2

memcpy(3)의 설명서를주의 깊게 읽으십시오. 원본 및 대상 영역이 겹칠 수 없습니다 (그렇지 않으면 undefined behavior). 컴파일 중 모든 경고 및 디버그 정보를 사용하는 것을 잊지 마십시오 (gcc -Wall -Wextra -g)

대신 memmove(3)을 사용하는 것이 좋습니다.

gdb 디버거에서 watch 명령으로 감시 점을 설정할 수 있습니다, 이러한 문제를 디버깅하기 위해, 최근 GCC 당신은 컴파일 플래그로 -fsanitize=address를 사용할 수 있습니다. 또는 valgrind 등 ...

+0

모든 공정한 포인트. Valgrind는 그런데 memcpy 중복을보고합니다. – keltar