0

ファイルのサイズに合わせてバッファを割り当てる関数があります

char *buffer = new char[size_of_file];

iはバッファーをループし、いくつかのポインターをサブバッファーにコピーして、より小さな単位で処理します。

char *subbuffer = new char[size+1];

for (int i =0; i < size; i++) {
  subbuffer[i] = (buffer + cursor)[i];
}

次に、関数を呼び出して、このサブバッファーと、サブバッファー内の場所の任意のカーソル、および抽象化するテキストのサイズを渡します。

  wchar_t* FileReader::getStringForSizeAndCursor(int32_t size, int cursor, char *buffer) {

  int wlen = size/2;

  #if MARKUP_SIZEOFWCHAR == 4 // sizeof(wchar_t) == 4
  uint32_t *dest = new uint32_t[wlen+1];
  #else
  uint16_t *dest = new uint16_t[wlen+1];
  #endif

  char *bcpy = new char[size];
  memcpy(bcpy, (buffer + cursor), size+2);



  unsigned char *ptr = (unsigned char *)bcpy; //need to be careful not to read outside the buffer


  for(int i=0; i<wlen; i++) {
      dest[i] = (ptr[0] << 8) + ptr[1];
      ptr += 2;
  }
  //cout << "size:: " << size << " wlen:: " << wlen << " c:: " << c << "\n";

  dest[wlen] = ('\0' << 8) + '\0';
  return (wchar_t *)dest;
}

ファイルをループしている間、これを構造体のプロパティとして値に格納します。

私の問題は、サブバッファーを解放し、構造体ポインターの配列、アプリのsegfaultsをループして、構造体のタイトルプロパティの読み取りを開始したときのようです。GDBは正常に終了したと言っていますが、私が数えたレコードがたくさんありません。

これは何かの関数スコープに関係しているのではないかと思います。getStringForSizeAndCursorのmemcpyは、解放する前にサブバッファーの外にバイトをコピーしているため、segfaultを修正すると思いました。今のところ、それらはstruct deconstructorによってクリーンアップされると思いますが、期待する前に分解されているか、一部のメモリが元のサブバッファーをまだ指している場合、サブバッファーをリークさせると、期待したデータが返されますが、これは解決策ではありません。

4

1 に答える 1

0

あなたの質問のコードで私が見ることができる唯一の明確なエラーは、bcpyの割り当てが小さすぎることです。ここでは、サイズのバッファーを割り当て、すぐにバイトをバッファーsizeにコピーします。size+2コードで余分な2バイトを使用していないので、コピーに+2をドロップするだけです。

それに加えて、私はあなたがしている疑わしいことを1つだけ見ることができます。

char *subbuffer = new char[size+1];

sizeバイトをバッファにコピーします。割り当ては、ゼロターミネーションに追加のメモリを割り当てていることを示唆していますが、メモリをまったく存在させない（+1なし）か、2バイトを割り当てる必要があります（関数は2バイト文字セットを示唆しているため）。 、ゼロで終了するのが見えないので、ゼロで終了する文字列として使用すると壊れてしまう可能性があります。

コメントの@Grizzlyにもポイントがあります。文字列とw文字列のメモリの割り当てと処理は、おそらくSTLに「オフロード」して良好な結果を得ることができるものです。

于 2012-10-08T16:32:47.887 に答える