gdb/2450: gdb core dump in user-defined stack print command

gdb/2450: gdb core dump in user-defined stack print command

[skip]

>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=<value optimized out>,
    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 <gdb_do_one_event>,
    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 <captured_command_loop>,
---Type <return> to continue, or q <return> 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 <captured_main>,
    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:

Re: gdb/2450: gdb core dump in user-defined stack print command

[Daniel Jacobowitz]

The following reply was made to PR gdb/2450; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: skip@pobox.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2450: gdb core dump in user-defined stack print command
Date: Fri, 2 May 2008 12:39:06 -0400

 On Fri, May 02, 2008 at 01:17:16PM -0000, skip@pobox.com wrote:
 > 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=<value optimized out>,
 >     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
 
 If this still happens in GDB 6.8, could you try "set debug expression
 1" first?
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

Re: gdb/2450: gdb core dump in user-defined stack print command

[Skip Montanaro]

The following reply was made to PR gdb/2450; it has been noted by GNATS.

From: Skip Montanaro <skipm@trdlnk.com>
To: gdb-gnats@sources.redhat.com, gdb-prs@sources.redhat.com
Cc:  
Subject: Re: gdb/2450: gdb core dump in user-defined stack print command
Date: Fri, 02 May 2008 11:20:18 -0500

 http://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=2450
 
 A colleague at work built gdb 6.8 and said it stopped the crash/core dump
 for him.  We still have to confirm that there are no significant differences
 between the way 6.7 and 6.8 were built, but we'll check into that and see if
 we can confirm that 6.8 truly solves the problem.
 
 Skip