Hello, I'm debugging remote program with eclipse and gdb. when i move my mouse pointer on an const string like "hello world"(some thing like char a[]="hello world"), then gdb crashed. the gdb i used is compiler by myself. here is the version infomation: C:\Users\Administrator>arm-sylixos-eabi-gdb --version GNU gdb (SylixOS Toolchain for ARM Embedded Processors) 7.8.0.20150304-cvs Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-w64-mingw32 --target=arm-sylixos-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". gdb error is: /home/user/toolchain/gcc-arm-sylixos-eabi-4_9-2015q2-20150411/src/gdb/gdb/infrun.c:6229: internal-error: normal_stop: Assertion `get_frame_type (frame) == DUMMY_FRAME' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] /home/user/toolchain/gcc-arm-sylixos-eabi-4_9-2015q2-20150411/src/gdb/gdb/infrun.c:6229: internal-error: normal_stop: Assertion `get_frame_type (frame) == DUMMY_FRAME' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. I open the remote debug log, it output: Sending packet: $Pe=748201c0#bb...Ack Packet received: Packet P (set-register) is NOT supported Sending packet: $G0100000014706b24707908c0748201c0a84f03c0c0e0d62050a702c010736b240100000058e1d62048736b2464e0d620e44f03c058e0d620748201c0888201c053000020#cc...Ack Packet received: OK Sending packet: $G0e00000014706b24707908c0748201c0a84f03c0c0e0d62050a702c010736b240100000058e1d62048736b2464e0d620e44f03c058e0d620748201c0888201c053000020#00...Ack Packet received: OK Sending packet: $G0e00000014706b24707908c0748201c0a84f03c0c0e0d62050a702c010736b240100000058e1d62048736b2464e0d620e44f03c050e0d620748201c0888201c053000020#f8...Ack Packet received: OK Sending packet: $G0e00000014706b24707908c0748201c0a84f03c0c0e0d62050a702c010736b240100000058e1d62048736b2464e0d620e44f03c050e0d620748201c050bc02c053000020#49...Ack Packet received: OK Sending packet: $Z0,c0018274,4#df...Ack Packet received: OK Sending packet: $vCont;c#a8...Ack Packet received: T05thread:4010023; Sending packet: $g#67...Ack Packet received: 787a08c00e000000008008c0787a08c0a84f03c0c0e0d62050a702c010736b240100000058e1d62048736b2464e0d6200400000058e0d620748201c0748201c053000020 Sending packet: $mc0018274,4#96...Ack Packet received: fedeffe7 Sending packet: $z0,c0018274,4#ff...Ack Packet received: This is a bug, please report it. For instructions, see: <http://www.gnu.org/software/gdb/bugs/>. /home/user/toolchain/gcc-arm-sylixos-eabi-4_9-2015q2-20150411/src/gdb/gdb/infrun.c:6229: internal-error: normal_stop: Assertion `get_frame_type (frame) == DUMMY_FRAME' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] /home/user/toolchain/gcc-arm-sylixos-eabi-4_9-2015q2-20150411/src/gdb/gdb/infrun.c:6229: internal-error: normal_stop: Assertion `get_frame_type (frame) == DUMMY_FRAME' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. I
On 04/17/2015 01:24 PM, 305128674 at qq dot com wrote: > > the gdb i used is compiler by myself. here is the version infomation: I believe this has been fixed in more recent versions of gdb. > C:\Users\Administrator>arm-sylixos-eabi-gdb --version > GNU gdb (SylixOS Toolchain for ARM Embedded Processors) 7.8.0.20150304-cvs Could you try the 7.9 branch, and/or master? > Copyright (C) 2014 Free Software Foundation, Inc.
(In reply to Pedro Alves from comment #1) > On 04/17/2015 01:24 PM, 305128674 at qq dot com wrote: > > > > the gdb i used is compiler by myself. here is the version infomation: > > I believe this has been fixed in more recent versions of gdb. > > > C:\Users\Administrator>arm-sylixos-eabi-gdb --version > > GNU gdb (SylixOS Toolchain for ARM Embedded Processors) 7.8.0.20150304-cvs > > Could you try the 7.9 branch, and/or master? > > > Copyright (C) 2014 Free Software Foundation, Inc. I tried the gdb verions 7.9, the bug remain。 gdb still crashed。 the new version information is: D:\qtcreator-gdb-7.9-mingw32_nt-6.1-i686>gdb-arm-sylixosqt-eabi.exe --version Python Exception <type 'exceptions.ImportError'> No module named gdb: D:\qtcreator-gdb-7.9-mingw32_nt-6.1-i686\gdb-arm-sylixosqt-eabi.exe: warning: Could not load the Python gdb module from `d:\usr\local\share\gdb/python'. Limited Python support is available from the _gdb module. Suggest passing --data-directory=/path/to/gdb/data-directory. GNU gdb (GDB) 7.9 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-pc-mingw32 --target=arm-sylixosqt-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word".
OK, thanks. In order to understand what's going on, we'll need: - "set debug infrun 1 + set debug remote 1" logs (both enabled at the same time). - ideally, get eclipse out of the equation, and to reproduce this with gdb alone. Enable Eclipse gdb logging, to find the MI traffic between Eclipse and gdb.
(In reply to Pedro Alves from comment #3) > OK, thanks. > > In order to understand what's going on, we'll need: > > - "set debug infrun 1 + set debug remote 1" logs (both enabled at the same > time). > > - ideally, get eclipse out of the equation, and to reproduce this with gdb > alone. Enable Eclipse gdb logging, to find the MI traffic between Eclipse > and gdb. Thanks for your help I enable "set debug infrun 1 + set debug remote 1" when gdb start and catch the logs. it's diffrent from what i used catched。 I cann't andstand the rsp command "P, G, cont:c",why gdb send this when my mouse move to a const string. the gdbstub is write by my self, some command is not implemented, such as "P". Is this the problem? here is the log(I have clear logs before my mouse move to the const string, so this is the logs relate to the problem): Sending packet: $Pe=748200c0#ba...Ack Packet received: Packet P (set-register) is NOT supported Sending packet: $G010000002cce6d2460390fc0748200c0384e02c00505050506060606070707070808080809090909101010100455d720744e02c0f854d720748200c0888200c053000020#58...Ack Packet received: OK Sending packet: $G0e0000002cce6d2460390fc0748200c0384e02c00505050506060606070707070808080809090909101010100455d720744e02c0f854d720748200c0888200c053000020#8c...Ack Packet received: OK Sending packet: $G0e0000002cce6d2460390fc0748200c0384e02c00505050506060606070707070808080809090909101010100455d720744e02c0f054d720748200c0888200c053000020#84...Ack Packet received: OK infrun: clear_proceed_status_thread (Thread 67174450) Sending packet: $G0e0000002cce6d2460390fc0748200c0384e02c00505050506060606070707070808080809090909101010100455d720744e02c0f054d720748200c088ba01c053000020#de...Ack Packet received: OK infrun: proceed (addr=0xc001ba88, signal=GDB_SIGNAL_0, step=0) Sending packet: $Z0,c0008274,4#de...Ack Packet received: OK infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 67174450] at 0xc001ba88 Sending packet: $vCont;c#a8...Ack infrun: wait_for_inferior () Packet received: T05thread:4010032; infrun: target_wait (-1, status) = infrun: 42000 [Thread 67174450], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED Sending packet: $g#67...Ack Packet received: 683a0fc00e00000000400fc0683a0fc0384e02c00505050506060606070707070808080809090909101010100455d720704f02c0f854d72030ba01c0748200c053000020 infrun: stop_pc = 0xc0008274 Sending packet: $mc0008274,4#95...Ack Packet received: fedeffe7 infrun: BPSTAT_WHAT_STOP_SILENT infrun: stop_waiting Sending packet: $qfThreadInfo#bb...Ack Packet received: m4010032 Sending packet: $qsThreadInfo#c8...Ack Packet received: l Sending packet: $z0,c0008274,4#fe...Ack Packet received: d:/MinGW/msys/1.0/home/Administrator/staging/gdb-7.9/gdb/infrun.c:6577: internal-error: normal_stop: Assertion `get_frame_type (frame) == DUMMY_FRAME' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] This is a bug, please report it. For instructions, see: <http://www.gnu.org/software/gdb/bugs/>. This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. d:/MinGW/msys/1.0/home/Administrator/staging/gdb-7.9/gdb/infrun.c:6577: internal-error: normal_stop: Assertion `get_frame_type (frame) == DUMMY_FRAME' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) [answered Y; input not from terminal] Follw is eclipse gdb trace output: 988,254 39-data-evaluate-expression --thread 1 --frame 0 "\"Hello World!\\n\"" 988,270 39^done,value="\"Hello World!\\n\"" 988,270 (gdb) 988,317 40-var-create --thread 1 --frame 0 - * "\"Hello World!\\n\"" 988,332 40^done,name="var3",numchild="14",value="[14]",type="char [14]",has_more="0" 988,332 (gdb) 988,332 41-var-create --thread 1 --frame 0 - * "&(\"Hello World!\\n\")" 988,348 42-var-create --thread 1 --frame 0 - * "\"Hello World!\\n\"[0]" 988,348 43-var-create --thread 1 --frame 0 - * "\"Hello World!\\n\"[1]" 988,348 44-var-create --thread 1 --frame 0 - * "\"Hello World!\\n\"[2]" 988,348 &"Sending packet: $Pe=748200c0#ba..." 988,348 &"Ack\n" 988,348 &"Packet received: \n" 988,348 &"Packet P (set-register) is NOT supported\n" 988,348 &"Sending packet: $G010000002cce6d2460390fc0748200c0384e02c005050505060606060707070708080808\ 09090909101010100455d720744e02c0f854d720748200c0888200c053000020#58..." 988,348 &"Ack\n" 988,348 &"Packet received: OK\n" 988,348 &"Sending packet: $G0e0000002cce6d2460390fc0748200c0384e02c005050505060606060707070708080808\ 09090909101010100455d720744e02c0f854d720748200c0888200c053000020#8c..." 988,348 &"Ack\n" 988,348 &"Packet received: OK\n" 988,348 &"Sending packet: $G0e0000002cce6d2460390fc0748200c0384e02c005050505060606060707070708080808\ 09090909101010100455d720744e02c0f054d720748200c0888200c053000020#84..." 988,348 &"Ack\n" 988,348 &"Packet received: OK\n" 988,348 &"infrun: clear_proceed_status_thread (Thread 67174450)\n" 988,348 &"Sending packet: $G0e0000002cce6d2460390fc0748200c0384e02c005050505060606060707070708080808\ 09090909101010100455d720744e02c0f054d720748200c088ba01c053000020#de..." 988,348 &"Ack\n" 988,348 &"Packet received: OK\n" 988,348 &"infrun: proceed (addr=0xc001ba88, signal=GDB_SIGNAL_0, step=0)\n" 988,348 &"Sending packet: $Z0,c0008274,4#de..." 988,348 &"Ack\n" 988,348 &"Packet received: OK\n" 988,348 &"infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 6717\ 4450] at 0xc001ba88\n" 988,348 &"Sending packet: $vCont;c#a8..." 988,363 &"Ack\n" 988,363 &"infrun: wait_for_inferior ()\n" 988,363 &"Packet received: T05thread:4010032;\n" 988,363 &"infrun: target_wait (-1, status) =\ninfrun: 42000 [Thread 67174450],\ninfrun: status->\ kind = stopped, signal = GDB_SIGNAL_TRAP\n" 988,363 &"infrun: TARGET_WAITKIND_STOPPED\n" 988,363 &"Sending packet: $g#67..." 988,363 &"Ack\n" 988,363 &"Packet received: 683a0fc00e00000000400fc0683a0fc0384e02c0050505050606060607070707080808080\ 9090909101010100455d720704f02c0f854d72030ba01c0748200c053000020\n" 988,363 &"infrun: stop_pc = 0xc0008274\n" 988,363 &"Sending packet: $mc0008274,4#95..." 988,363 &"Ack\n" 988,363 &"Packet received: fedeffe7\n" 988,363 &"infrun: BPSTAT_WHAT_STOP_SILENT\n" 988,363 &"infrun: stop_waiting\n" 988,363 &"Sending packet: $qfThreadInfo#bb..." 988,363 &"Ack\n" 988,363 &"Packet received: m4010032\n" 988,363 &"Sending packet: $qsThreadInfo#c8..." 988,363 &"Ack\n" 988,363 &"Packet received: l\n" 988,363 &"Sending packet: $z0,c0008274,4#fe..." 988,363 &"Ack\n" 988,363 &"Packet received: \n" 988,363 ~"d:/MinGW/msys/1.0/home/Administrator/staging/gdb-7.9/gdb/infrun.c:6577: internal-error: no\ rmal_stop: Assertion `get_frame_type (frame) == DUMMY_FRAME' failed.\nA problem internal to GDB has \ been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? " 988,363 ~"(y or n) [answered Y; input not from terminal]\n" 988,363 &"\nThis is a bug, please report it." 988,363 &" For instructions, see:\n<http://www.gnu.org/software/gdb/bugs/>." 988,363 &"\n\n" 988,363 ~"d:/MinGW/msys/1.0/home/Administrator/staging/gdb-7.9/gdb/infrun.c:6577: internal-error: no\ rmal_stop: Assertion `get_frame_type (frame) == DUMMY_FRAME' failed.\nA problem internal to GDB has \ been detected,\nfurther debugging may prove unreliable.\nCreate a core file of GDB? " 988,363 ~"(y or n) [answered Y; input not from terminal]\n"
> I cann't andstand the rsp command "P, G, cont:c",why gdb send this when my > mouse move to a const string. I suspect GDB is evaluating an expression that requires allocating memory in the inferior's address space for the const string in question, and thus GDB is calling "malloc" in the inferior. > the gdbstub is write by my self, some command is > not implemented, such as "P". Is this the problem? Not sure. > here is the log(I have clear logs before my mouse move to the const string, so > this is the logs relate to the problem): Thanks. I'm not seeing anything obviously wrong though. I think you'll need to debug gdb and try to figure out what is going wrong. I'd really try to cut Eclipse out of the equation. Likely you can reproduce this with the "print/call" commands.
(In reply to Pedro Alves from comment #5) > > I cann't andstand the rsp command "P, G, cont:c",why gdb send this when my > > mouse move to a const string. > > I suspect GDB is evaluating an expression that requires allocating memory > in the inferior's address space for the const string in question, and thus > GDB is calling "malloc" in the inferior. > > > the gdbstub is write by my self, some command is > > not implemented, such as "P". Is this the problem? > > Not sure. > > > here is the log(I have clear logs before my mouse move to the const string, so > > this is the logs relate to the problem): > > Thanks. I'm not seeing anything obviously wrong though. I think you'll > need to debug gdb and try to figure out what is going wrong. I'd > really try to cut Eclipse out of the equation. Likely you can > reproduce this with the "print/call" commands. ok, I will try to run gdb alone. but i don't kown what command to you use to simulate the mouse move to a const string. print is ok. i use --interpretor mi to send the same cmd as eclipse, it show error also.
> ok, I will try to run gdb alone. > but i don't kown what command to you use to simulate the mouse move to a const > string. > print is ok. > i use --interpretor mi to send the same cmd as eclipse, it show error also. I'd debug gdb, and put a breakpoint in call_function_by_hand. Then in the inferior gdb, issue the MI commands that trigger the bug. You'll probably find the backtrace shows value_allocate_space_in_inferior. I suspect that something around: (gdb) print "foo" + 1 triggers the issue too. I'd try explict inferior function calls too: (gdb) print foo() And there's the possibility that bug really is MI varobj specific too. I'd run gdb under valgrind as well, in case this is caused by gdb memory corruption.
(In reply to Pedro Alves from comment #7) > > ok, I will try to run gdb alone. > > but i don't kown what command to you use to simulate the mouse move to a const > > string. > > print is ok. > > i use --interpretor mi to send the same cmd as eclipse, it show error also. > > I'd debug gdb, and put a breakpoint in call_function_by_hand. Then in the > inferior gdb, issue the MI commands that trigger the bug. You'll probably > find the backtrace shows value_allocate_space_in_inferior. I suspect that > something around: > > (gdb) print "foo" + 1 > > triggers the issue too. I'd try explict inferior function calls too: > > (gdb) print foo() > > And there's the possibility that bug really is MI varobj specific too. > > I'd run gdb under valgrind as well, in case this is caused by gdb memory > corruption. So, do you have some idea to avoid this issue, or i need to wait for a newer gdb version? i need to use gdb with eclipse.
I have no idea how to avoid/workaround this issue. I gave suggestions for how to debug it, and zone in on the root issue. In order for someone else to debug it (other than you), we'd need get a minimal, self-contained and complete reproducer, that can be run without Eclipse. The sequence of commands used to trigger the bug can be based on MI commands. If we have that, and the bug can only be triggered against your stub, it may still be reproduciable with gdbreplay, if you give us a "set remotelogfile" log file. (See "Using GDBreplay" in gdb/gdbserver/README. Make sure to try yourself against gdbreplay before sending us the log.)
Created attachment 8268 [details] mi commant list
Created attachment 8269 [details] debug remote log file
Created attachment 8270 [details] cmd error out put
(In reply to Pedro Alves from comment #9) > I have no idea how to avoid/workaround this issue. I gave suggestions for > how to debug it, and zone in on the root issue. In order for someone else > to debug it (other than you), we'd need get a minimal, self-contained and > complete reproducer, that can be run without Eclipse. The sequence of > commands used to trigger the bug can be based on MI commands. If we have > that, and the bug can only be triggered against your stub, it may still be > reproduciable with gdbreplay, if you give us a "set remotelogfile" log file. > (See "Using GDBreplay" in gdb/gdbserver/README. Make sure to try yourself > against gdbreplay before sending us the log.) I have uploaded the mi-command file and remote log file, error happens at mi command "41-var-create --thread 1 --frame 0 - * "&(\"Hello World!\\n\")". but i can't reproducer this issue on every pc, a other pc sends diffrent rsp commands sequence when i use the same mi-commond sequence.