msp430-gdb segmentation fault with target remote

Can you run msp430-gdb itself under control of (the host) GDB, and provide a stack backtrace at the point of crash?

How exactly was your msp430-gdb configured and built? Do you have instructions how to reproduce the overall setup?

Hi guys. If this is MSP430 specific then could you bounce this bug up into the GDB bugzilla? Linaro don't directly work on the MSP430 range.

The same here on Ubuntu 11.10 (mspdebug and msp430-gdb from distribution package repository)

$ sudo mspdebug rf2500 "gdb"
MSPDebug version 0.16 - debugging tool for MSP430 MCUs
[...]
Bound to port 2000. Now waiting for connection...
Client connected from 127.0.0.1:40729
Clearing all breakpoints...
-----

$ gdb msp430-gdb
[...]
GNU gdb (Linaro GDB) 7.3
[...]
(gdb) target remote localhost:2000
Remote debugging using localhost:2000

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x08062bce in ?? ()
#2 0x0805f807 in ?? ()
#3 0x081237aa in ?? ()
#4 0x0812422c in ?? ()
#5 0x0812a12f in ?? ()
#6 0x08123503 in ?? ()
#7 0x08118c00 in ?? ()
#8 0x0807ac91 in ?? ()
#9 0x08129ef5 in ?? ()
#10 0x0806ff40 in ?? ()
#11 0x080564eb in ?? ()
#12 0x08130009 in ?? ()
#13 0x08130a83 in ?? ()
#14 0x0820c8cc in ?? ()
#15 0x08130078 in ?? ()
#16 0x0812f19b in ?? ()
#17 0x0812f31b in ?? ()
#18 0x0812f775 in ?? ()
#19 0x0812a12f in ?? ()
#20 0x080a957c in ?? ()
#21 0x0812a713 in ?? ()
#22 0x0804d4a8 in ?? ()
#23 0x0812a12f in ?? ()
#24 0x0804e35c in ?? ()
#25 0x0812a12f in ?? ()
#26 0x0804e6e0 in ?? ()
#27 0x0804d343 in ?? ()
#28 0x001f4113 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#29 0x0804d369 in ?? ()
Backtrace stopped: Not enough registers or memory available to unwind further
(gdb)

