This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

arm-none-eabi-gdb hangs when printing address of array element


Hello,
I try to work with gdb and openocd to develop software for a STM32 micro controller. I need some help / tipps because the debugger hangs very often. The C++ sources are compiled with -ggdb (but using just -g makes no difference) and -O0.

Iâve narrowed it down to a situation, where I have a brake point and when I reach the brake point a second time and try to print the address of the second byte from an array, the gdb hangs. If reach the bp the first time, I issue following commands:

(gdb) p (void*)this
$1 = (void *) 0x20013eec
(gdb) p &receive_buffer_
$2 = (unsigned char (*)[255]) 0x20013eec
(gdb) p &receive_buffer_[1]
$3 = (unsigned char *) 0x20013eed â\377\003\001â

when I reach the bp a second time, I issue the same commands:

(gdb) p (void*)this
$4 = (void *) 0x20013eec
(gdb) p &receive_buffer_
$5 = (unsigned char (*)[255]) 0x20013eec
(gdb) p &receive_buffer_[1]

GDB hangs and does not respond to ctrl-c. When I reach the bp the second time, I can `p receive_buffer_` without hanging the gdb:

(gdb) p receive_buffer_
$2 = "\004\016\004\001\f\374\000\353\200\000\000\000\376\377\357\277\000T\002\242\256\376sZ\000\002\006@\335\375\277\367\002\b \240_\277\257\357\060\002\000\002\377\376n\277\022\200\000\203\b\177\261\377(A\000\020\377]\377\367 \222\005\004\377\373\377\373 \200 :\337\353\377\372\000\f\020!\274\352\327n\000\000\b\000\365\177\346\277\000\000\000\b\377\277S\247@\000\200\004{\357\177?\000\000D\021\253\251\277\307\024\bD\n\366?\337Ï\000\002\020\377\277?\372\204\001\000\207\373\373\277\375\004\200\062\021\337\374\356D\000 @\000o\277\357\377\b\f \020\377\345;\337\000\000\200\b\337\237_\316\000\030\b\203o \177\253\t$\200\020\204\000\000 \000\000\004\030\264?\001 \001\000"...
(gdb) p receive_buffer_[1]
$3 = 14 '\016'
(gdb) p &receive_buffer_[1]

The gdb seems to be in an infinite loop. When I attach lldb on OS/X, I get the following: backtrack

