Getting IOError

[rahul-paul]

rahul@rahul-desktop { ~/pycharm-workspace/ceres_new }-> python -m pyinstrument ceres/sim/sim_definition.py
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in run_module_as_main
"main", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in run_code
exec code in run_globals
File "/home/rahul/src/pyinstrument/pyinstrument/main.py", line 135, in
main()
File "/home/rahul/src/pyinstrument/pyinstrument/main.py", line 79, in main
exec(code, globs, None)
File "/home/rahul/src/pyinstrument/pyinstrument/main.py", line 25, in exec
exec("exec code in globs, locs")
File "", line 1, in
File "ceres/sim/sim_definition.py", line 48, in
main()
File "ceres/sim/sim_definition.py", line 31, in main
from aglyph.assembler import Assembler
File "/usr/local/lib/python2.7/dist-packages/aglyph/init.py", line 61, in
platform.platform()))
File "/usr/lib/python2.7/platform.py", line 1576, in platform
system,node,release,version,machine,processor = uname()
File "/usr/lib/python2.7/platform.py", line 1273, in uname
processor = _syscmd_uname('-p','')
File "/usr/lib/python2.7/platform.py", line 1029, in _syscmd_uname
output = string.strip(f.read())
IOError: [Errno 4] Interrupted system call
Alarm clock

[rahul-paul]

running on ubuntu 12.04

[asmeurer]

To quote Antoine Pitrou (a core CPython developer) regarding this library

Be careful about this known issue: """In signal mode, any calls to time.sleep will return immediately. This is because of an implementation detail of time.sleep, but matches the behaviour of the C function sleep."""

I doubt that only time.sleep will be affected. Using signals really means that many C library functions will return EINTR early when a signal is received. If your workload does some I/O its behaviour may change when profiled by this library.

(yes, Unix signals are really awful!)

So probably you can't use the signal version of pyinstrument for your application.

[joerick]

Okay... wow. Thanks for the bug report. I had no idea signals could affect system calls like that. I suppose syscalls have to bail so that the signal handler can fire in userspace?

How often have you seen this with your program? Once/a few times/Always?

Regardless, if you're getting a lot of these errors, you should switch to setprofile mode. I see you're using the command-line interface. I'll have a look at putting a flag in there to switch to setprofile mode, since I imagine it's going to be a problem for a few more people than just you.

It might also be a good idea for me to catch IOError 4 in pyinstrument main.py and give some explaination about what's going on.

By the way, @asmeurer, do you have a link to the discussion you quoted? I might learn something!

[rahul-paul]

@joerick yes it would be great if you could add a setprofile mode argument for the command line

[asmeurer]

No, it was an internal discussion on a company mailing list about pyinstrument. Antoine's comment that I pasted here was the only useful thing in the discussion about this. You'll have to reach out to other sources for information on this. Let me know what you learn. I also didn't know this about signals.

[joerick]

Strangely, I couldn't recreate this on OS X or Ubuntu 13.04, but could with Ubuntu 12.04.

I'm doing three things here:

• fc7fe46 Adding a call to signal.siginterrupt to change the behaviour of system calls that are interrupted. Now system calls that have transferred no data yet will be automatically resumed once the signal has been handled. This will hopefully fix the majority of cases (including the case on this issue).
• 5245e52 Where the problem persists, I'm adding a --setprofile flag to the command-line interface to switch to that behaviour.
• b70bb51 When an IOError (errno EINTR) is raised in the command-line interface, a message is displayed explaining how to switch to setprofile mode.

[joerick]

Hopefully the signal.siginterrupt call should have fixed the above for you @rahul-paul. If you have a chance could you check it's no longer a problem and report back? Thanks!

[rahul-paul]

@joerick just checked with the latest code - it does fix my problem. Thanks.

[joerick]

Really hoping that PEP 475 makes it into Python 3.5. That could solve this once and for all.