std :: flushがない場合にセグメンテーションフォルトが発生します

Question

この問題のアプローチはすでにいくつかあります。 ¹² ³

しかし、これは全く異なります。 std::flush行をコメントアウトするとSegfaultが発生しますが、この行を追加するとSegmentationフォルトは発生しません！

int Stm32Serial::writeToSerial() 
{ 
    /// TODO Write handle for writing if necessary 
    /// int serial_write_ret; 
    if (USE_USB) 
    { 
     usb_port.writeBytes (stm_buf_t, stm_buf_t[LENGTH_INDEX]); 
     return SERIAL_RET; 
    } 
    else 
    { 
     std::cout << std::flush; // TODO HACK Remove it! 
     serial_port.sendBuff (stm_buf_t, stm_buf_t[LENGTH_INDEX]); 
     return SERIAL_RET; 
    } 
} 

また、私はgdbを試しました。私はthisデバッグ技術とcompiling with -g optionとROSでこの機能を使用していますが、それはLENGTH_INDEXとstm_buf_t[]探した関数名

Program received signal SIGSEGV, Segmentation fault. 
__mempcpy_sse2() at ../sysdeps/x86_64/memcpy.S:142 
142 ../sysdeps/x86_64/memcpy.S: No such file or directory. 
(gdb) bt 
#0 __mempcpy_sse2() at ../sysdeps/x86_64/memcpy.S:142 
#1 0x6564656563786520 in ??() 
#2 0x20726f7272652064 in ??() 
#3 0x6c6f687365726874 in ??() 
#4 0x2e30203a79622064 in ??() 
#5 0x202c323537373431 in ??() 
#6 0x697420656c637963 in ??() 
#7 0x36312e30203a656d in ??() 
#8 0x2c31343936373632 in ??() 
#9 0x6f68736572687420 in ??() 
#10 0x32302e30203a646c in ??() 
#11 0x742064616572202c in ??() 
#12 0x312e30203a656d69 in ??() 
#13 0x3530333430353233 in ??() 
#14 0x657461647075202c in ??() 
#15 0x30203a656d697420 in ??() 
#16 0x373430353233312e in ??() 
#17 0x74697277202c3234 in ??() 
#18 0x203a656d69742065 in ??() 
#19 0x3637363236312e30 in ??() 
#20 0x006d305b1b333637 in ??() 
#21 0x00007fffffffbbf0 in ??() 
#22 0x00000000ffffbbd8 in ??() 
---Type <return> to continue, or q <return> to quit--- 
#23 0x00007fff00000000 in ??() 
#24 0x0000000000000000 in ??() 
(gdb) 

• を印刷していない、[OK]があります。

また、この関数の呼び出しを持つ別の場所からstd::cout << std::flush;を呼び出すと、Segfaultも処理されます。

... 
genSum (stm_buf_t); 
writeToSerial(); 
std::cout << std::flush; 
... 

私の次のアプローチは何ですか？

Answer 1

経験豊富なネーダーは、スタックがASCIIでいっぱいであることに気づくでしょう。これは、ほとんどの場合、strcpyまたはローカル変数のバッファオーバーフローの兆候です。

スタックアドレスの一部を16進数からASCIIに変換しました。後方に読むように見えます。

rorre dedeecxe rorre dlohserht.0：YBさd、257741it elcyc61.0：全角、1496762ohserht 20.0：DLTのdaer、1.0：emi50340523etadpu、0：最初のビットが 'しきい値エラーがエラーを超えた' と言うように見えます

発します。このテキストのコードや入力ファイルを見て、コード内のどこで使用されているかを確認します。ローカルバッファを上書きしているメモリコピーがあることはほぼ確実です。

コメントに記載されているように、Valgrindはよくこの種の問題を見つけるでしょう。