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)
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?
$ 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
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.
Note: this appears to be really an issue with pyrasite; the "Component" field should be changed once pyrasite is in Fedora.
I am unable to reproduce this issue with a F18 i686 guest. Closing.