segfault when unrevisioned files exist in working tree

Bug #449372 reported by Per Johansson on 2009-10-12
6
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Martin Pool
2.0
Medium
Martin Pool
Gentoo Linux
Unknown
Medium

Bug Description

I built and installed an rpm of bzr-2.0.0 from source, but I am getting segfault when I try to do bzr st or bzr diff and a file exists in the tree which is not revisioned:

; bzr init foo
Created a standalone tree (format: 2a)
; cd foo/
; touch bar
; bzr st
Segmentation fault

Valgrind indicates it is a null access:
; valgrind /usr/bin/bzr st
... (python errors suppressed as python says they should be)

==21943== Invalid read of size 4
==21943== at 0xC4C9BF2: __pyx_f_21_dirstate_helpers_pyx_13ProcessEntryC__loop_one_block (_dirstate_helpers_pyx.c:8401)
==21943== by 0xC4CE451: __pyx_f_21_dirstate_helpers_pyx_13ProcessEntryC__iter_next (_dirstate_helpers_pyx.c:7479)
==21943== by 0xC4B2FDA: __pyx_f_21_dirstate_helpers_pyx_13ProcessEntryC___next__ (_dirstate_helpers_pyx.c:6016)
==21943== by 0x3228691422: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x3228695FE4: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x322869473E: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x3228695FE4: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x322864C459: (within /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x32286360EF: PyObject_Call (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x322869352B: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x3228695FE4: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x322869473E: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0)
==21943== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==21943==
==21943== Process terminating with default action of signal 11 (SIGSEGV)
==21943== Access not within mapped region at address 0x0
==21943== at 0xC4C9BF2: __pyx_f_21_dirstate_helpers_pyx_13ProcessEntryC__loop_one_block (_dirstate_helpers_pyx.c:8401)
==21943== by 0xC4CE451: __pyx_f_21_dirstate_helpers_pyx_13ProcessEntryC__iter_next (_dirstate_helpers_pyx.c:7479)
==21943== by 0xC4B2FDA: __pyx_f_21_dirstate_helpers_pyx_13ProcessEntryC___next__ (_dirstate_helpers_pyx.c:6016)
==21943== by 0x3228691422: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x3228695FE4: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x322869473E: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x3228695FE4: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x322864C459: (within /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x32286360EF: PyObject_Call (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x322869352B: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x3228695FE4: PyEval_EvalCodeEx (in /usr/lib64/libpython2.4.so.1.0)
==21943== by 0x322869473E: PyEval_EvalFrame (in /usr/lib64/libpython2.4.so.1.0)
==21943==

This is a CentOS 5 system running python 2.4 on x86_64

Related branches

Per Johansson (per.j) wrote :

The function in question is:
static int __pyx_tp_traverse_21_dirstate_helpers_pyx_Reader(PyObject *o, visitproc v, void *a) {
  int e;
  struct __pyx_obj_21_dirstate_helpers_pyx_Reader *p = (struct __pyx_obj_21_dirstate_helpers_pyx_Reader *)o;
  if (p->state) {
    e = (*v)(p->state, a); if (e) return e;
  }
  if (p->text) {
    e = (*v)(p->text, a); if (e) return e; // line 8401
  }
  return 0;
}

Since p-> have already been used I guess it has to be v that is NULL.

Per Johansson (per.j) wrote :

Sorry, that info was from the wrong .c-file, I didn't realise it's rebuilt as part of the rpm creation, here's the correct code:

static PyObject *__pyx_f_21_dirstate_helpers_pyx_13ProcessEntryC__loop_one_block(struct __pyx_obj_21_dirstate_helpers_pyx_ProcessEntryC *__pyx_v_self) {
      ...
      if (__pyx_1) {

        /* "/home/pelle/bzr-2.0.0/build/bdist.linux-x86_64/rpm/BUILD/bzr-2.0.0/bzrlib/_dirstate_helpers_pyx.pyx":1839 */
        Py_DECREF(__pyx_6); __pyx_6 = 0; // 8401
        Py_DECREF(__pyx_9); __pyx_9 = 0;
        Py_INCREF(__pyx_v_result);
        __pyx_r = __pyx_v_result;
        goto __pyx_L0;
        goto __pyx_L26;
      }

__pyx_6 is not referenced in this part of code earlier... very strange

Per Johansson (per.j) wrote :

Ok, upgrade to latest pyrex version fixes the problem. The previous one was Pyrex-0.9.4-2.fc6, the new one is build from source, version 0.9.8.5.

Vincent Ladeuil (vila) on 2009-10-12
Changed in bzr:
status: New → Confirmed
importance: Undecided → Medium
tags: added: centos
Matthew Fuller (fullermd) wrote :

Perhaps this is bug 276868 (fixed by blacklisting pyrex 0.9.4.1, so maybe we just need to expand the blacklisted version list)?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Per Johansson wrote:
> Ok, upgrade to latest pyrex version fixes the problem. The previous one
> was Pyrex-0.9.4-2.fc6, the new one is build from source, version
> 0.9.8.5.
>

There was a known bug in 0.9.4-? for which setup.py explicitly forbid
building using that version.

if have_pyrex and pyrex_version == '0.9.4.1':

It seems our version checking didn't include 0.9.4-2 or whatever you
were building with. If you could give us the result of:

  from Pyrex.Compiler.Version import version
  print version

We can add that version of the compiler to the black list. (My guess it
is either '0.9.4' or '0.9.4.0' or something along those lines.) Perhaps
we should just blacklist all of 0.9.4?

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrTVr0ACgkQJdeBCYSNAAMfzwCfe6Hhvap4JtEfdUsZlwguZm7V
rBkAn2q2vopgWHGyY2vNbeuLV3bCCVGp
=92vD
-----END PGP SIGNATURE-----

Per Johansson (per.j) wrote :

$ python
Python 2.4.3 (#1, Jan 21 2009, 01:11:33)
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from Pyrex.Compiler.Version import version
>>> print version
0.9.4
>>>

makes sense, since the 2 is the rpm build-number

Changed in gentoo:
status: Unknown → In Progress
Martin Pool (mbp) on 2010-01-12
Changed in bzr:
assignee: nobody → Martin Pool (mbp)
status: Confirmed → In Progress
tags: added: easy pyrex
Martin Pool (mbp) on 2010-01-14
Changed in bzr:
milestone: none → 2.1.0rc1
status: In Progress → Fix Released
Changed in gentoo:
status: In Progress → Invalid
Changed in gentoo:
status: Invalid → Confirmed
Changed in gentoo:
status: Confirmed → Unknown
Changed in gentoo:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.