2014-10-29 2 views
0

Я застрял в странной проблеме. У меня есть exe, который создается с использованием gyp-проекта и common.gypi поддерживается для сборки exe для 32-разрядного и 64-битного Linux. Однако, когда я строю для 64-битного linux и memcpy, вызывается в точке кода, содержимое обнуляется. Создание 32-битной платформы с использованием флага -m32 не вызывает этой проблемы. Я сомневаюсь, что может возникнуть проблема с заголовками, поскольку файлы заголовков для проекта являются общими для 32-битной и 64-битной платформы. Может кто-нибудь, пожалуйста, укажите некоторые рекомендации, как решить эту проблему? Бинарный файл динамически связан и использует GLIBC lgcc, lc и lm. Любые указатели в этой области очень ценятся. Я буду рад предоставить любую дополнительную информацию. Спасибо.с использованием memcpy для 64-битного linux 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. 

Проблема заключается значение флагов, который был первоначально скопирован в целевой_адрес становится равным нулю после тетсру вызывается. Та же логика, когда построена для 32bit, работает просто отлично.

+0

Невозможно ответить на столь неспецифический вопрос. Memcpy копирует память, вот и все, несмотря ни на что. Если окажется, что это не так - в другом месте есть ошибка. Вы можете использовать valgrind для отслеживания ошибок доступа к памяти. – keltar

+0

Я фактически портировал свою 32-битную настройку на 64 бит, и все, что я сделал, это удалить флаг -m32 из проекта для 64-битных сборок, и я надеялся, что это сработает. Я могу, возможно, дать 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).

Для отладки таких вопросов, вы можете установить точку наблюдение с watch команды в gdb отладчике, и с недавним GCC вы могли бы использовать -fsanitize=address как флаг компиляции. или valgrind и т. д.

+0

Все справедливые точки. Кстати, Valgrind сообщает о перекрытии memcpy. – keltar