Bug 951802 - python3-3.3.1 is FTBFS on ARM due to failed gdb test
python3-3.3.1 is FTBFS on ARM due to failed gdb test
Product: Fedora
Classification: Fedora
Component: python3 (Show other bugs)
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Bohuslav "Slavek" Kabrda
Fedora Extras Quality Assurance
Depends On:
Blocks: ARMTracker
  Show dependency treegraph
Reported: 2013-04-13 04:55 EDT by Peter Robinson
Modified: 2013-05-30 17:56 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-05-30 17:56:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter Robinson 2013-04-13 04:55:53 EDT
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:
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 09:11:05 EDT
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
Comment 2 Dave Malcolm 2013-04-16 14:34:37 EDT
Sounds similar to bug 912025 fwiw
Comment 3 Bohuslav "Slavek" Kabrda 2013-04-17 09:29:20 EDT
(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 08:41:52 EDT
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 08:50:21 EDT
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 06:26:59 EDT
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
Comment 7 Fedora Update System 2013-04-24 06:29:46 EDT
python3-3.3.1-2.fc19 has been submitted as an update for Fedora 19.
Comment 8 Peter Robinson 2013-04-24 06:35:27 EDT
It's FAILED on mainline rawhide though
Comment 9 Bohuslav "Slavek" Kabrda 2013-04-24 06:45:33 EDT
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 00:41:55 EDT
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 00:58:45 EDT
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.