core dump when watchpoint set

core dump when watchpoint set

[Joel Sherrill]

Hi,

I wondered if this looked familiar and was fixed in
CVS.  I am using gdb 6.8 targeting powerpc and running
the application using psim.  When I set a watchpoint
and then run, gdb core dumps.

If this isn't a known issue, can someone point me in
the direction of what to look at so I can fix it?


(gdb) watch _Thread_Executing
Watchpoint 5: _Thread_Executing
(gdb) info watchpoints
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x000091bc in _Internal_error_Occurred 
at ../../../../../../current/c/src/../../cpukit/score/src/interr.c:53
2       breakpoint     keep y   0x0000856c in rtems_fatal_error_occurred 
at ../../../../../../current/c/src/../../cpukit/sapi/src/fatal.c:38
3       breakpoint     keep y   0x0000d9dc in __assert at 
../../../../../../current/c/src/../../cpukit/libcsupport/src/__assert.c:48
4       breakpoint     keep y   0x00001fdc in C_exception_handler
                                       at 
../../../../../../../current/c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/vectors_init.c:119
5       watchpoint     keep y              _Thread_Executing
(gdb) r
Starting program: /home/joel/rtems-4.9-work/build/test/minimum.ralf

Program received signal SIGSEGV, Segmentation fault.
value_type (value=0x0) at ../../gdb-6.8/gdb/value.c:269
269     {
Missing separate debuginfos, use: debuginfo-install expat.i386 
glibc.i686 ncurses.i386 readline.i386
(gdb) bt
#0  value_type (value=0x0) at ../../gdb-6.8/gdb/value.c:269
#1  0x080ca752 in coerce_array (arg=0x0) at ../../gdb-6.8/gdb/value.c:1677
#2  0x080d6cf7 in value_equal (arg1=0x0, arg2=0xa23ecc8) at 
../../gdb-6.8/gdb/valarith.c:1603
#3  0x080bdf7e in watchpoint_check (p=0xa1e3568) at 
../../gdb-6.8/gdb/breakpoint.c:2578
#4  0x080fd9e3 in catch_errors (func=0x80bde40 <watchpoint_check>, 
func_args=0xa1e3568,
    errstring=0xa23eb20 "Error evaluating expression for watchpoint 
5\n", mask=6)
    at ../../gdb-6.8/gdb/exceptions.c:513
#5  0x080bf262 in bpstat_stop_status (bp_addr=376, ptid={pid = 42, lwp = 
0, tid = 0})
    at ../../gdb-6.8/gdb/breakpoint.c:2790
#6  0x080f3cb9 in handle_inferior_event (ecs=0xbf8436b4) at 
../../gdb-6.8/gdb/infrun.c:1980
#7  0x080f5de7 in wait_for_inferior (treat_exec_as_sigtrap=0) at 
../../gdb-6.8/gdb/infrun.c:1042
#8  0x080f5fb4 in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_0, 
step=0) at ../../gdb-6.8/gdb/infrun.c:844
#9  0x080f1113 in run_command_1 (args=0x0, from_tty=1, 
tbreak_at_main=<value optimized out>)
    at ../../gdb-6.8/gdb/infcmd.c:563
#10 0x08053555 in execute_command (p=0xa0d90e1 "", from_tty=1) at 
../../gdb-6.8/gdb/top.c:449
#11 0x08100eaf in command_handler (command=0xa0d90e0 "") at 
../../gdb-6.8/gdb/event-top.c:518
#12 0x08101b47 in command_line_handler (rl=0xa1b8c10 "") at 
../../gdb-6.8/gdb/event-top.c:804
#13 0x005e5892 in rl_callback_read_char () from /lib/libreadline.so.5
#14 0x0810103b in rl_callback_read_char_wrapper (client_data=0x0) at 
../../gdb-6.8/gdb/event-top.c:177
#15 0x08100a97 in handle_file_event (event_file_desc=0) at 
../../gdb-6.8/gdb/event-loop.c:728
#16 0x080fff59 in process_event () at ../../gdb-6.8/gdb/event-loop.c:341
#17 0x08100728 in gdb_do_one_event (data=0x0) at 
../../gdb-6.8/gdb/event-loop.c:378
#18 0x080fd9e3 in catch_errors (func=0x8100610 <gdb_do_one_event>, 
func_args=0x0, errstring=0x83590e8 "", mask=6)
    at ../../gdb-6.8/gdb/exceptions.c:513
