|Summary:||python3-3.3.1 is FTBFS on ARM due to failed gdb test|
|Product:||[Fedora] Fedora||Reporter:||Peter Robinson <pbrobinson>|
|Component:||python3||Assignee:||Bohuslav "Slavek" Kabrda <bkabrda>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||amcnabb, bkabrda, dmalcolm, jan.kratochvil, tomspur|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-05-30 21:56:06 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Peter Robinson 2013-04-13 08:55:53 UTC
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]
Comment 1 Bohuslav "Slavek" Kabrda 2013-04-15 13:11:05 UTC
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  and on armv7hl  - 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.  https://gist.github.com/bkabrda/5387906  https://gist.github.com/bkabrda/5387908
Comment 3 Bohuslav "Slavek" Kabrda 2013-04-17 13:29:20 UTC
(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 :/
Comment 4 Peter Robinson 2013-04-23 12:41:52 UTC
Any update on this? This is now blocking the building on a lot of packages on ARM and starting to cause us issues.
Comment 5 Bohuslav "Slavek" Kabrda 2013-04-23 12:50:21 UTC
Nothing new, so far. I'll create some temporary fix that will skip printing corrupted frames in tracebacks - until the proper solution is found.
Comment 6 Bohuslav "Slavek" Kabrda 2013-04-24 10:26:59 UTC
Fixed in , successful scratch build on arm-koji is here .  http://pkgs.fedoraproject.org/cgit/python3.git/commit/?h=f19&id=b935d25938262c5161ab89752972f642f7dea5b6  http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1741876
Comment 7 Fedora Update System 2013-04-24 10:29:46 UTC
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
Comment 8 Peter Robinson 2013-04-24 10:35:27 UTC
It's FAILED on mainline rawhide though
Comment 9 Bohuslav "Slavek" Kabrda 2013-04-24 10:45:33 UTC
Yes, but that is caused by bug in systemd, as reported in https://bugzilla.redhat.com/show_bug.cgi?id=956035.
Comment 10 Fedora Update System 2013-04-30 04:41:55 UTC
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.
Comment 11 Fedora Admin XMLRPC Client 2013-05-10 04:58:45 UTC
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.