From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11405 invoked by alias); 26 Aug 2009 13:47:14 -0000 Received: (qmail 11388 invoked by uid 48); 26 Aug 2009 13:47:14 -0000 Date: Wed, 26 Aug 2009 13:47:00 -0000 Message-ID: <20090826134714.11387.qmail@sourceware.org> From: "pmuldoon at redhat dot com" To: gdb-prs@sourceware.org In-Reply-To: <20090629213421.10344.ppluzhnikov@google.com> References: <20090629213421.10344.ppluzhnikov@google.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug c++/10344] Pretty printers that call into inferior could crash GDB X-Bugzilla-Reason: CC Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2009-q3/txt/msg00165.txt.bz2 ------- Additional Comments From pmuldoon at redhat dot com 2009-08-26 13:47 ------- I looked at this a little today. I wanted to see if similar results happen with the work on the archer-pmuldoon-python-value-infcall branch. The same results occur. However I do not believe this to be an issue with inferior function calls, but a peculiarity/side-effect with GDB's UI levels. If, given the original test case, we just make the call directly within the GDB command line, I see: python gdb.parse_and_eval("Foo::print(0x123)") Program received signal SIGSEGV, Segmentation fault. 0x0000000000400560 in Foo::print this=0x123) at t.cc:11 11 return *p; // crash! Traceback (most recent call last): File "", line 1, in RuntimeError: 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 (Foo::print() const) will be abandoned. When the function is done executing, GDB will silently stop. Error while executing Python code. I noted the internal assert raised about uiout levels in the original bug report and decided to investigate this message: "../../gdb/ui-out.c:129: internal-error: push_level: Assertion `uiout->level >= 0 && uiout->level < MAX_UI_OUT_LEVELS' failed. So while debugging GDB I noted that that the currently maximum used uiout->level is 3 from a "directly" called function via parse_and_eval. When this call is made from within a Python pretty printer, the uiout->level exceeds the limit specified MAX_UI_OUT_LEVELS (which is 6), and the call to error() reporting the signal condition in the inferior function call cannot be printed. This triggers an internal GDB error condition. Changing the MAX_UI_OUT_LEVELS to 7 "fixed" the problem, and the call proceeded as it should. I do not know why the uiout levels usage is so increased via a the pretty printer, or indeed know very much about uiout levels at all. Or why the level is set at 6 in the code. But I thought I would produce my notes here. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10344 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.