Bug 804694

Summary: gdb regression causes python segfaults when running pyrasite
Product: [Fedora] Fedora Reporter: Luke Macken <lmacken>
Component: pyrasiteAssignee: Luke Macken <lmacken>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: dmalcolm, jan.kratochvil, lmacken, pfrields, pmuldoon, sergiodj, tromey
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-31 17:18:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 803149    
Bug Blocks:    

Description Luke Macken 2012-03-19 15:41:44 UTC
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):

gdb-7.4.50.20120120-32.fc17

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:

    PyGILState_Ensure()
    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())")
    PyGILState_Release($1)

Comment 1 Dave Malcolm 2012-03-19 17:39:48 UTC
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 18:29:40 UTC
$ gdb -p 1416
GNU gdb (GDB) Fedora (7.4.50.20120120-31.fc18)
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,
flags=flags@entry=0xbf880800)
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,
arena=arena@entry=0x94dfd38)
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,
flags=flags@entry=0xbf88096c)
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 19:22:42 UTC
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 22:22:34 UTC
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 17:18:57 UTC
I am unable to reproduce this issue with a F18 i686 guest. Closing.