Безопасная очистка памяти и перераспределение

После обсуждения здесь , если вы хотите иметь безопасный класс для хранения конфиденциальной информации (например, паролей) в памяти, вы должны:

• memset/clear the memory перед ее освобождение
• перераспределение также должно следовать тому же правилу — вместо использования realloc используйте malloc для создания новой области памяти, скопируйте старую в новую, а затем memset/очистите старую память перед ее окончательным освобождением

. это звучит хорошо, и я создал тестовый класс, чтобы проверить, работает ли это.Поэтому я сделал простой тестовый пример, в котором я продолжаю добавлять слова «LOL» и «WUT», за которыми следует число, к этому безопасному буферному классу около тысячи раз, уничтожая этот объект, прежде чем, наконец, сделать что-то, что вызовет дамп ядра.

Так как класс должен безопасно очищать память перед уничтожением, я не должен найти «LOLWUT» в дампе ядра. Тем не менее, мне все же удалось их найти, и я подумал, не глючит ли моя реализация. Тем не менее, я попробовал то же самое, используя SecByteBlock библиотеки CryptoPP:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
using namespace std;

int main(){
   {
      CryptoPP::SecByteBlock moo;

      int i;
      for(i = 0; i < 234; i++){
         moo += (CryptoPP::SecByteBlock((byte*)"LOL", 3));
         moo += (CryptoPP::SecByteBlock((byte*)"WUT", 3));

         char buffer[33];
         sprintf(buffer, "%d", i);
         string thenumber (buffer);

         moo += (CryptoPP::SecByteBlock((byte*)thenumber.c_str(), thenumber.size()));
      }

      moo.CleanNew(0);

   }

   sleep(1);

   *((int*)NULL) = 1;

   return 0;
}

А затем скомпилировал, используя:

g++ clearer.cpp -lcryptopp -O0

И затем включил дамп ядра

ulimit -c 99999999

Но затем включение дампа ядра и его запуск

./a.out ; grep LOLWUT core ; echo hello

дает следующий результат

Segmentation fault (core dumped)
Binary file core matches
hello

Чем это вызвано? Вся область памяти для приложения перераспределилась из-за перераспределения, вызванного добавлением SecByteBlock?

Кроме того, Это документация SecByteBlock

edit: После проверки дампа ядра с помощью vim я получил следующее: http://imgur.com/owkaw

edit2: обновленный код, чтобы его было легче компилировать, и инструкции по компиляции

final edit3: похоже, виноват memcpy. См. реализацию Rasmus mymemcpyв его ответе ниже.