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