(lldb) process attach --pid 62987
Process 62987 stopped
Executable module set to "/Users/todi/gdb-7.9/build/gdb/gdb".
Architecture set to: x86_64-apple-macosx.
(lldb) bt
* thread #1: tid = 0x4b7f62, 0x00007fff9015dc87 libiconv.2.dylib`wchar_to_loop_convert + 129, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff9015dc87 libiconv.2.dylib`wchar_to_loop_convert + 129
    frame #1: 0x00000001000dcd8e gdb`wchar_iterate [inlined] gdb_iconv(utf_flag=<unavailable>, inbuf=0x0000000101a04736, inbytesleft=0x0000000100916130, outbuf=0x0000000100907634, outbytesleft=0x0000000000000000) + 8 at charset.c:193
    frame #2: 0x00000001000dcd86 gdb`wchar_iterate(iter=0x0000000100916120, out_result=0x00007fff5fbfebb4, out_chars=0x00007fff5fbfeba0, ptr=0x00007fff5fbfebf8, len=0x00007fff5fbfec00) + 118 at charset.c:656
    frame #3: 0x00000001000fe496 gdb`generic_printstr [inlined] count_next_character(iter=<unavailable>, vec=0x00000001009e0bf0) + 363 at valprint.c:2156
    frame #4: 0x00000001000fe32b gdb`generic_printstr(stream=0x00000001009deb20, type=<unavailable>, string=<unavailable>, length=<unavailable>, encoding=<unavailable>, force_ellipses=0, quote_char=<unavailable>, c_style_terminator=<unavailable>, options=<unavailable>) + 379 at valprint.c:2420
    frame #5: 0x00000001001f24dc gdb`c_printstr(stream=0x00000001009deb20, type=0x0000000102806fc0, string=0x0000000101a04730, length=9, user_encoding=<unavailable>, force_ellipses=0, options=<unavailable>) + 172 at c-lang.c:217
    frame #6: 0x00000001000ff0d2 gdb`val_print_string(elttype=0x0000000102806fc0, encoding=0x0000000000000000, addr=536952566, len=<unavailable>, stream=0x00000001009deb20, options=0x00007fff5fbfeec8) + 434 at valprint.c:2544
    frame #7: 0x0000000100216b5d gdb`c_val_print(type=<unavailable>, valaddr=<unavailable>, embedded_offset=<unavailable>, address=<unavailable>, stream=0x0000000102806fc0, recurse=<unavailable>, original_value=<unavailable>, options=0x00007fff5fbfeec8) + 1469 at c-valprint.c:303
    frame #8: 0x00000001000fc8bf gdb`val_print(type=0x00000001028aaf08, valaddr=0x0000000101a04720, embedded_offset=0, address=0, stream=0x00000001009deb20, recurse=0, val=0x0000000101a05c80, options=<unavailable>, language=0x0000000100438f90) + 527 at valprint.c:787
    frame #9: 0x00000001002172e4 gdb`c_value_print(val=<unavailable>, stream=<unavailable>, options=<unavailable>) + 980 at c-valprint.c:584
    frame #10: 0x0000000100103f64 gdb`print_command_1(exp=<unavailable>, voidprint=<unavailable>) + 612 at printcmd.c:994
    frame #11: 0x0000000100223b79 gdb`execute_command(p=<unavailable>, from_tty=<unavailable>) + 457 at top.c:476
    frame #12: 0x000000010014bd52 gdb`command_handler(command=0x00000001009073d0) + 146 at event-top.c:494
    frame #13: 0x000000010014bc87 gdb`command_line_handler(rl=<unavailable>) + 1095 at event-top.c:698
    frame #14: 0x00000001002a4dcd gdb`rl_callback_read_char + 477 at callback.c:220
    frame #15: 0x000000010014b829 gdb`rl_callback_read_char_wrapper(client_data=<unavailable>) + 9 at event-top.c:171
    frame #16: 0x000000010014b16c gdb`stdin_event_handler(error=<unavailable>, client_data=0x0000000000000000) + 140 at event-top.c:432
    frame #17: 0x000000010014a370 gdb`gdb_wait_for_event(block=<unavailable>) + 720 at event-loop.c:801
    frame #18: 0x000000010014a01b gdb`gdb_do_one_event + 427 at event-loop.c:309
    frame #19: 0x000000010014a405 gdb`start_event_loop + 117 at event-loop.c:334
    frame #20: 0x0000000100145136 gdb`captured_command_loop(data=<unavailable>) + 22 at main.c:321
    frame #21: 0x0000000100140335 gdb`catch_errors(func=0x0000000100145120, func_args=0x0000000000000000, errstring=0x0000000100368c50, mask=RETURN_MASK_ALL) + 85 at exceptions.c:237
    frame #22: 0x0000000100144a02 gdb`captured_main(data=<unavailable>) + 3810 at main.c:1149
    frame #23: 0x0000000100140335 gdb`catch_errors(func=0x0000000100143b20, func_args=0x00007fff5fbff4c0, errstring=0x0000000100368c50, mask=RETURN_MASK_ALL) + 85 at exceptions.c:237
    frame #24: 0x0000000100143b12 gdb`gdb_main(args=<unavailable>) + 34 at main.c:1157


The versions of gdb Iâve tried are 7.6 and 7.9 and configured like this:

This GDB was configured as "--host=x86_64-apple-darwin13.4.0 --target=arm-none-eabi".

Obviously, I have no clue on what I could do to solve my problem. Do you have an idea how I could solve that issue? The issue sounds very constructed and bizarre, but while debugging normally, this endless loop comes up very quickly.

kind regards,
Torsten

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]