Originally discovered in #3076.

Observation

With a very specific kernel (on commit f6adf9d) compiled on linux, running on imix, with the examples/tests/analog_comparator app (commit f5e164366028b5633006299ac136ba5bf0e0db74) as the only app running, the fourth syscall (a memop sbrk) fails in some way. In code, libtock-c memop() seems to get an invalid return code from the kernel (r0==1, which isn't a valid memop return code).

Comments

Observing this bug seems to take a VERY specific order of instructions and timing. The bug is very repeatable (Hudson and I can both observe it, on multiple imixes, over many trials, and it happens every time). However, modifying the kernel OR the app, OR the number of apps all cause it to go away. This suggests that the particular timing quirk of when the analog_comparator app calls sbrk matters significantly. For example, compiling the same kernel on mac and the issue goes away. Adding a second app (and lengthing the boot process), and the issue goes away. Adding even a single instruction before the svc 5 (memop) call in the app and the issue goes away.