Bug 863040

Created attachment 621505 [details]
File: environ

Created attachment 621506 [details]
File: build_ids

Created attachment 621507 [details]
File: maps

Created attachment 621508 [details]
File: open_fds

Created attachment 621509 [details]
File: cgroup

Created attachment 621510 [details]
File: limits

Created attachment 621511 [details]
File: backtrace

Thanks for filing this bug report.

Were you running this on a virtual machine, or on actual hardware?

What is the output of:

  rpm -q python

Looking at attachment 621511 [details] I see that a segmentation fault happened whilst the Python embedded within gdb was parsing some startup python code provided by gdb in frame #10 within finish_python_initialization()

The fault appears to have happened within Python/symtable.c somewhere around here:

   876  static int
   877  symtable_add_def(struct symtable *st, PyObject *name, int flag)
   878  {
   879      PyObject *o;
   880      PyObject *dict;
   881      long val;
   882      PyObject *mangled = _Py_Mangle(st->st_private, name);
   883  
   884      if (!mangled)
   885          return 0;
   886      dict = st->st_cur->ste_symbols;
   887      if ((o = PyDict_GetItem(dict, mangled))) {
>>>888          val = PyInt_AS_LONG(o);
   889          if ((flag & DEF_PARAM) && (val & DEF_PARAM)) {

The attachment reports the error occurring at line 888;  PyInt_AS_LONG is a macro:

  #define PyInt_AS_LONG(op) (((PyIntObject *)(op))->ob_ival)

but for that to be a segfault would require "o" to be invalid or NULL.  It can't be NULL due to the test at line 887.

The attachment reports the error occurring here:

=> 0x00007f2abdb02ce0 <+96>:	mov    0x10(%rax),%rdi

which appears to be the op->ob_ival lookup, with rax = 0x8000000000000, so I believe we're seeing "o" aka "op" with value 0x8000000000000

Given how early this bug occurred, and how often this code is run, I suspect virtualization or hardware issues.

run on hardware Lenovo Z570

rpm -q python
python-2.7.3-7.2.fc17.x86_64


can this error appear because of lost files?

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.