純粋な仮想メソッドと呼ばれる - クロスコンパイル

Question

BeagleBone Blackで使用するためのイベントベースのプログラミングライブラリを書いていて、奇妙なエラーが発生しました。

まったく同じフラグを持つ正確なコードをコンパイルすると、ARMベースのプロセッサで次のエラーが表示されますが、X86コンピュータにコンパイルされたコードを実行したときは。

$ ./missionControl
pure virtual method called
pure virtual method called
pure virtual method called
terminate called recursively
terminate called recursively
Aborted

.

ラップトップをコンパイルして実行すると、プログラムは正しく実行されます。

私がコンパイルを使用しているコマンドです（ish、makefileを使用していますが、両方のコンパイル方法の両方が同じ動作を正確に示しています）：

g++ -std=gnu++11 -pthread -O3 -D_GLIBCXX_USE_NANOSLEEP -o missionControl `find . -name *.cpp`

.

Ubuntuのarm-linux-gnueabi-g++または実際のBeagleBone上のARM対応のg++を使用してコンパイルするかどうかは関係ありません。まだ腕のエラーを獲得します。

私の質問はこれです：このエラーを引き起こす可能性があるもの、そして私はソースを見つけようとするために何ができるのですか？なぜこれが1つのプロセッサアーキテクチャで起こるのでしょうが、同じバージョンのG ++の場合は別のプロセッサアーキテクチャではありませんか？

ありがとう！

ARMプロセッサのGDBからのバックトレース：

#0  0xb6d4adf8 in raise () from /lib/libc.so.6
#1  0xb6d4e870 in abort () from /lib/libc.so.6
#2  0xb6f50ab4 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#3  0xb6f4ea4c in ?? () from /usr/lib/libstdc++.so.6
#4  0xb6f4ea4c in ?? () from /usr/lib/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

.

Answer 1

BeagleBone上で実行されるLibstDC ++のARM版のバグが原因であることが判明しました。仮想関数を持たない小さな玩具プログラムは、std :: threadが作成されたときに同じエラー（ "純粋仮想関数という）を引き起こします。

BeagleBone自体のGCC / libstdc ++ 4.8のカスタムバージョンをコンパイルしようとします - 長い時間がかかる場合でも。

Answer 2

The pure virtual method called error occurs when you attempt to use dynamic dispatch to call a function that is pure virtual in a base before the derived type that implements it has been constructed or after it has already destructed.

The most common cause for this is if the base class attempts to call a virtual function that is pure at this level through the constructor or destructor. Other than that, as it has been pointed out in some comments, if you attempt to access a dead object, you might also run into this same issue.

Just attach a debugger to the program and see what virtual function is called and from where.

Answer 3

See: https://groups.google.com/forum/#!topic/automatak-dnp3/Jisp_zGhd5I

And: Why does this simple c++11 threading-example fail, when compiled with clang 3.2?

Now, I have no idea why this works, but it does for me at least. Add the following four preprocessor definitions to the compiler command line:

__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8

I haven't experimented to see if they are all required, or whether or not you can get away with only some. But this solved the problem for me. Thanks to those who wrote the above answers, and thanks to my colleague for out-googling me :)