(tested with MSP430 LaunchPad (MSP-EXP430G2), http://processors.wiki.ti.com/index.php/MSP430_LaunchPad_%28MSP-EXP430G2%29)

More useful callstack:
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x08061dec in frame_unwind_find_by_frame (this_frame=0x845ccc8, this_cache=0x845ccd4) at frame-unwind.c:113
#2 0x08061200 in get_frame_type (frame=0x845ccc8) at frame.c:2199
#3 0x08132a44 in print_frame_info (frame=0x845ccc8, print_level=0, print_what=SRC_AND_LOC, print_args=1) at stack.c:539
#4 0x0813211d in print_stack_frame_stub (args=0xbfffe5d0) at stack.c:101
#5 0x081394e3 in catch_errors (func=0x81320c0 <print_stack_frame_stub>, func_args=0xbfffe5d0, errstring=0x830cf70 "", mask=2) at exceptions.c:521
#6 0x08132298 in print_stack_frame (frame=0x845ccc8, print_level=0, print_what=SRC_AND_LOC) at stack.c:149
#7 0x0812c875 in normal_stop () at infrun.c:5825
#8 0x081266bc in start_remote (from_tty=1) at infrun.c:2246
#9 0x08073442 in remote_start_remote (uiout=0x846d0c8, opaque=0xbfffe820) at remote.c:3279
#10 0x0813932b in catch_exception (uiout=0x846d0c8, func=0x8072fa0 <remote_start_remote>, func_args=0xbfffe820, mask=6) at exceptions.c:471
#11 0x08074490 in remote_open_1 (name=0x84208d6 "localhost:2000", from_tty=1, target=0x83d5cc0, extended_p=0) at remote.c:4055
#12 0x080736fc in remote_open (name=0x84208d6 "localhost:2000", from_tty=1) at remote.c:3390
#13 0x08096d17 in do_cfunc (c=0x84313f0, args=0x84208d6 "localhost:2000", from_tty=1) at ./cli/cli-decode.c:67
#14 0x08099692 in cmd_func (cmd=0x84313f0, args=0x84208d6 "localhost:2000", from_tty=1) at ./cli/cli-decode.c:1777
#15 0x080557f6 in execute_command (p=0x84208e3 "0", from_tty=1) at top.c:428
#16 0x081405d1 in command_handler (command=0x84208c8 "") at event-top.c:499
#17 0x08140ba0 in command_line_handler (rl=0x846ef50 "target remote localhost:2000") at event-top.c:704
#18 0x08240ef8 in rl_callback_read_char () at callback.c:205
#19 0x0813fc63 in rl_callback_read_char_wrapper (client_data=0x0) at event-top.c:177
#20 0x081404c9 in stdin_event_handler (error=0, client_data=0x0) at event-top.c:434
#21 0x0813f0a8 in handle_file_event (data=...) at event-loop.c:831
#22 0x0813e7f5 in process_event () at event-loop.c:402
#23 0x0813e893 in gdb_do_one_event (data=0x0) at event-loop.c:455
#24 0x081394e3 in catch_errors (func=0x813e803 <gdb_do_one_event>, func_args=0x0, errstring=0x82e5cab "", mask=6) at exceptions.c:521
#25 0x080ae246 in tui_command_loop (data=0x0) at ./tui/tui-interp.c:172
#26 0x08139bce in current_interp_command_loop () at interps.c:291
#27 0x0804c322 in captured_command_loop (data=0x0) at ./main.c:228
#28 0x081394e3 in catch_errors (func=0x804c317 <captured_command_loop>, func_args=0x0, errstring=0x82cd1f9 "", mask=6) at exceptions.c:521
#29 0x0804d21d in captured_main (data=0xbfffed10) at ./main.c:936
#30 0x081394e3 in catch_errors (func=0x804c358 <captured_main>, func_args=0xbfffed10, errstring=0x82cd1f9 "", mask=6) at exceptions.c:521
#31 0x0804d253 in gdb_main (args=0xbfffed10) at ./main.c:945
#32 0x0804c0a6 in main (argc=1, argv=0xbfffedc4) at gdb.c:35

Fails in:
|111 TRY_CATCH (ex, RETURN_MASK_ERROR)
|112 {
>|113 res = entry->unwinder->sniffer (entry->unwinder, this_frame,
|114 this_cache);
|115 }

(gdb) p *entry->unwinder
$7 = {type = NORMAL_FRAME, stop_reason = 0x806baeb <msp430_epilogue_frame_this_id>, this_id = 0x806c7db <msp430_frame_prev_register>, prev_register = 0, unwind_data = 0x806c814, sniffer = 0, dealloc_cache = 0,
  prev_arch = 0}

sniffer is NULL, but what is it and where is it coming from?

In order to install gdb to debug msp430 I encountered some conflicts between gdb and gdb-msp430:

sudo dpkg -i --force-overwrite gdb_7.3-0ubuntu2_i386.deb
(Reading database ... 184431 files and directories currently installed.)
Unpacking gdb (from gdb_7.3-0ubuntu2_i386.deb) ...
dpkg: warning: overriding problem because --force enabled:
 trying to overwrite '/usr/share/gdb/python/gdb/__init__.py', which is also in package gdb-msp430 7.2~mspgcc-7.2-20110612-1ubuntu1
dpkg: warning: overriding problem because --force enabled:
 trying to overwrite '/usr/share/gdb/python/gdb/types.py', which is also in package gdb-msp430 7.2~mspgcc-7.2-20110612-1ubuntu1
dpkg: warning: overriding problem because --force enabled:
 trying to overwrite '/usr/share/gdb/python/gdb/printing.py', which is also in package gdb-msp430 7.2~mspgcc-7.2-20110612-1ubuntu1
dpkg: warning: overriding problem because --force enabled:
 trying to overwrite '/usr/share/gdb/python/gdb/command/__init__.py', which is also in package gdb-msp430 7.2~mspgcc-7.2-20110612-1ubuntu1
dpkg: warning: overriding problem because --force enabled:
 trying to overwrite '/usr/share/gdb/python/gdb/command/pretty_printers.py', which is also in package gdb-msp430 7.2~mspgcc-7.2-20110612-1ubuntu1
Setting up gdb (7.3-0ubuntu2) ...
Processing triggers for man-db ...

For now, gdb reports "no debugging symbols found" in the case of msp430-gdb which probably means I ought to recompile the package with -g. I suppose that this is what Andrzej Bieniek did to produce the stack trace above.

Okay, right after following the directions here (https://wiki.ubuntu.com/DebuggingProgramCrash), I reproduced the same stack trace reported by Andrzej Bieniek:

(gdb) target remote localhost:2000
Remote debugging using localhost:2000

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x08062bce in frame_unwind_find_by_frame (this_frame=0x83fa090,
    this_cache=0x83fa09c) at frame-unwind.c:113
#2 0x0805f807 in get_frame_type (frame=0x83fa090) at frame.c:2199
#3 0x081237aa in print_frame_info (frame=0x83fa090, print_level=0,
    print_what=SRC_AND_LOC, print_args=1) at stack.c:539
#4 0x0812422c in print_stack_frame_stub (args=0xbfffecb0) at stack.c:101
#5 0x0812a12f in catch_errors (func=0x81241f0 <print_stack_frame_stub>,
    func_args=0xbfffecb0, errstring=0x82868e1 "", mask=2) at exceptions.c:521
#6 0x08123503 in print_stack_frame (frame=0x83fa090, print_level=0,
    print_what=SRC_AND_LOC) at stack.c:149
