Bug 804694
Summary: | gdb regression causes python segfaults when running pyrasite | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Luke Macken <lmacken> |
Component: | pyrasite | Assignee: | Luke Macken <lmacken> |
Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | 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
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. |