#19 0x080a9e2a in tui_command_loop (data=0x0) at 
../../gdb-6.8/gdb/tui/tui-interp.c:153
#20 0x080fdfaf in current_interp_command_loop () at 
../../gdb-6.8/gdb/interps.c:276
#21 0x0804c32b in captured_command_loop (data=0x0) at 
../../gdb-6.8/gdb/main.c:99
#22 0x080fd9e3 in catch_errors (func=0x804c320 <captured_command_loop>, 
func_args=0x0, errstring=0x83590e8 "",
    mask=6) at ../../gdb-6.8/gdb/exceptions.c:513
#23 0x0804cb55 in captured_main (data=0xbf843c04) at 
../../gdb-6.8/gdb/main.c:882
#24 0x080fd9e3 in catch_errors (func=0x804c360 <captured_main>, 
func_args=0xbf843c04, errstring=0x83590e8 "",
    mask=6) at ../../gdb-6.8/gdb/exceptions.c:513
#25 0x0804c311 in gdb_main (args=0xbf843c04) at ../../gdb-6.8/gdb/main.c:891
#26 0x0804c2d5 in main (argc=Cannot access memory at address 0x1
) at ../../gdb-6.8/gdb/gdb.c:33




-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: core dump when watchpoint set

[Michael Snyder]

Hmmm, yeah, a null value is being passed up, resulting in
a null type being sent to value_type, which dereferences it
without null-checking.

And in fact, the current source (breakpoint.c) does check
b->val != NULL before it makes the corresponding call.

So you can expect that this is fixed.

Joel Sherrill wrote:
> Hi,
> 
> I wondered if this looked familiar and was fixed in
> CVS.  I am using gdb 6.8 targeting powerpc and running
> the application using psim.  When I set a watchpoint
> and then run, gdb core dumps.
> 
> If this isn't a known issue, can someone point me in
> the direction of what to look at so I can fix it?
> 
> 
> (gdb) watch _Thread_Executing
> Watchpoint 5: _Thread_Executing
> (gdb) info watchpoints
> Num     Type           Disp Enb Address    What
> 1       breakpoint     keep y   0x000091bc in _Internal_error_Occurred
> at ../../../../../../current/c/src/../../cpukit/score/src/interr.c:53
> 2       breakpoint     keep y   0x0000856c in rtems_fatal_error_occurred
> at ../../../../../../current/c/src/../../cpukit/sapi/src/fatal.c:38
> 3       breakpoint     keep y   0x0000d9dc in __assert at
> ../../../../../../current/c/src/../../cpukit/libcsupport/src/__assert.c:48
> 4       breakpoint     keep y   0x00001fdc in C_exception_handler
>                                        at
> ../../../../../../../current/c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/vectors_init.c:119
> 5       watchpoint     keep y              _Thread_Executing
> (gdb) r
> Starting program: /home/joel/rtems-4.9-work/build/test/minimum.ralf
> 
> Program received signal SIGSEGV, Segmentation fault.
> value_type (value=0x0) at ../../gdb-6.8/gdb/value.c:269
> 269     {
> Missing separate debuginfos, use: debuginfo-install expat.i386
> glibc.i686 ncurses.i386 readline.i386
> (gdb) bt
> #0  value_type (value=0x0) at ../../gdb-6.8/gdb/value.c:269
> #1  0x080ca752 in coerce_array (arg=0x0) at ../../gdb-6.8/gdb/value.c:1677
> #2  0x080d6cf7 in value_equal (arg1=0x0, arg2=0xa23ecc8) at
> ../../gdb-6.8/gdb/valarith.c:1603
> #3  0x080bdf7e in watchpoint_check (p=0xa1e3568) at
> ../../gdb-6.8/gdb/breakpoint.c:2578
> #4  0x080fd9e3 in catch_errors (func=0x80bde40 <watchpoint_check>,
> func_args=0xa1e3568,
>     errstring=0xa23eb20 "Error evaluating expression for watchpoint
> 5\n", mask=6)
>     at ../../gdb-6.8/gdb/exceptions.c:513
> #5  0x080bf262 in bpstat_stop_status (bp_addr=376, ptid={pid = 42, lwp =
> 0, tid = 0})
>     at ../../gdb-6.8/gdb/breakpoint.c:2790
> #6  0x080f3cb9 in handle_inferior_event (ecs=0xbf8436b4) at
> ../../gdb-6.8/gdb/infrun.c:1980
> #7  0x080f5de7 in wait_for_inferior (treat_exec_as_sigtrap=0) at
> ../../gdb-6.8/gdb/infrun.c:1042
> #8  0x080f5fb4 in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_0,
> step=0) at ../../gdb-6.8/gdb/infrun.c:844
> #9  0x080f1113 in run_command_1 (args=0x0, from_tty=1,
> tbreak_at_main=<value optimized out>)
>     at ../../gdb-6.8/gdb/infcmd.c:563
> #10 0x08053555 in execute_command (p=0xa0d90e1 "", from_tty=1) at
> ../../gdb-6.8/gdb/top.c:449
> #11 0x08100eaf in command_handler (command=0xa0d90e0 "") at
> ../../gdb-6.8/gdb/event-top.c:518
> #12 0x08101b47 in command_line_handler (rl=0xa1b8c10 "") at
> ../../gdb-6.8/gdb/event-top.c:804
> #13 0x005e5892 in rl_callback_read_char () from /lib/libreadline.so.5
> #14 0x0810103b in rl_callback_read_char_wrapper (client_data=0x0) at
> ../../gdb-6.8/gdb/event-top.c:177
> #15 0x08100a97 in handle_file_event (event_file_desc=0) at
> ../../gdb-6.8/gdb/event-loop.c:728
> #16 0x080fff59 in process_event () at ../../gdb-6.8/gdb/event-loop.c:341
> #17 0x08100728 in gdb_do_one_event (data=0x0) at
> ../../gdb-6.8/gdb/event-loop.c:378
> #18 0x080fd9e3 in catch_errors (func=0x8100610 <gdb_do_one_event>,
> func_args=0x0, errstring=0x83590e8 "", mask=6)
>     at ../../gdb-6.8/gdb/exceptions.c:513
> #19 0x080a9e2a in tui_command_loop (data=0x0) at
> ../../gdb-6.8/gdb/tui/tui-interp.c:153
> #20 0x080fdfaf in current_interp_command_loop () at
> ../../gdb-6.8/gdb/interps.c:276
> #21 0x0804c32b in captured_command_loop (data=0x0) at
> ../../gdb-6.8/gdb/main.c:99
> #22 0x080fd9e3 in catch_errors (func=0x804c320 <captured_command_loop>,
> func_args=0x0, errstring=0x83590e8 "",
>     mask=6) at ../../gdb-6.8/gdb/exceptions.c:513
> #23 0x0804cb55 in captured_main (data=0xbf843c04) at
> ../../gdb-6.8/gdb/main.c:882
> #24 0x080fd9e3 in catch_errors (func=0x804c360 <captured_main>,
> func_args=0xbf843c04, errstring=0x83590e8 "",
>     mask=6) at ../../gdb-6.8/gdb/exceptions.c:513
> #25 0x0804c311 in gdb_main (args=0xbf843c04) at ../../gdb-6.8/gdb/main.c:891
> #26 0x0804c2d5 in main (argc=Cannot access memory at address 0x1
> ) at ../../gdb-6.8/gdb/gdb.c:33
> 
> 
> 
> 
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill@OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985
> 
> 

