We're using this for automated execution so we intentionally are only worried about the return code from the application, so that's fine. Thanks Jason for figuring this out and solving the problem!
Joe -----Original Message----- From: gem5-dev [mailto:[email protected]] On Behalf Of Jason Lowe-Power Sent: Monday, July 31, 2017 8:52 AM To: gem5 Developer List <[email protected]> Subject: Re: [gem5-dev] Python Execution Error 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
