0

私は小さなプロジェクトに取り組んでいますが、このコードがプログラムのクラッシュを引き起こしている理由を知りたいです。

PLAYER_FILE_PATH-"player.txt"

sprite=yoshi.bmp
width=64
height=64
frames=8
alignment=1
animate=1

プログラム

      FILE *pfile = fopen(PLAYER_FILE_PATH, "r");
if (!pfile)
{
    debug_printf("could not open player file for reading!\n");
    return;
}
fscanf(pfile, "sprite=%s\n\
               width=%d\n\
               height=%d\n\
               frames=%d\n\
               alignment=%d\n\
               animate=%d",
               player_entity.entity_sprite.imgloc,
               &player_entity.entity_sprite.width,
               &player_entity.entity_sprite.height,
               &player_entity.entity_sprite.frames,
               &player_entity.entity_sprite.oscdir,
               &player_entity.entity_sprite.osc);
fclose(pfile);
4

3 に答える 3

4

確実に知るには、player_entity の定義を確認する必要があります。安全に割り当てられたメモリの一部を指す必要がある「imgloc」を適切に定義していない可能性があります。たとえば、次の定義では、imgloc が適切に初期化されていないとコア ダンプが発生します。

struct {
  struct {
    char *imgloc;
    int width;
    int height;
    int frames;
    int oscdir;
    int osc;
  } entity_sprite;
} player_entity;

上記の imgloc 行を次のように置き換えると、このコア ダンプは回避されます。

char imgloc[100];

ただし、文字列が長すぎると、指定されたバッファーがオーバーフローするため、fscanf を使用して文字列を読み取るには十分に注意してください。おそらく、代わりに文字列部分だけに fgets を試し、残りの部分には fscanf を試してみてください。

于 2013-02-14T12:26:01.490 に答える
0

私の推測では、malloc またはスタックを使用して、imgloc の値を保持するためのバッファーを作成していないということです。

于 2013-02-14T12:18:35.173 に答える
0

一般的には、アプリケーションの開発中にメモリ デバッガ (valgrind など) を使用することをお勧めします。

そうすれば、プログラムがメモリをリークしないことを最初から確認でき（後でデバッグするのは悪夢です）、アクセスする必要のないメモリからの読み取りまたはメモリへの書き込みを検出できます（これにより、セグメンテーション違反が発生します。プログラムをクラッシュさせます)。

特定のケースでは、Valgrind は、アクセスできないメモリ アドレス X に書き込みを行っていることを警告し (初期化されていないメモリを使用している可能性があります)、デバッグ情報を使用してコンパイルした場合はファイル名と行番号を提供します。 (-g)。その場合、それは fscanf を指し示しているので、詳しく調べます。行を見て問題が見つからない場合は、(おそらく) 文字列を割り当てる行を示すまで、パラメータを 1 つずつ読み取るように分割します。

char* が (ポインタのサイズを予約する以外に) メモリを割り当てないことを知らなければ問題は解決しませんが、どこから調べればよいかがわかります。もちろん、メモリを予約する必要があることがわかったので、問題が再び発生したときにすぐにその知識を適用します。

于 2013-02-14T13:59:37.760 に答える