Bug 1061463

Summary: [abrt] openocd: ioutil_Jim_Command_peek(): openocd killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Josep <josep.puigdemont>
Component: openocdAssignee: Dean Glazeski <dnglaze>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: chitlesh, dnglaze, LotharLutz, shakthimaan
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/be7a13fd42dcdc2967ac20a6458bd5ae64e70836
Whiteboard: abrt_hash:a812c3416e07637bae479376b460ce57229d8603
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-05 10:14:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Josep 2014-02-04 21:13:36 UTC
Description of problem:
I was connected to the opencd server via telnet to por 4444 and I issued the command:
> peek 0x0

Version-Release number of selected component:
openocd-0.7.0-3.fc20

Additional info:
reporter:       libreport-2.1.12
backtrace_rating: 4
cmdline:        openocd -s /usr/share/openocd/scripts -f ../daemon.cfg -f interface/olimex-arm-usb-ocd-h.cfg -f board/olimex_stm32_h103.cfg
crash_function: ioutil_Jim_Command_peek
executable:     /usr/bin/openocd
kernel:         3.12.9-301.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 ioutil_Jim_Command_peek at ioutil.c:421
 #1 JimInvokeCommand at jim.c:10074
 #2 Jim_EvalObj at jim.c:10519
 #3 Jim_EvalSource at jim.c:10838
 #4 command_run_line at command.c:659
 #5 telnet_input at telnet_server.c:391
 #6 server_loop at server.c:465
 #7 openocd_thread at openocd.c:295
 #8 openocd_main at openocd.c:328
 #10 _start

Comment 1 Josep 2014-02-04 21:13:41 UTC
Created attachment 859374 [details]
File: backtrace

Comment 2 Josep 2014-02-04 21:13:43 UTC
Created attachment 859375 [details]
File: cgroup

Comment 3 Josep 2014-02-04 21:13:45 UTC
Created attachment 859376 [details]
File: core_backtrace

Comment 4 Josep 2014-02-04 21:13:47 UTC
Created attachment 859377 [details]
File: dso_list

Comment 5 Josep 2014-02-04 21:13:49 UTC
Created attachment 859378 [details]
File: environ

Comment 6 Josep 2014-02-04 21:13:51 UTC
Created attachment 859379 [details]
File: exploitable

Comment 7 Josep 2014-02-04 21:13:53 UTC
Created attachment 859380 [details]
File: limits

Comment 8 Josep 2014-02-04 21:13:55 UTC
Created attachment 859381 [details]
File: maps

Comment 9 Josep 2014-02-04 21:13:57 UTC
Created attachment 859382 [details]
File: open_fds

Comment 10 Josep 2014-02-04 21:13:58 UTC
Created attachment 859383 [details]
File: proc_pid_status

Comment 11 Josep 2014-02-04 21:14:00 UTC
Created attachment 859384 [details]
File: var_log_messages

Comment 12 Markus Mayer 2014-02-05 10:14:56 UTC
Hi Josep,

I'm not that familiar with openocd, so take my comment with a grain of salt.

'peek' reads from the memory address given by the first parameter. It reads the memory of the machine openocd is running (that's your PC). It doesn't read the memory of the debugged device.

So 'peek 0x0' will read/dereference a null pointer, which will cause your x64-cpu to emit a segmentation fault. That's by design!

I'm closing this as 'not a bug', but if you disagree fell free to reopen it.


regards
   Markus

Comment 13 Josep 2014-02-05 12:35:24 UTC
Hi Markus,
I didn't know peek looked at the memory on the machine where openocd was running, that seems an odd feature, but why not...
Closing seems the right thing to do, thanks anyway.