2012-03-05 13 views
1

**編集:私は解決策を見つけました**無効なメモリアドレスからのFD_SETの読み取り?

が、私は以下の読み取りにあえて人のための奇妙な問題があります。私は宿題に取り組んでいます

をし、送信する必要がありますUNIXパイプを使用するプロセス間のメッセージ

このコードで私の意図は、提供されたファイル記述子でselect()を行うことです。ブロックすることなく何かを読むことができれば、私はそれを返したい。そうでない場合は、NULLを返して、ブロックせずに続行します。

ここでfdがファイルディスクリプタである私「のgetMessage」機能、内部のコードです:

message* getMessage(int fd){ 
    int messageAvailable = 0; 
    struct timeval timeout; 
    fd_set fd2; 

    //If there's a message available, read it; if not, continue on without delay 
    timeout.tv_sec = 0; 
    timeout.tv_usec = 0; 
    FD_ZERO(&fd2); 
    FD_SET(fd,&fd2); 
    messageAvailable = select(FD_SETSIZE,&fd2,NULL,NULL,&timeout); 
    if(messageAvailable){ 
     int bytesRead = 0; 
     message* m; 
     m = malloc(sizeof(message)); 
     //Get the header 
     bytesRead = read(fd,m,sizeof(message)); 
     //If we got the whole message 
     if(bytesRead == sizeof(message)){ 
      return m; 
     }else{ 
      //If a message wasn't generated, free the space we allocated for it 
      free(m); 
      return NULL; 
     } 
    }else{ 
     return NULL; 
    } 
} 

このコードは、プログラムの期間継続ループの内側に、そして正確に同じですポイント(1つのメッセージが正常に転送された後の次のgetMessage()コール)はsegfaultsです。明らかに、FD_SET行は無効なメモリ位置から読み取っています。

私のコードをすべて掲載することなく、この単純なマクロでsegfaultが発生している可能性があります。

私はライン33は、上記FD_SETラインに対応し、以下の情報、デバッグ関連掲載しました:私がやった後

==1330== Invalid read of size 1 
==1330== at 0x804E819: getMessage (messages.c:33) 
==1330== by 0x8049123: main (messageTest.c:110) 
==1330== Address 0xde88d627 is not stack'd, malloc'd or (recently) free'd 
==1330== 
==1330== 
==1330== Process terminating with default action of signal 11 (SIGSEGV) 
==1330== Access not within mapped region at address 0xDE88D627 
==1330== at 0x804E819: getMessage (messages.c:33) 
==1330== by 0x8049123: main (messageTest.c:110) 
==1330== If you believe this happened as a result of a stack 
==1330== overflow in your program's main thread (unlikely but 
==1330== possible), you can try to increase the size of the 
==1330== main thread stack using the --main-stacksize= flag. 
==1330== The main thread stack size used in this run was 8388608. 
==1330== 
==1330== HEAP SUMMARY: 
==1330==  in use at exit: 344 bytes in 10 blocks 
==1330== total heap usage: 25 allocs, 15 frees, 2,492 bytes allocated 
==1330== 
==1330== LEAK SUMMARY: 
==1330== definitely lost: 12 bytes in 1 blocks 
==1330== indirectly lost: 0 bytes in 0 blocks 
==1330==  possibly lost: 0 bytes in 0 blocks 
==1330== still reachable: 332 bytes in 9 blocks 
==1330==   suppressed: 0 bytes in 0 blocks 
==1330== Rerun with --leak-check=full to see details of leaked memory 
==1330== 
==1330== For counts of detected and suppressed errors, rerun with: -v 
==1330== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 11 from 6) 
Segmentation fault 
+1

コードをさらに投稿しても、投稿されているものは明らかに間違っていることはありません。 'select()'が失敗した場合は '-1'を返し、' if(messageAvailable) 'は' true'と評価されます: 'if(messageAvailable> 0)'に変更します。 'select()'の最初の引数として 'fd +' 1を使わないのはなぜですか? – hmjd

+0

ええと...あいまいな質問です。私はそのことについて申し訳ありません。しかし、私は解決策を見つけました。私は無効なファイル記述子をgetMessageに渡していたことがわかります。 私のメッセージについて良い点があります。私はそれを変更します。ありがとう:) – BraedenP

答えて

0

がおっと...私は誤ってFDとして関数に-1を渡していたが何らかの処理(これは、すべての実行で同じポイントで発生した理由を説明しています)。

この質問はおそらく閉じられる可能性があります。私はそれが私の単一の使用事例の外で多目的に役立つとは思わない。

関連する問題