python: functions from math and os modules are interrupted by EINTR

Question

I have linux board on samsung SoC s3c6410 (ARM11). I build rootfs with buildroot: Python 2.7.1, uClibc-0.9.31. Linux kernel: Linux buildroot 2.6.28.6 #177 Mon Oct 3 12:50:57 EEST 2011 armv6l GNU/Linux

My app, written on python, in some mysterios conditons raise this exceptions:

1) exception:

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

code:

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

2) exception:

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

code:

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

Some info about app: it have 3-7 threads, listen serial ports via 'serial' module, use gui implemented via c extension that wrap directfb, i can't reproduce this exceptions, they are not predictable.

I googled for EINTR exceptions in python, but only found that EINTR can occur only on slow system calls and python's modules socket, subprocess and another one is already process EINTR. So what happens in my app? Why simple call of math function can interrupt program at any time, it's not reliable at all. I have only suggestions: ulibc bug, kernel/hw handling bug. But this suggestions don't show me solution.

Now i created wrap functions (that restart opertion in case of EINTR) around some functions from os module, but wrapping math module will increase execution time in 2 times. There another question: if math can be interrutped than other module also can and how to get reliability?

PS I realize that library call (to libm for example) is not system call, so why i have "Interrupted system call"?

Answer 1

There was an old bug with threads and EINTR in uClibc (#4994) that they fixed in 0.9.30. The fix was tested against pthreads, so I would second the suggestion by tMC to check how you configured threads when building uClibc.

Also you could try compiling with the malloc-simple option? It is slow, but if your issue disappears it may suggest threading issues as well:

malloc-simple is trivially simple and slow as molasses. It was written from scratch for uClibc, and is the simplest possible (and therefore smallest) malloc implementation.

This uses only the mmap() system call to allocate and free memory, and does not use the brk() system call at all, making it a fine choice for MMU-less systems with very limited memory. It's 100% standards compliant, thread safe , very small, and releases freed memory back to the OS immediately rather than keeping it in the process's heap for reallocation. It is also VERY SLOW.