F19: http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=135433 F20: http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=135220 ---------------------------------------------------------------------- Ran 47 tests in 5.711s OK (skipped=3) 343 tests OK. 1 test failed: test_gdb 2 tests altered the execution environment: test_site test_urllib2_localnet 26 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_devpoll test_ioctl test_kqueue test_msilib test_ossaudiodev test_pep277 test_smtpnet test_socketserver test_startfile test_systemtap test_timeout test_tk test_ttk_guionly test_unicode_file test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 4 skips unexpected on linux: test_ioctl test_systemtap test_tk test_ttk_guionly [2358814 refs]
Notes: It seems that python-gdb hook is not working properly. Compared to successful builds, PyObjectPtr.subclass_from_type (file python-gdb.py) is returning different values for members of the stack trace. Compare output on x86_64 [1] and on armv7hl [2] - output continues on x86_64, but ends with an error on armv7hl with (two failed tests, both seem to have the same cause): Traceback (most recent call last): File "/builddir/build/BUILD/Python-3.3.1/Lib/test/test_gdb.py", line 678, in test_up_at_top cmds_after_breakpoint=['py-up'] * 4) File "/builddir/build/BUILD/Python-3.3.1/Lib/test/test_gdb.py", line 213, in get_stack_trace self.assertEqual(err, '') AssertionError: "Python Exception <class '__main__.NullPyObjectPtr'> <__main__.PyFrameObjectPtr [truncated]... != '' - Python Exception <class '__main__.NullPyObjectPtr'> <__main__.PyFrameObjectPtr object at 0x23a6db0>: - Error occurred in Python command: <__main__.PyFrameObjectPtr object at 0x23a6db0> Traceback (most recent call last): File "/builddir/build/BUILD/Python-3.3.1/Lib/test/test_gdb.py", line 759, in test_threads cmds_after_breakpoint=['thread apply all py-bt']) File "/builddir/build/BUILD/Python-3.3.1/Lib/test/test_gdb.py", line 213, in get_stack_trace self.assertEqual(err, '') AssertionError: "Python Exception <class 'gdb.error'> There is no member named co_name.: \nError [truncated]... != '' - Python Exception <class 'gdb.error'> There is no member named co_name.: - Error occurred in Python command: There is no member named co_name. Not sure if the issue is in Python itself or in gdb so far. [1] https://gist.github.com/bkabrda/5387906 [2] https://gist.github.com/bkabrda/5387908
Sounds similar to bug 912025 fwiw
(In reply to comment #2) > Sounds similar to bug 912025 fwiw Yep, it does sound similar, but the patches don't seem to help. The problem with the second failed test (the one with "co_name") is this: - Frame.print_traceback is called - this calls Frame.get_pyop and then recursively calls Frame.print_traceback - in one call of get_pyop, PyFrameObjectPtr.from_pyobject_ptr raises the exception with the "no member co_name" message, because: -- in the first call, PyFrameObjectPtr.from_pyobject_ptr tries to construct a frame object (calls PyFrameObjectPtr.__init__) -- the constructor tries to init self.co, self.co_name and some others - in a non-corrupted run, it gets PyCodeObjectPtr and PyUnicodeObjectPtr for these two, but in the corrupted run it gets PyTupleObjectPtr for self.co -- setting self.co_name then fails, because PyTupleObjectPtr doesn't have "co_name" member (which propagates the exception to Frame.print_traceback, which obviously can't handle it) Now, the patches mentioned in bug 912025 don't help, because they just aren't made for this scenario. So this is py-bt. py-bt-full seems to be failing in a similar way. I'm not sure about the first traceback yet, though. It may be the same, but I'm afraid it's not :/
Any update on this? This is now blocking the building on a lot of packages on ARM and starting to cause us issues.
Nothing new, so far. I'll create some temporary fix that will skip printing corrupted frames in tracebacks - until the proper solution is found.
Fixed in [1], successful scratch build on arm-koji is here [2]. [1] http://pkgs.fedoraproject.org/cgit/python3.git/commit/?h=f19&id=b935d25938262c5161ab89752972f642f7dea5b6 [2] http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1741876
python3-3.3.1-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/python3-3.3.1-2.fc19
It's FAILED on mainline rawhide though
Yes, but that is caused by bug in systemd, as reported in https://bugzilla.redhat.com/show_bug.cgi?id=956035.
python3-3.3.1-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.