3

samsung SoC s3c6410 (ARM11) に Linux ボードがあります。buildroot: Python 2.7.1, uClibc-0.9.31 で rootfs をビルドします。Linux カーネル: Linux buildroot 2.6.28.6 #177 Mon Oct 3 12:50:57 EEST 2011 armv6l GNU/Linux

Pythonで書かれた私のアプリは、いくつかの謎の条件でこの例外を発生させます:

1) 例外:

 File "./dfbUtils.py", line 3209, in setItemData
ValueError: (4, 'Interrupted system call')

コード:

currentPage=int(math.floor(float(rowId)/self.pageSize))==self.selectedPage

2) 例外:

File "./terminalGlobals.py", line 943, in getFirmawareName
OSError: [Errno 4] Interrupted system call: 'firmware'

コード:

for fileName in os.listdir('firmware'):

アプリに関する情報: 3 ~ 7 のスレッドがあり、「シリアル」モジュールを介してシリアル ポートをリッスンし、directfb をラップする c 拡張機能を介して実装された gui を使用します。この例外は再現できません。それらは予測できません。

私はPythonでEINTR例外を探しましたが、EINTRは遅いシステムコールでのみ発生し、Pythonのモジュールソケット、サブプロセス、および別のモジュールはすでにプロセスEINTRであることがわかりました。では、私のアプリでは何が起こるでしょうか? 数学関数の単純な呼び出しがいつでもプログラムを中断できるのはなぜですか。まったく信頼できません。提案があるのは、ulibc のバグ、kernel/hw 処理のバグです。しかし、この提案は解決策を示していません。

今、os モジュールのいくつかの関数の周りにラップ関数 (EINTR の場合に操作を再開する) を作成しましたが、数学モジュールをラップすると実行時間が 2 倍になります。別の質問があります: 数学が他のモジュールよりも中断できる場合、信頼性を得るにはどうすればよいですか?

PS ライブラリ呼び出し (たとえば libm への呼び出し) はシステム コールではないことに気付きました。

4

1 に答える 1

0

スレッドと uClibc (#4994) に古いバグがありEINTR、0.9.30 で修正されました。修正は pthreads に対してテストされたので、uClibc をビルドするときにスレッドをどのように構成したかを確認するように tMC の提案を支持します。

また、malloc-simple オプションでコンパイルしてみてはいかがでしょうか? 遅いですが、問題が解決した場合は、スレッドの問題も示唆している可能性があります。

malloc-simple糖蜜のように単純で遅いです。これは uClibc 用にゼロから作成されたもので、最も単純な (したがって最小の) malloc 実装です。

これは、mmap()メモリの割り当てと解放にシステム コールのみを使用し、brk()システム コールをまったく使用しないため、メモリが非常に限られている MMU のないシステムに適しています。100% 標準に準拠し、スレッド セーフで、非常に小さく、解放されたメモリを再割り当てのためにプロセスのヒープに保持するのではなく、すぐに OS に戻します。また、非常に遅いです。

于 2012-03-11T05:57:11.450 に答える