Hi Guys,
Thanks for the thorough analysis!
I have a patch that fixes the issue by adding an explicit type
conversion to the wrapper. I'll post the patch as soon as the CI system
has determined that it is worthy.
However, I agree with Jason, calling sys.exit(exit_event.getCode())
should be considered an anti-pattern. My main issue with that
(anti-)pattern is that it breaks gem5's interactive mode (-i).
Cheers,
Andreas
On 30/07/2017 17:57, Jason Lowe-Power wrote:
After digging into this way too much the issue isn't really with PyBind11,
but with Python 2.x and the way Simulation.run() works.
If you don't use Simulation.run() things work just fine. For instance,
running the following gives an exit code of 0:
build/X86/gem5.opt configs/learning_gem5/part1/simple.py
The problem is Simulation.run() calls sys.exit(exit_event.getCode()). It
turns out that getCode() returns a long, not an int. From the Python
documentation: https://docs.python.org/2/library/sys.html#sys.exit, "If
another type of object is passed, None is equivalent to passing zero, and
any other object is printed to stderr and results in an exit code of 1. In
particular, sys.exit("some error message") is a quick way to exit a program
when an error occurs."
This is a known "issue" in PyBind11 that all ints are returned as longs:
https://github.com/pybind/pybind11/issues/432. Plus, Python fixed all of
these issues in Python 3.0+ by not having both int and long types.
The easiest solution is to make a one line change in Simulation.py:
-sys.exit(exit_event.getCode())
+sys.exit(int(exit_event.getCode()))
Another solution is to not rely on the event's exit code for Python's exit
code. Honestly I don't think it makes much sense to return the exit code of
the guest application as the exit code of gem5. gem5 exits "correctly"
whether or not the guest application has a return code of 0. I would argue
for making the following change:
-sys.exit(exit_event.getCode())
+print "Guest application exit code:", exit_event.getCode()
Additionally, I don't think it makes sense for Simulation.run() to call
sys.exit! What if you wanted to do more processing after calling
Simulation.run()?
Joe and Brad: If this is causing issues for your internal regressions, feel
free to post a patch that fixes the issue. I've spent too much of my Sunday
trying to track this down :).
Jason
On Fri, Jul 28, 2017 at 5:00 PM Beckmann, Brad <[email protected]>
wrote:
Thanks Joe for confirming this is a problem with the public repo.
Andreas S., since you added the PyBind support, can you look into this?
This seems to be an issue that slipped through the regression tester, but
obviously we don't want gem5 returning a non-zero error code for successful
runs.
Thanks,
Brad
-----Original Message-----
From: gem5-dev [mailto:[email protected]] On Behalf Of Gross, Joe
Sent: Friday, July 28, 2017 2:56 PM
To: gem5 Developer List <[email protected]>
Subject: Re: [gem5-dev] Python Execution Error
Also, I've tested when running on the public master branch, SHA1=
dcb9334b94d14ccdc4ce42e1082e53d6d600e570, built for X86.
I tried a small hello world program:
#include <iostream>
int main() {
std::cerr << "hello world" << std::endl;
return 0;
}
/usr/bin/time -v ./build/X86/gem5.opt ./configs/example/se.py -c ./test ...
Exit status: 1
echo $?
1
So it seems that the public gem5 also is giving an error exit when the
application seems to work successfully. Maybe this has to do with PyBind11
and the python library?
Joe
-----Original Message-----
From: gem5-dev [mailto:[email protected]] On Behalf Of Gross, Joe
Sent: Thursday, July 27, 2017 6:01 PM
To: gem5 Developer List <[email protected]>
Subject: [gem5-dev] Python Execution Error
Hello,
We recently updated our internal repo to be based on a recent rev of the
public gem5 repo which includes PyBind. After this change, amongst others
from the public repo, I noticed that the simulator was exiting with return
code 1, although the simulations seem to run and complete.
What I found is that gem5 seems to be calling the python interpreter to
run python statements, such as "import m5" and they work fine, but when it
gets to "m5.main()", this fails to execute for some reason and
PyErr_Print() is called. This also seems to fail and thus the simulator
exits with error code 1. This happens after the simulation completes and
the simulated application returns. Below is the stack trace:
#0 __GI__exit (status=status@entry=1) at
../sysdeps/unix/sysv/linux/_exit.c:28
#1 0x00007ffff66f3a0b in __run_exit_handlers (status=status@entry=1,
listp=<optimized out>, run_list_atexit=run_list_atexit@entry=true) at
exit.c:92
#2 0x00007ffff66f3a95 in __GI_exit (status=status@entry=1) at exit.c:99
#3 0x00007ffff74f08cf in Py_Exit (sts=sts@entry=1) at
/usr/src/debug/Python-2.7.5/Python/pythonrun.c:1783
#4 0x00007ffff74f0a07 in handle_system_exit () at
/usr/src/debug/Python-2.7.5/Python/pythonrun.c:1155
#5 0x00007ffff74f0ccd in handle_system_exit () at
/usr/src/debug/Python-2.7.5/Python/pythonrun.c:1177
#6 PyErr_PrintEx (set_sys_last_vars=set_sys_last_vars@entry=1) at
/usr/src/debug/Python-2.7.5/Python/pythonrun.c:1165
#7 0x00007ffff74f0eca in PyErr_Print () at
/usr/src/debug/Python-2.7.5/Python/pythonrun.c:1068
#8 0x000000000141ed9c in m5Main (argc=argc@entry=7,
argv=argv@entry=0x7fffffffb158)
at build/X86/sim/init.cc:280
#9 0x0000000000b03323 in main (argc=7, argv=0x7fffffffb158) at
build/X86/sim/main.cc:58
Does anyone have any insights as to why this is happening? Was there some
mandatory update to execution scripts that we may have missed? Any help is
appreciated.
Joe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