RE: core dump when watchpoint set

[Robert Norton]

> -----Original Message-----
> From: gdb-owner@sourceware.org
> [mailto:gdb-owner@sourceware.org] On Behalf Of Michael Snyder
> Sent: 09 September 2008 23:10
> To: Joel Sherrill
> Cc: gdb@sourceware.org
> Subject: Re: core dump when watchpoint set
>
> Hmmm, yeah, a null value is being passed up, resulting in
> a null type being sent to value_type, which dereferences it
> without null-checking.
>
> And in fact, the current source (breakpoint.c) does check
> b->val != NULL before it makes the corresponding call.
>
> So you can expect that this is fixed.

In fact I fixed exactly this bug in our 6.8 port this week by applying this patch:

http://sourceware.org/ml/gdb-patches/2008-02/msg00472.html

Robert

Re: core dump when watchpoint set

[Joel Sherrill]

Robert Norton wrote:
>> -----Original Message-----
>> From: gdb-owner@sourceware.org
>> [mailto:gdb-owner@sourceware.org] On Behalf Of Michael Snyder
>> Sent: 09 September 2008 23:10
>> To: Joel Sherrill
>> Cc: gdb@sourceware.org
>> Subject: Re: core dump when watchpoint set
>>
>> Hmmm, yeah, a null value is being passed up, resulting in
>> a null type being sent to value_type, which dereferences it
>> without null-checking.
>>
>> And in fact, the current source (breakpoint.c) does check
>> b->val != NULL before it makes the corresponding call.
>>
>> So you can expect that this is fixed.
>>     
>
> In fact I fixed exactly this bug in our 6.8 port this week by applying this patch:
>
> http://sourceware.org/ml/gdb-patches/2008-02/msg00472.html
>
>   
Thank you.  I can confirm it fixes the issue when used with psim
as well.

Ralf.. could you add this patch to the RTEMS gdb 6.8 set?  Thanks.
> Robert
>
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985