Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 951802 - python3-3.3.1 is FTBFS on ARM due to failed gdb test
Summary: python3-3.3.1 is FTBFS on ARM due to failed gdb test
Alias: None
Product: Fedora
Classification: Fedora
Component: python3
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Bohuslav "Slavek" Kabrda
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
Reported: 2013-04-13 08:55 UTC by Peter Robinson
Modified: 2013-05-30 21:56 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-05-30 21:56:06 UTC
Type: Bug

Attachments (Terms of Use)

Description Peter Robinson 2013-04-13 08:55:53 UTC

Ran 47 tests in 5.711s
OK (skipped=3)
343 tests OK.
1 test failed:
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
It seems that python-gdb hook is not working properly. Compared to successful builds, PyObjectPtr.subclass_from_type (file 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/", line 678, in test_up_at_top
    cmds_after_breakpoint=['py-up'] * 4)
  File "/builddir/build/BUILD/Python-3.3.1/Lib/test/", 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/", line 759, in test_threads
    cmds_after_breakpoint=['thread apply all py-bt'])
  File "/builddir/build/BUILD/Python-3.3.1/Lib/test/", 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.


Comment 2 Dave Malcolm 2013-04-16 18:34:37 UTC
Sounds similar to bug 912025 fwiw

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_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
-- 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 [1], successful scratch build on arm-koji is here [2].


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.

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

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.

Note You need to log in before you can comment on or make changes to this bug.