#7 0x08118c00 in normal_stop () at infrun.c:5825
#8 0x0807ac91 in remote_start_remote (uiout=0x8409db0, opaque=0xbfffeef4)
    at remote.c:3279
#9 0x08129ef5 in catch_exception (uiout=0x8409db0,
    func=0x807a720 <remote_start_remote>, func_args=0xbfffeef4, mask=6)
    at exceptions.c:471
#10 0x0806ff40 in remote_open_1 (name=<optimized out>, from_tty=1,
    target=0x83781e0, extended_p=0) at remote.c:4055
#11 0x080564eb in execute_command (p=0x83c18e3 "0", from_tty=1) at top.c:428
#12 0x08130009 in command_handler (command=0x83c18c8 "") at event-top.c:499
#13 0x08130a83 in command_line_handler (
    rl=0x840baf0 "target remote localhost:2000") at event-top.c:704
#14 0x0820c8cc in rl_callback_read_char () at callback.c:205
#15 0x08130078 in rl_callback_read_char_wrapper (client_data=0x0)
    at event-top.c:177
#16 0x0812f19b in handle_file_event (data=...) at event-loop.c:831
#17 0x0812f31b in process_event () at event-loop.c:402
#18 process_event () at event-loop.c:352
#19 0x0812f775 in gdb_do_one_event (data=<optimized out>) at event-loop.c:467
#20 gdb_do_one_event (data=0x0) at event-loop.c:417
#21 0x0812a12f in catch_errors (func=0x812f660 <gdb_do_one_event>,
    func_args=0x0, errstring=0x82868e1 "", mask=6) at exceptions.c:521
#22 0x080a957c in tui_command_loop (data=0x0) at ./tui/tui-interp.c:172
#23 0x0812a713 in current_interp_command_loop () at interps.c:291
#24 0x0804d4a8 in captured_command_loop (data=0x0) at ./main.c:228
#25 0x0812a12f in catch_errors (func=0x804d4a0 <captured_command_loop>,
    func_args=0x0, errstring=0x82868e1 "", mask=6) at exceptions.c:521
#26 0x0804e35c in captured_main (data=0xbffff2c0) at ./main.c:936
#27 0x0812a12f in catch_errors (func=0x804d610 <captured_main>,
    func_args=0xbffff2c0, errstring=0x82868e1 "", mask=6) at exceptions.c:521
#28 0x0804e6e0 in gdb_main (args=0xbffff2c0) at ./main.c:945
#29 0x0804d343 in main (argc=1, argv=0xbffff374) at gdb.c:35

>(gdb) p *entry->unwinder
>$7 = {type = NORMAL_FRAME, stop_reason = 0x806baeb <msp430_epilogue_frame_this_id>, this_id = 0x806c7db ><msp430_frame_prev_register>, prev_register = 0, unwind_data = 0x806c814, sniffer = 0, dealloc_cache = 0,
> prev_arch = 0}
>
>sniffer is NULL, but what is it and where is it coming from?

It seems this is some out-of-tree patch? In any case, "struct frame_unwind" earlier this year gained a new member "stop_reason"; it seems that the msp430 code has a struct initializer that was not updated to take that into account (the "this_id" routine is in the stop_reason field, the "prev_register" routine is in the this_id field etc.)

I guess you need to insert "default_frame_unwind_stop_reason" (or some appropriate stop_reason routine) into that initializer at the appropriate place.

Thanks Carson, Ulrich.

>>It seems this is some out-of-tree patch?
afaik it is mspgcc branch

Ubuntu provides gdb 7.3. Yes, Ulrich you are right with new a member.
If package is build with ftp://ftp.gnu.org/pub/gnu/gdb/gdb-7.2a.tar.bz2, it doesn't crash :)

msp430-gdb
GNU gdb (GDB) 7.2
[...]
(gdb) target remote localhost:2000
Remote debugging using localhost:2000
0x0000ffff in ?? ()
(gdb) bt
#0 0x0000ffff in ?? ()
(gdb)

Since this is an out-of-tree patch that simply hasn't been updated for a common code change, it is not a Linaro GDB problem. Setting the "Linaro GDB" part of the bug to Invalid.

Add patch that updates gdb-mscp (version 7.2~mspgcc-7.2-20110612-1ubuntu1) to gdb 7.3.
It needs to be applied after msp430-gdb-7.2-20110103.patch

Briefly tested, seems to work ok.

The attachment "msp430-gdb-7.3-fix-segfault.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Status changed to 'Confirmed' because the bug affects multiple users.

Andrzej , thanks for the patch. Seems to work for me
Steve

As this hasn't made it into the repos I tried applying the patch and rebuilding, however it runs into a failed hunk when patching sim/configure and I can't see what is wrong with it. Trying a simple rebuild of the source for gdb-msp430 also fails though without any patching so I suspect I am missing something ... is there a building dependency with gcc-msp430 and/or binutils ???

Any pointers to a less terse description of fixing this bug ? ... thanks.