Bug 804694 - gdb regression causes python segfaults when running pyrasite
gdb regression causes python segfaults when running pyrasite
Product: Fedora
Classification: Fedora
Component: pyrasite (Show other bugs)
i686 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Luke Macken
Fedora Extras Quality Assurance
Depends On: 803149
  Show dependency treegraph
Reported: 2012-03-19 11:41 EDT by Luke Macken
Modified: 2016-09-19 22:43 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-10-31 13:18:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Luke Macken 2012-03-19 11:41:44 EDT
Description of problem:

After upgrading to F17, my code injection tool 'pyrasite' now causes
python to segfault. Downgrading to F16's gdb resolves this problem.

Version-Release number of selected component (if applicable):


Steps to Reproduce:

Run 'python -v' in a different window.

git clone git://github.com/lmacken/pyrasite.git
cd pyrasite
python -m pyrasite.main $(pgrep -f "python -v") pyrasite/payloads/helloworld.py

Actual results:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
0x00dd7416 in __kernel_vsyscall ()
Program received signal SIGSEGV, Segmentation fault.
0x49036d17 in PyGILState_Ensure () at /usr/src/debug/Python-2.7.2/Python/pystate.c:634
634 }
Program received signal SIGSEGV, Segmentation fault.
0x48d473b4 in malloc () from /lib/libc.so.6

Expected results:

'python -v' interpreter should print "Hello World"

Additional info:

Under the hood, pyrasite is attaching to the process and running these
commands in gdb:

    PyRun_SimpleString("import sys; sys.path.insert(0, \\"/home/lmacken/code/github.com/pyrasite/pyrasite/payloads\\"); sys.path.insert(0, \\"/home/lmacken/code/github.com/pyrasite\\"); exec(open(\\"/home/lmacken/code/github.com/pyrasite/pyrasite/payloads/helloworld.py\\").read())")
Comment 1 Dave Malcolm 2012-03-19 13:39:48 EDT
What happens if you directly attach in gdb and manually enter the commands that pyrasite would run?

At what exact point does it fail?  What is the backtrace at that point?
Comment 2 Luke Macken 2012-03-20 14:29:40 EDT
$ gdb -p 1416
GNU gdb (GDB) Fedora (
0x004e3416 in __kernel_vsyscall ()
(gdb) call PyGILState_Ensure()
Program received signal SIGSEGV, Segmentation fault.
0x49036d17 in PyGILState_Ensure ()
at /usr/src/debug/Python-2.7.2/Python/pystate.c:634
634 }
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(PyGILState_Ensure) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) bt
#0 0x49036d17 in PyGILState_Ensure ()
at /usr/src/debug/Python-2.7.2/Python/pystate.c:634
#1 <function called from gdb>
#2 0x004e3416 in __kernel_vsyscall ()
#3 0x48dba6ed in ___newselect_nocancel ()
at ../sysdeps/unix/syscall-template.S:82
#4 0x00d10a07 in readline_until_enter_or_signal (signal=<synthetic pointer>,
prompt=0xb77286d4 ">>> ")
at /usr/src/debug/Python-2.7.2/Modules/readline.c:961
#5 call_readline (sys_stdin=0x48e7ba80, sys_stdout=0x48e7b9e0, prompt=
0xb77286d4 ">>> ") at /usr/src/debug/Python-2.7.2/Modules/readline.c:1055
#6 0x48f7ba4b in PyOS_Readline (sys_stdin=0x48e7ba80, sys_stdout=0x48e7b9e0,
prompt=0xb77286d4 ">>> ")
at /usr/src/debug/Python-2.7.2/Parser/myreadline.c:210
#7 0x48f7c7c4 in tok_nextc (tok=tok@entry=0x95110f0)
at /usr/src/debug/Python-2.7.2/Parser/tokenizer.c:860
#8 0x48f7d587 in tok_get (p_end=0xbf8807ac, p_start=0xbf8807a8, tok=0x95110f0)
at /usr/src/debug/Python-2.7.2/Parser/tokenizer.c:1206
#9 PyTokenizer_Get (tok=tok@entry=0x95110f0, p_start=p_start@entry=
0xbf8807a8, p_end=p_end@entry=0xbf8807ac)
at /usr/src/debug/Python-2.7.2/Parser/tokenizer.c:1646
#10 0x48f78ebc in parsetok (tok=0x95110f0, g=g@entry=0x0, start=256, err_ret=
0xbf880804, flags=0xbf880800)
at /usr/src/debug/Python-2.7.2/Parser/parsetok.c:159
#11 0x48f794af in PyParser_ParseFileFlagsEx (fp=0x100, fp@entry=0x48e7ba80,
filename=0xbf880804 "\n", filename@entry=0x4907d913 "<stdin>", g=
0xbf880800, start=start@entry=256, ps1=ps1@entry=0xb77286d4 ">>> ",
ps2=ps2@entry=0xb7728c34 "... ", err_ret=err_ret@entry=0xbf880804,
at /usr/src/debug/Python-2.7.2/Parser/parsetok.c:106
#12 0x49037fb7 in PyParser_ASTFromFile (fp=fp@entry=0x48e7ba80,
---Type <return> to continue, or q <return> to quit---
filename=filename@entry=0x4907d913 "<stdin>", start=start@entry=256,
ps1=ps1@entry=0xb77286d4 ">>> ", ps2=ps2@entry=0xb7728c34 "... ",
flags=flags@entry=0xbf88096c, errcode=errcode@entry=0xbf88087c,
at /usr/src/debug/Python-2.7.2/Python/pythonrun.c:1477
#13 0x49039078 in PyRun_InteractiveOneFlags (fp=fp@entry=0x48e7ba80,
filename=filename@entry=0x4907d913 "<stdin>", flags=flags@entry=0xbf88096c)
at /usr/src/debug/Python-2.7.2/Python/pythonrun.c:833
#14 0x49039290 in PyRun_InteractiveLoopFlags (fp=fp@entry=0x48e7ba80,
filename=filename@entry=0x4907d913 "<stdin>", flags=flags@entry=0xbf88096c)
at /usr/src/debug/Python-2.7.2/Python/pythonrun.c:773
#15 0x490398a2 in PyRun_AnyFileExFlags (fp=fp@entry=0x48e7ba80,
filename=filename@entry=0x4907d913 "<stdin>", closeit=closeit@entry=0,
at /usr/src/debug/Python-2.7.2/Python/pythonrun.c:742
#16 0x4904aae5 in Py_Main (argc=argc@entry=2, argv=argv@entry=0xbf880aa4)
at /usr/src/debug/Python-2.7.2/Modules/main.c:599
#17 0x08048578 in main (argc=2, argv=0xbf880aa4)
at /usr/src/debug/Python-2.7.2/Modules/python.c:23
Comment 3 Luke Macken 2012-03-20 15:22:42 EDT
I just installed a x86_64 kvm guest based on the F17 20120318.10 nightly, and cannot reproduce this issue -- looks like it is i686 specific.
Comment 4 Dave Malcolm 2012-03-23 18:22:34 EDT
Note: this appears to be really an issue with pyrasite; the "Component" field should be changed once pyrasite is in Fedora.
Comment 5 Luke Macken 2012-10-31 13:18:57 EDT
I am unable to reproduce this issue with a F18 i686 guest. Closing.

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