From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32736 invoked by alias); 2 May 2008 13:18:02 -0000 Received: (qmail 32703 invoked by uid 71); 2 May 2008 13:18:01 -0000 Resent-Date: 2 May 2008 13:18:01 -0000 Resent-Message-ID: <20080502131801.32702.qmail@sourceware.org> Resent-From: gdb-gnats@sources.redhat.com (GNATS Filer) Resent-To: nobody@sources.redhat.com Resent-Cc: gdb-prs@sources.redhat.com, skip@pobox.com Resent-Reply-To: gdb-gnats@sources.redhat.com, skip@pobox.com Received: (qmail 32371 invoked by uid 48); 2 May 2008 13:17:16 -0000 Message-Id: <20080502131716.32370.qmail@sourceware.org> Date: Fri, 02 May 2008 13:18:00 -0000 From: skip@pobox.com Reply-To: skip@pobox.com To: gdb-gnats@sources.redhat.com Cc: skip@pobox.com X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) X-GNATS-Notify: skip@pobox.com Subject: gdb/2450: gdb core dump in user-defined stack print command 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: 2008-q2/txt/msg00026.txt.bz2 >Number: 2450 >Category: gdb >Synopsis: gdb core dump in user-defined stack print command >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Fri May 02 13:18:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Skip Montanaro >Release: 6.7 >Organization: >Environment: GNU gdb 6.7 ... This GDB was configured as "i386-pc-solaris2.10". Python2.5 or later. (If tried against Python 2.4 or earlier, replace PyEval_EvalFrameEx with PyEval_EvalFrame in the user-defined pystack command.) >Description: I have a set of gdb commands which help me navigate around the Python interpreter stack. A version is distributed with Python in .../Misc/gdbinit. In recent versions of gdb they've quit working, causing gdb itself to drop a core file. Today I spent a little time trying to narrow down the problem. I've boiled it down to this fairly simple user-defined command: define pystack select-frame 0 set $last = 0 while $sp != $last if $pc > PyEval_EvalFrameEx && $pc < PyEval_EvalCodeEx frame end set $last = $sp up-silently 1 end select-frame 0 end I can define the command, but if I try to execute it gdb gets an apparent assertion error and dumps core. Here's the gdb backtrace: #0 0xfede5f85 in _lwp_kill () from /lib/libc.so.1 #1 0xfede2dfe in thr_kill () from /lib/libc.so.1 #2 0xfed911cb in raise () from /lib/libc.so.1 #3 0xfed715e9 in abort () from /lib/libc.so.1 #4 0x0808d62b in internal_vproblem (problem=0x82f04e0, file=0x828b9cf "../../gdb/regcache.c", line=, fmt=0x828b9b4 "%s: Assertion `%s' failed.", ap=0x8046a6c "G\036%\bX\237+\b2") at ../../gdb/utils.c:794 #5 0x0808af93 in internal_verror (file=0x828b9cf "../../gdb/regcache.c", line=164, fmt=0x828b9b4 "%s: Assertion `%s' failed.", ap=0x8046a6c "G\036%\bX\237+\b2") at ../../gdb/utils.c:809 #6 0x0808afc9 in internal_error (file=0x828b9cf "../../gdb/regcache.c", line=164, string=0x828b9b4 "%s: Assertion `%s' failed.") at ../../gdb/utils.c:818 #7 0x080e2067 in register_type (gdbarch=0x833e370, regnum=50) at ../../gdb/regcache.c:164 #8 0x080ecaaa in evaluate_subexp_standard (expect_type=0x0, exp=0x11461640, pos=0x80473c4, noside=EVAL_AVOID_SIDE_EFFECTS) at ../../gdb/eval.c:511 #9 0x080e9d16 in evaluate_subexp (expect_type=0x0, exp=0x0, pos=0x8046974, noside=EVAL_AVOID_SIDE_EFFECTS) at ../../gdb/eval.c:75 #10 0x080eb910 in evaluate_subexp_standard (expect_type=0x0, exp=0x11461640, pos=0x80473c4, noside=EVAL_AVOID_SIDE_EFFECTS) at ../../gdb/eval.c:1780 #11 0x080e9d16 in evaluate_subexp (expect_type=0x0, exp=0x0, pos=0x8046974, noside=EVAL_AVOID_SIDE_EFFECTS) at ../../gdb/eval.c:75 #12 0x080ebc70 in evaluate_subexp_standard (expect_type=0x0, exp=0x11461640, pos=0x8046974, noside=EVAL_NORMAL) at ../../gdb/eval.c:1706 #13 0x080e9d16 in evaluate_subexp (expect_type=0x0, exp=0x0, pos=0x8046974, noside=EVAL_NORMAL) at ../../gdb/eval.c:75 #14 0x080e9d41 in evaluate_expression (exp=0x11461640) at ../../gdb/eval.c:165 #15 0x080b8c1c in execute_control_command (cmd=0xa82f9e8) at ../../gdb/cli/cli-script.c:492 #16 0x080b8b67 in execute_control_command (cmd=0xa82f968) at ../../gdb/cli/cli-script.c:445 #17 0x080b8f78 in execute_user_command (c=0x1b276ed0, args=0x0) at ../../gdb/cli/cli-script.c:310 #18 0x08089ecc in execute_command (p=0x831272f "", from_tty=1) at ../../gdb/top.c:441 #19 0x081201c9 in command_handler (command=0x8312728 "pystack") at ../../gdb/event-top.c:518 #20 0x08120e2a in command_line_handler (rl=0x196a9568 "pystack") at ../../gdb/event-top.c:804 #21 0x081c95ee in rl_callback_read_char () at ../../readline/callback.c:205 #22 0x0812035b in rl_callback_read_char_wrapper (client_data=0x0) at ../../gdb/event-top.c:177 #23 0x0811fdb7 in handle_file_event (event_file_desc=0) at ../../gdb/event-loop.c:728 #24 0x0811f229 in process_event () at ../../gdb/event-loop.c:341 #25 0x0811fac0 in gdb_do_one_event (data=0x0) at ../../gdb/event-loop.c:378 #26 0x0811ccc3 in catch_errors (func=0x811f920 , func_args=0x0, errstring=0x8289a91 "", mask=6) at ../../gdb/exceptions.c:513 #27 0x080c81a5 in tui_command_loop (data=0x0) at ../../gdb/tui/tui-interp.c:152 #28 0x0811d28f in current_interp_command_loop () at ../../gdb/interps.c:276 #29 0x0808460b in captured_command_loop (data=0x0) at ../../gdb/main.c:99 #30 0x0811ccc3 in catch_errors (func=0x8084600 , ---Type to continue, or q to quit--- func_args=0x0, errstring=0x82833f8 "", mask=6) at ../../gdb/exceptions.c:513 #31 0x08083ea6 in captured_main (data=0x80479a4) at ../../gdb/main.c:870 #32 0x0811ccc3 in catch_errors (func=0x8083740 , func_args=0x80479a4, errstring=0x82833f8 "", mask=6) at ../../gdb/exceptions.c:513 #33 0x08083711 in gdb_main (args=0x80479a4) at ../../gdb/main.c:879 #34 0x080836d5 in main (argc=-18993666, argv=0x1) at ../../gdb/gdb.c:33 >How-To-Repeat: * Run Python from gdb. * At the interpreter prompt execute import os os.abort() * At the resulting gdb prompt define the pystack command above and execute it. Executing the above user-defined command seems to reliably crash gdb for me on Solaris 10. I tried this same command on my Mac (Leopard, gdb 6.3.50-20050815) and it worked as expected. Unfortunately, I don't have a newer version of gdb on my Mac or any older versions of gdb on Solaris to test whether it seems to be version-related or platform-related. >Fix: >Release-Note: >Audit-Trail: >Unformatted: