This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 912025 - python-2.7.3-15.fc19 is FTBFS on ARM
python-2.7.3-15.fc19 is FTBFS on ARM
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: python (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dave Malcolm
Fedora Extras Quality Assurance
:
Depends On:
Blocks: ARMTracker
  Show dependency treegraph
 
Reported: 2013-02-17 04:42 EST by Peter Robinson
Modified: 2013-02-21 11:16 EST (History)
6 users (show)

See Also:
Fixed In Version: python-2.7.3-21.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 11:16:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to python-gdb.py to deal with FakeRepr (4.63 KB, patch)
2013-02-18 22:45 EST, Dave Malcolm
no flags Details | Diff

  None (edit)
Description Peter Robinson 2013-02-17 04:42:59 EST
We're seeing the following failure to build on ARM.

http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1444664
Comment 1 Thomas Spura 2013-02-17 11:30:27 EST
The error from root.log is:
DEBUG util.py:314:  Executing command: ['rpm', '-Uvh', '--nodeps', '/builddir/build/originals/python-2.7.3-15.fc19.src.rpm'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'echo -n "<mock-chroot>"', 'HOME': '/builddir', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin'}
DEBUG util.py:264:  Updating / installing...
DEBUG util.py:264:  python-2.7.3-15.fc19                  ########################################
DEBUG util.py:264:  error: unpacking of archive failed on file /builddir/build/SOURCES/Python-2.7.3.tar.xz;5120a17e: cpio: read failed - Inappropriate ioctl for device
DEBUG util.py:264:  error: /builddir/build/originals/python-2.7.3-15.fc19.src.rpm cannot be installed

This seems more like a rpm/cpio bug than a python one.

Are other builds maybe similarly failing like this one?
Comment 2 Peter Robinson 2013-02-17 11:42:23 EST
> This seems more like a rpm/cpio bug than a python one.

It's not. We've got dozens of build failures for this package NVR:

http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1443153
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1444171

1 test failed:
    test_gdb
38 tests skipped:
    test_aepack test_al test_applesingle test_bsddb185 test_bsddb3
    test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_dl test_gl test_imgfile test_ioctl test_kqueue
    test_linuxaudiodev test_macos test_macostools test_msilib
    test_ossaudiodev test_pep277 test_scriptpackages test_smtpnet
    test_socketserver test_startfile test_sunaudiodev test_timeout
    test_tk test_ttk_guionly test_unicode_file test_urllib2net
    test_urllibnet test_winreg test_winsound test_zipfile64
3 skips unexpected on linux2:
    test_ioctl test_tk test_ttk_guionly
[1184003 refs]
make: *** [test] Error 1
Comment 3 Dave Malcolm 2013-02-18 16:44:39 EST
From http://arm.koji.fedoraproject.org//work/tasks/4172/1444172/build.log
this failure occurs on %check of the debug build:

======================================================================
FAIL: test_up_at_top (test.test_gdb.StackNavigationTests)
Verify handling of "py-up" at the top of the stack
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7.3/Lib/test/test_gdb.py", line 682, in test_up_at_top
    cmds_after_breakpoint=['py-up'] * 4)
  File "/builddir/build/BUILD/Python-2.7.3/Lib/test/test_gdb.py", line 189, in get_stack_trace
    self.assertEqual(err, '')
AssertionError: "Python Exception <type 'exceptions.TypeError'> coercing to Unicode: need string or buffer, FakeRepr found: \nError occurred in Python command: coercing to Unicode: need string or buffer, FakeRepr found" != ''
----------------------------------------------------------------------

(the optimized build doesn't appear to get tested, owing to the failure of the debug build).
Comment 4 Dave Malcolm 2013-02-18 22:21:24 EST
For some reason, within the "py-up" called by the test suite, PyFrameObjectPtr.filename() is failing to extract a proxy str value within gdb for the co_filename value from the inferior process, and instead builds a FakeRepr instance.  The TypeError exception occurs within PyFrameObjectPtr.current_line() when this FakeRepr is passed to the open() builtin (for reading the source from disk).

(Hope to fix it shortly, but getting late here)
Comment 5 Dave Malcolm 2013-02-18 22:45:56 EST
Created attachment 699301 [details]
Patch to python-gdb.py to deal with FakeRepr
Comment 6 Dave Malcolm 2013-02-19 17:25:21 EST
Fix committed to git as:
http://pkgs.fedoraproject.org/cgit/python.git/commit/?id=a0eea8701ec8091b9a4228b3a4bd529e68194c29

This also experimentally re-enables the %check on ARM

Building python-2.7.3-19.fc19 for rawhide
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5034410
Comment 7 Dave Malcolm 2013-02-19 21:46:12 EST
(In reply to comment #6)
> Fix committed to git as:
> http://pkgs.fedoraproject.org/cgit/python.git/commit/
> ?id=a0eea8701ec8091b9a4228b3a4bd529e68194c29
> 
> This also experimentally re-enables the %check on ARM
> 
> Building python-2.7.3-19.fc19 for rawhide
> Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5034410

^^^ that build failed (due to me forgetting to update %files in a prior commit), but this one succeeded (on i686 and x86_64):

  Building python-2.7.3-20.fc19 for rawhide
  Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5034780

Does this fix the build on ARM?
Comment 8 Peter Robinson 2013-02-20 05:08:40 EST
Build running here http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1452879
Comment 9 Peter Robinson 2013-02-20 07:35:10 EST
Build failed http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1452879
Comment 10 Dave Malcolm 2013-02-20 10:50:11 EST
Thanks.

This time the debug build's check ran successfully (including test_gdb)

The optimized build's check failed, though again just in test_gdb.

The failure was similar to before, in that it occurred in the test for "py-up" at the top of the stack, though this time the stderr was different:

======================================================================
FAIL: test_up_at_top (test.test_gdb.StackNavigationTests)
Verify handling of "py-up" at the top of the stack
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7.3/Lib/test/test_gdb.py", line 682, in test_up_at_top
    cmds_after_breakpoint=['py-up'] * 4)
  File "/builddir/build/BUILD/Python-2.7.3/Lib/test/test_gdb.py", line 189, in get_stack_trace
    self.assertEqual(err, '')
AssertionError: "Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0xf: \nError occurred in Python command: Cannot access memory at address 0xf" != ''
----------------------------------------------------------------------
Comment 11 Dave Malcolm 2013-02-20 12:37:52 EST
gdb was giving entirely bogus values for "f" (PyFrameObject*) in various C frames higher up in the stack, presumably due to compiler optimization.

It seems that this functionality is always at risk from optimization eliminating our ability to read the variables of interest, so for now I'm disabling all of StackNavigationTests when Python is optimized (two of them already were individually disabled).

Fix committed to git as:
http://pkgs.fedoraproject.org/cgit/python.git/commit/?id=d63f6bd94f3dcbcbaa3ece4e37eccfe4cb972032


Building python-2.7.3-21.fc19 for rawhide
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5037364
Comment 12 Peter Robinson 2013-02-20 12:49:23 EST
ARM build: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1453625
Comment 13 Brendan Conoboy 2013-02-21 00:01:06 EST
Looks like the build is good.  Thanks Dave!

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