I thought of that solution, too, but I wasn't sure how to do it with PyBind11. I think it is the best solution to the problem. Thanks for coding it up, Andreas!
The sys.exit(exit_event.getCode()) is wrapped in "if not interactive" so it doesn't completely break that usage. But it's still ugly and confusing! Jason On Mon, Jul 31, 2017 at 5:22 AM Andreas Sandberg <[email protected]> wrote: > 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
