Bug 18274 - gdb crashed when I move my mouse to a const string
Summary: gdb crashed when I move my mouse to a const string
Status: WAITING
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.8
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-17 12:24 UTC by jiangtaijin
Modified: 2016-05-16 18:04 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
mi commant list (706 bytes, text/plain)
2015-04-25 05:21 UTC, jiangtaijin
Details
debug remote log file (1.68 KB, text/plain)
2015-04-25 05:23 UTC, jiangtaijin
Details
cmd error out put (4.10 KB, text/plain)
2015-04-25 05:24 UTC, jiangtaijin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jiangtaijin 2015-04-17 12:24:35 UTC
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
Comment 1 Pedro Alves 2015-04-20 08:55:20 UTC
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.
Comment 2 jiangtaijin 2015-04-21 05:50:54 UTC
(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".
Comment 3 Pedro Alves 2015-04-21 08:01:07 UTC
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.
Comment 4 jiangtaijin 2015-04-21 09:30:14 UTC
(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"
Comment 5 Pedro Alves 2015-04-21 12:50:39 UTC
> 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.
Comment 6 jiangtaijin 2015-04-21 14:48:05 UTC
(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.
Comment 7 Pedro Alves 2015-04-21 15:28:36 UTC
> 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.
Comment 8 jiangtaijin 2015-04-22 07:25:20 UTC
(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.
Comment 9 Pedro Alves 2015-04-22 10:38:11 UTC
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.)
Comment 10 jiangtaijin 2015-04-25 05:21:23 UTC
Created attachment 8268 [details]
mi commant list
Comment 11 jiangtaijin 2015-04-25 05:23:46 UTC
Created attachment 8269 [details]
debug remote log file
Comment 12 jiangtaijin 2015-04-25 05:24:42 UTC
Created attachment 8270 [details]
cmd error out put
Comment 13 jiangtaijin 2015-04-25 05:34:42 UTC
(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.