0

I am stuck into a strange issue. I have an exe that is created using gyp project and common.gypi is supported to build exe for both 32 and 64 bit linux. However, when i build for 64 bit linux and memcpy is invoked at a point within the code, the content gets zeroed out. Building for 32 bit platform using -m32 flag does not cause this problem. I doubt there might be an issue with the headers since the header files for the project is common for both 32bit and 64bit platform. Can someone please provide some pointers how to tackle this issue? The binary is dynamically linked and uses GLIBC lgcc, lc and lm. Any pointers in this area is greatly appreciated. I will be happy to provide any additional information required. Thanks.

UPDATE : Little bit of code snippet: This is the basic snippet of the code:

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.

The problem is the value of flags that was initially copied to dst becomes zero after memcpy is invoked. Same logic when built for 32bit works just fine.

learn_develop
  • 1,735
  • 4
  • 15
  • 33
  • Impossible to answer so unspecific question. Memcpy copies memory, that's all about it, no matter what. If it appears that it does not - there is a bug somewhere else. You could use valgrind to track down memory access bugs. – keltar Oct 29 '14 at 07:04
  • I actually ported my 32 bit setup to 64 bit and all i did was remove -m32 flag from the project for 64bit builds and i hoped that should work. I can probably give valgrind a shot, but isn't it supposed to determine memory leaks? I tried using memcpy in the function directly too by include string header file but still it didn't fix the issue. The only thing I am suspecting it might be because the size of the src and dest is different and somewhere the defines might be messing up the structures. – learn_develop Oct 29 '14 at 07:16
  • If problem wasn't noticeable before doesn't mean it wasn't there. Or code doesn't fit 64bit scheme, e.g. it implies that sizeof(size_t) == sizeof(int). Valgrind have many tools, one you need here is memcheck. – keltar Oct 29 '14 at 07:23
  • thanks @keltar : let me give it a try – learn_develop Oct 29 '14 at 07:31
  • Not getting anything significant with memcheck tool, except for couple of warnings "Conditional jump or move depends on uninitialised value(s)", that too not in the area I am investigating... – learn_develop Oct 29 '14 at 08:12
  • You do realise that it is almost impossible to reconstruct picture from few fragments you told, right? Are you saying that **right after** memcpy `dst` and `src` contents differs? Or **after** that something else overwrites `dst` once again? If latter, and you don't know what code does it - you could set watchpoint in gdb (https://sourceware.org/gdb/onlinedocs/gdb/Set-Watchpoints.html) – keltar Oct 29 '14 at 09:16
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/63848/discussion-between-user3086861-and-keltar). – learn_develop Oct 29 '14 at 09:38

1 Answers1

2

Read carefully the documentation of memcpy(3). The source and destination areas are not allowed to overlap (otherwise it is undefined behavior). Don't forget to enable all warnings and debug info while compiling (gcc -Wall -Wextra -g)

You might want to use memmove(3) instead.

To debug such issues, you could set a watchpoint with watch command in gdb debugger, and with recent GCC you could use -fsanitize=address as a compilation flag. or valgrind, etc...

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547