Почему MIcroQuill Smartheap выдает ошибки mem_bad_pointer после встраивания perl?

Я встраиваю Perl в приложение C++, которое использует Smartheap. Независимо от того, компилирую ли я perl для использования его собственного malloc или системы, я получаю кучу диалогов об ошибках mem___bad_pointer. Кажется, все работает нормально, когда я просто нажимаю «ОК» и игнорирую ошибки, но, очевидно, мне нужно решить проблему.

Возможно, мне нужно скомпилировать SmartHeap в мою сборку Perl? Это вообще осуществимо?

Ниже приведена единственная страница документации о mem__bad_pointer, которую мне удалось найти, но я не ближе к решению проблемы. Я не понимаю, как и где perl и Smartheap конфликтуют друг с другом. Любые указатели приветствуются.

  • Указатель был выделен диспетчером памяти, отличным от SmartHeap, например, из другой библиотеки DLL или EXE или из библиотеки времени выполнения компилятора. Изучите файл карты, чтобы убедиться, что подключается версия malloc, _fmalloc/farmalloc или operator new для SmartHeap.
  • Указатель является «диким» (неинициализированным), размещен в стеке (локальная переменная) или недействителен по иным причинам.
  • Указатель ранее был освобожден. Если SmartHeap освободил страницу, из которой первоначально был выделен указатель, SmartHeap не сможет определить, что это двойное освобождение. Однако SmartHeap сообщит о недопустимом указателе. Используйте dbgMemDeferFreeing, чтобы отловить этот тип ошибки.
  • Указатель был увеличен или уменьшен с момента выделения.
  • Для 16-разрядной архитектуры x86 указатель был приведен к ближайшему указателю после выделения, и в этом случае сегментная часть указателя была потеряна.
  • Пул памяти, из которого был выделен указатель, был освобожден, или SmartHeap был отменен из задачи.
  • Задача, из которой был выделен указатель, завершена (см. раздел B.4).

person kingkongrevenge    schedule 30.01.2009    source источник


Ответы (1)


Не видя кода, трудно отладить проблему. Возможно, вы выделяете память и с помощью smartheap, и с помощью обычного диспетчера памяти. это может быть вызвано выделением памяти в сборке dll без умной кучи.

В зависимости от вашего кода распределение может быть в порядке, и вы можете писать за пределами области памяти с полным покрытием.

person David    schedule 12.02.2009