4

最近、GCCのコード生成機能（具体的には、-finstrument-functionsコンパイラフラグ）を使用して、プログラムにインストルメンテーションを簡単に追加する方法について読みました。本当にかっこいいと思い、以前のC++プロジェクトで試してみました。パッチを何度か改訂した後、STLコンテナを使用したり、C++ストリームI/ Oを使用してstdoutに出力しようとしたりすると、プログラムがすぐにセグメンテーション違反でクラッシュすることがわかりました。私の最初のアイデアは、構造体を維持することstd::listでしたEvent

typedef struct  
{
    unsigned char event_code;
    intptr_t func_addr;
    intptr_t caller_addr;
    pthread_t thread_id;
    timespec ts;
}Event;

list<Event> events;

これは、プログラムが終了したときにファイルに書き込まれます。EventGDBは、リストにを追加しようとすると、events.push_back(ev)それ自体を呼び出すとインストルメンテーション呼び出しが開始されると教えてくれました。これはそれほど驚くべきことではなく、少し考えてみれば理にかなっています。計画2についても同様です。

私をこのすべての混乱に巻き込んだブログの例は、クレイジーなことは何もしませんでした。それは、を使用してファイルに文字列を書き込んだだけですfprintf()。古いものの代わりにC++のストリームベースのI/Oを使用しても害はないと思いましたが(f)printf()、その仮定は間違っていることがわかりました。今回は、ほぼ無限の死のスパイラルの代わりに、GDBは標準ライブラリへのかなり正常に見える降下を報告しました...その後にセグメンテーション違反が続きます。

簡単な例

#include <list>
#include <iostream>
#include <stdio.h>

using namespace std;

extern "C" __attribute__ ((no_instrument_function)) void __cyg_profile_func_enter(void*, void*);

list<string> text;

extern "C" void __cyg_profile_func_enter(void* /* unused */, void* /* unused */)
{
    // Method 1
    text.push_back("NOPE");

    // Method 2
    cout << "This explodes" << endl;

    // Method 3
    printf("This works!");
}

サンプルGDBバックトレース

方法1

#0  _int_malloc (av=0x7ffff7380720, bytes=29) at malloc.c:3570
#1  0x00007ffff704ca45 in __GI___libc_malloc (bytes=29) at malloc.c:2924
#2  0x00007ffff7652ded in operator new(unsigned long) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff763ba89 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff763d495 in char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff763d5e3 in std::basic_string<char, std::char_traits<char>,  std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from  /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00000000004028c1 in __cyg_profile_func_enter () at src/instrumentation.cpp:82
#7  0x0000000000402c6f in std::move<std::string&> (__t=...) at     /usr/include/c++/4.6/bits/move.h:82
#8  0x0000000000402af5 in std::list<std::string, std::allocator<std::string>   >::push_back(std::string&&) (this=0x6055c0, __x=...) at   /usr/include/c++/4.6/bits/stl_list.h:993
#9  0x00000000004028d2 in __cyg_profile_func_enter () at src/instrumentation.cpp:82
#10 0x0000000000402c6f in std::move<std::string&> (__t=...) at /usr/include/c++/4.6/bits/move.h:82
#11 0x0000000000402af5 in std::list<std::string, std::allocator<std::string> >::push_back(std::string&&) (this=0x6055c0, __x=...) at /usr/include/c++/4.6/bits/stl_list.h:993
#12 0x00000000004028d2 in __cyg_profile_func_enter () at src/instrumentation.cpp:82
#13 0x0000000000402c6f in std::move<std::string&> (__t=...) at /usr/include/c++/4.6/bits/move.h:82
#14 0x0000000000402af5 in std::list<std::string, std::allocator<std::string> >::push_back(std::string&
...

方法2

#0  0x00007ffff76307d1 in std::ostream::sentry::sentry(std::ostream&) ()
    from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007ffff7630ee9 in std::basic_ostream<char, std::char_traits<char> >&  std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x00007ffff76312ef in std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x000000000040251e in __cyg_profile_func_enter () at src/instrumentation.cpp:81
#4  0x000000000040216d in _GLOBAL__sub_I__ZN8GLWindow7attribsE () at src/glwindow.cpp:164
#5  0x0000000000402f2d in __libc_csu_init ()
#6  0x00007ffff6feb700 in __libc_start_main (main=0x402cac <main()>, argc=1, ubp_av=0x7fffffffe268, 
init=0x402ed0 <__libc_csu_init>, fini=<optimized out>, rtld_fini=<optimized out>, 
stack_end=0x7fffffffe258) at libc-start.c:185
#7  0x0000000000401589 in _start ()

環境：

  • Ubuntu Linux 12.04（x64）
  • GCC 4.6.3
  • Intel 3750K CPU
  • 8GBのRAM
4

2 に答える 2

6

インストルメンテーション関数での使用に関する問題は、ランタイムの初期化の非常に初期の部分でcoutあるインストルメンテーション関数が呼び出される__libc_csu_init()ことです-グローバルC ++オブジェクトが構築される機会を得る前に（実際、私__libc_csu_init()はそれらを開始する責任があると思いますコンストラクター-少なくとも間接的に）。

ですからcout、まだ構築する機会がなく、それを使おうとしてもうまくいきません...

std::Listそして、それは、無限再帰を修正した後に使用しようとしたときに遭遇する問題である可能性があります（ Dave Sの回答で言及されています）。

初期化中にインストルメンテーションを失っても構わないと思っている場合は、次のようにすることができます。

#include <iostream>
#include <stdio.h>

int initialization_complete = 0;

using namespace std;

extern "C" __attribute__ ((no_instrument_function)) void __cyg_profile_func_enter(void*, void*);

extern "C" void __cyg_profile_func_enter(void* /* unused */, void* /* unused */)
{
    if (!initialization_complete) return;

    // Method 2
    cout << "This explodes" << endl;

    // Method 3
    printf("This works! ");
}

void foo()
{
    cout << "foo()" << endl;
}

int main()
{
    initialization_complete = 1;
    foo();
}
于 2012-09-02T05:06:38.217 に答える
2

最初のケースは無限ループのようで、スタックオーバーフローが発生します。これはおそらく、std :: listがテンプレートであり、そのコードが、それを使用している翻訳ユニットの一部として生成されているためです。これにより、インストルメントも取得されます。したがって、push_backを呼び出します。これは、push_backを呼び出すハンドラーを呼び出します。

2つ目は、推測する必要がある場合は似ているかもしれませんが、わかりにくいです。

解決策は、-finstrument-functionsを使用せずに、インストルメンテーション関数を個別にコンパイルすることです。サンプルブログは、オプションなしでtrace.cを個別にコンパイルしたことに注意してください。

于 2012-09-02T04:45:36.123 に答える