Comment 3 for bug 127399

I can also reproduce this bug fairly easily after a couple of tries on my feisty laptop.

I tried to run bash within valgrind memory checker and it detects several errors:

I run a bash with:

$ valgrind --trace-children=yes bash

... then try to run a non existing command in background and get several kind of errors such as among other things:

==17299== Invalid read of size 4
==17299== at 0x808BB0F: PyObject_Free (in /usr/bin/python2.5)
==17299== by 0x810AAFB: (within /usr/bin/python2.5)
==17299== by 0x8110F89: (within /usr/bin/python2.5)
==17299== by 0x80EFAEB: (within /usr/bin/python2.5)
==17299== by 0x80D7821: PyErr_Clear (in /usr/bin/python2.5)
==17299== by 0x80E88E4: (within /usr/bin/python2.5)
==17299== by 0x80E8AE4: PyErr_PrintEx (in /usr/bin/python2.5)
==17299== by 0x80E9302: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
==17299== by 0x805932F: Py_Main (in /usr/bin/python2.5)
==17299== by 0x8058861: main (in /usr/bin/python2.5)
==17299== Address 0x4361010 is not stack'd, malloc'd or (recently) free'd
==17299==
==17299== Conditional jump or move depends on uninitialised value(s)
==17299== at 0x808BB18: PyObject_Free (in /usr/bin/python2.5)
==17299== by 0x810AAE2: (within /usr/bin/python2.5)
==17299== by 0x81121A0: (within /usr/bin/python2.5)
==17299== by 0x8085268: (within /usr/bin/python2.5)
==17299== by 0x8086BAD: PyDict_SetItem (in /usr/bin/python2.5)
==17299== by 0x8088807: _PyModule_Clear (in /usr/bin/python2.5)
==17299== by 0x80DCC9C: PyImport_Cleanup (in /usr/bin/python2.5)
==17299== by 0x80E8D9E: Py_Finalize (in /usr/bin/python2.5)
==17299== by 0x80E88E9: (within /usr/bin/python2.5)
==17299== by 0x80E8AE4: PyErr_PrintEx (in /usr/bin/python2.5)
==17299== by 0x80E9302: PyRun_SimpleFileExFlags (in /usr/bin/python2.5)
==17299== by 0x805932F: Py_Main (in /usr/bin/python2.5)

Not sure whether this stack trace is right or not. I'd be surprised if bash used Python libraries?!