Bug 951802

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.