2

現在、Qtプログラムの1つをWindowsからLinuxに移植中です。Qtの便利なマクロを使って作業することで、プログラムをコンパイルできましたが、まだ動作させることができていません。

2つのライブラリとメインアプリケーションから存在するプログラムです。Windowsでは正常に動作し、Windowsのネイティブ呼び出しはありません。しかし、アプリケーションを実行すると、セグメンテーション違反が発生し続けます。

プログラムをデバッグすると、次の結果が得られます。

#0  0x00fb098a in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#1  0x00fc115d in QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) () from /usr/lib/i386-linux-gnu/libQtCore.so.4
#2  0x001355d3 in Communicator::init(int) () from ~/QtWorkspace/App/Communication/libCommunication.so.1
#3  0x0013f7c3 in Updater::Updater(QWidget*) () from ~/QtWorkspace/App/Updater/libUpdater.so.1
#4  0x0806a2f9 in Controller::Controller(QObject*, int, char**) ()
#5  0x08051a26 in main ()

Controllerは、2番目のライブラリ（Communicator）を呼び出す最初のライブラリ（Updater）を呼び出すメインアプリケーションの一部です。Communicatorでは、多くの接続が発生しますが、Windowsアプリケーションと何ら変わりはありません。

LD_LIBRARY_PATHを使用してライブラリの読み込みが正しく行われたことを確認し、QtCreatorを使用してアプリケーションをコンパイルしました。これはすべて、Ubuntu12.04とWindows7オペレーティングシステムで実行されます。

前もって感謝します ！

ジリエル

編集：

迅速な対応のおかげで、デバッグモードでのコンパイルで問題が発生しましたが、修正されました。そこで、QtCreatorのデバッガーを実行して、どこで問題が発生するかを見つけました。問題は、理由がわからないことです。これはそれがうまくいかないコードです：

fSocket = new QUdpSocket(this);
fSocket->bind(QHostAddress::Any, 0, QUdpSocket::DontShareAddress);
connect(fSocket, SIGNAL(readyRead()), this, SLOT(readPendingDatagrams()));

すでに述べたように、セグメンテーション違反は接続で発生しています。

ライブラリの複数のバージョンの問題はもっともらしいものですが、少なくともQtCreatorはそこで安全だと思いました。また、lddで確認しても、問題はありません。

EDIT2：

要求に応じて、Qtソースをgdbに追加した後のデバッグ結果（起動時に.gdbinitが読み取られますが、QtCreatorでは機能しないようです）：

#0  indexOfMethodRelative<8> (normalizeStringData=false, method=0x139efd "readPendingDatagrams()", 
    baseObject=0xbfffeff4) at kernel/qmetaobject.cpp:530
#1  QMetaObjectPrivate::indexOfSlotRelative (m=0xbfffeff4, slot=0x139efd "readPendingDatagrams()", 
    normalizeStringData=false) at kernel/qmetaobject.cpp:665
#2  0x00fc915d in QObject::connect (sender=0x825b2d0, signal=0x139f44 "2readyRead()", receiver=0xbffff160, 
    method=0x139efc "1readPendingDatagrams()", type=Qt::AutoConnection) at kernel/qobject.cpp:2592
#3  0x00137622 in Communicator::init (this=0xbffff160, timeOut=5000)
    at ../../App/Communication/communicator.cpp:25
#4  0x00143dcc in Updater::Updater (this=0xbffff148, parent=0x0) at ../../App/Updater/updater.cpp:10
#5  0x0806b2ae in Controller::Controller (this=0xbffff120, parent=0x0, argc=1, argv=0xbffff2b4)
    at ../../App/App/controller.cpp:4
#6  0x08054bbe in main (argc=1, argv=0xbffff2b4) at ../../App/App/main.cpp:18

おそらくこれは役立つでしょうか？readPendingDatagrams（）はプライベートスロットです。

4

2 に答える 2

3

まず、QObject::connectコールはおそらく、コールバックがシグナルにバインドされなかったことを示しています（コールバック/シグナルはQtメカニズムです）。LinuxでWindowsとは異なるQtバージョンを使用した結果である可能性があります。

次に、Qt Creatorでデバッグすることをお勧めします。これは、デバッグに最適なツールです。

にブレークポイントを設定しCommunicator::init()、失敗したconnect()呼び出しを見つけます。次に、この呼び出しに渡された引数をconnect()、UbuntuボックスにインストールされているQtバージョンで必要なものと比較します。また、ここにコードを投稿して Communicator::init()、他の人がコードを見て手伝ってくれるといいですね。

別の理由は、インストールされている共有ライブラリが別のバージョンのボックスにあるときにQtの1つのバージョンでコンパイルしていることである可能性があります...これは単なる推測ですが、再確認する価値があります。

Qtバージョンの問題ではない場合でも、失敗した呼び出しを調べて調査を開始することをお勧めします。また、Windowsに存在するいくつかのシステム変数が見つからず、実際の有効な値が期待される空の文字列/NULL文字列を渡している可能性もあります。

于 2012-06-23T20:18:22.727 に答える
0

完全に新しいプロジェクトを作成し、すべてのファイルをコピーすることで、自分で問題を修正しました。そのため、エラーはユーザーファイル内にある必要があると思います。

皆さんの提案に感謝します！

于 2012-07-01T20:15:56.457 に答える