I am trying to do an example about memory management in C++. I want to show people that there always is something standing in the memory (even if you do not write anything in it)
My problem is that gdb seems to exactly delete this values for debugging purpose...
Breakpoint 1, main (argc=1, argv=0x7fffffffe8f8) at dangling.cpp:6
6 int *test=new int;
(gdb) n
8 *test=10;
(gdb) p *test
$1 = 0
(gdb) n
10 delete test;
(gdb) p *test
$2 = 10
(gdb) n
12 std::cout<<*test<<std::endl;
(gdb) p *test
$3 = 0
(gdb)
is there a way to tell gdb not to do that. I would like to see the real value in the memory instead of the 0 of $1 and $3
gdb seems to exactly delete this values for debuging purpouse.
GDB does nothing of the sort.
I would like to see the real value in the memory instead of the 0 of $1 and $3
You are seeing the real value in memory (which happens to be 0).
Your problem is that default heap allocation returns you "clean" memory. It's only on subsequent re-allocations that you'll likely see "dirty" memory.
Related
I’m new for spike and RISC V. I’m trying to do some dynamic instruction trace with spike. These instructions are from a sample.c file. I have tried the following commands:
$ riscv64-unknown-elf-gcc simple.c -g -o simple.out
$ riscv64-unknown-elf-objdump -d --line-numbers -S simple.out
But these commands display the assembled instructions in an out file, which is not I want. I need to trace the dynamic executed instruction in runtime. I find only two relative commands in spike host option:
-g - track histogram of PCs
-l - generate a log of execution
I’m not sure if the result is what I expected as above.
Does anyone have an idea how to do the dynamic instruction trace in spike?
Thanks a lot!
Yes, you can call spike with -l to get a trace of all executed instructions.
Example:
$ spike -l --isa=RV64gc ~/riscv/pk/riscv64-unknown-elf/bin/pk ./hello 2> ins.log
Note that this trace also contains all instructions executed by the proxy-kernel - rather than just the trace of your user program.
The trace can still be useful, e.g. you can search for the start address of your code (i.e. look it up in the objdump output) and consume the trace from there.
Also, when your program invokes a syscall you see something like this in the trace:
[.. inside your program ..]
core 0: 0x0000000000010088 (0x00000073) ecall
core 0: exception trap_user_ecall, epc 0x0000000000010088
core 0: 0x0000000080001938 (0x14011173) csrrw sp, sscratch, sp
[.. inside the pk ..]
sret
[.. inside your program ..]
That means you can skip to the sycall instruction (that are executed in the pk) by searching for the next sret.
Alternatively, you can call spike with -d to enter debug mode. Then you can set a breakpoint on the first instruction of interest in your program (until pc 0 YOURADDRESS - look up the address in the objdump output) and single step from there (by hitting return multiple times). See also the help screen by entering h at the spike prompt.
How can I automatically see current 10 instructions whenever my program stopped by breakpoint in gdb?
(not machine instruction but high level instruction e.g
int a = 10;
int b = 12;
...
print("a = %d, b = %d\n");
To do this manually, I have to use 'list' command to see the instructions.
What command should I use?
Thanks
In addition to using tui or an Emacs gud mode, you could define hook-stop:
(gdb) define hook-stop
>list
>end
I installed Linpack on a 2-Node cluster with Xeon processors. Sometimes if I start Linpack with this command:
mpiexec -np 28 -print-rank-map -f /root/machines.HOSTS ./xhpl_intel64
linpack starts and prints the output, sometimes I only see the mpi mappings printed and then nothing following. To me this seems like random behaviour because I don't change anything between the calls and as already mentioned, Linpack sometimes starts, sometimes not.
In top I can see that xhpl_intel64processes have been created and they are heavily using the CPU but when watching the traffic between the nodes, iftop is telling me that it nothing is sent.
I am using MPICH2 as MPI implementation. This is my HPL.dat:
# cat HPL.dat
HPLinpack benchmark input file
Innovative Computing Laboratory, University of Tennessee
HPL.out output file name (if any)
6 device out (6=stdout,7=stderr,file)
1 # of problems sizes (N)
10000 Ns
1 # of NBs
250 NBs
0 PMAP process mapping (0=Row-,1=Column-major)
1 # of process grids (P x Q)
2 Ps
14 Qs
16.0 threshold
1 # of panel fact
2 PFACTs (0=left, 1=Crout, 2=Right)
1 # of recursive stopping criterium
4 NBMINs (>= 1)
1 # of panels in recursion
2 NDIVs
1 # of recursive panel fact.
1 RFACTs (0=left, 1=Crout, 2=Right)
1 # of broadcast
1 BCASTs (0=1rg,1=1rM,2=2rg,3=2rM,4=Lng,5=LnM)
1 # of lookahead depth
1 DEPTHs (>=0)
2 SWAP (0=bin-exch,1=long,2=mix)
64 swapping threshold
0 L1 in (0=transposed,1=no-transposed) form
0 U in (0=transposed,1=no-transposed) form
1 Equilibration (0=no,1=yes)
8 memory alignment in double (> 0)
edit2:
I now just let the program run for a while and after 30min it tells me:
# mpiexec -np 32 -print-rank-map -f /root/machines.HOSTS ./xhpl_intel64
(node-0:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15)
(node-1:16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31)
Assertion failed in file ../../socksm.c at line 2577: (it_plfd->revents & 0x008) == 0
internal ABORT - process 0
APPLICATION TERMINATED WITH THE EXIT STRING: Hangup (signal 1)
Is this a mpi problem?
Do you know what type of problem this could be?
I figured out what the problem was: MPICH2 uses different random ports each time it starts and if these are blocked your application wont start up correctly.
The solution for MPICH2 is to set the environment variable MPICH_PORT_RANGE to START:END, like this:
export MPICH_PORT_RANGE=50000:51000
Best,
heinrich
I'm used to debug my code using ghci. Often, something like this happens (not so obvious, of course):
ghci> let f#(_:x) = 0:1:zipWith(+)f x
ghci> length f
Then, nothing happens for some time, and if I don't react fast enough, ghci has eaten maybe 2 GB of RAM, causing my system to freeze. If it's too late, the only way to solve this problem is [ALT] + [PRINT] + [K].
My question: Is there an easy way to limit the memory, which can be consumed by ghci to, let's say 1 GB? If limit is exceed, the calculation should ve aborted or ghci should be killed.
A platform independant way to accomplish this is to supply the -M option as on option to the Haskell runtime like this
ghci +RTS -M1m
see the GHC documentation’s page on how to control the RTS (runtime system) for details.
The ghci output now looks like:
>ghci +RTS -M10m
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> let f#(_:x) = 0:1:zipWith(+)f x
Prelude> length f
Heap exhausted;
Current maximum heap size is 10485760 bytes (10 MB);
use `+RTS -M<size>' to increase it.
Running it under a shell with ulimit -m set is a fairly easy way. If you want to run with some limit on a regular basis, you can create a wrapper script that does ulimit before running ghci.
Is there a way to get the instruction pointer of a running application Unix?
I have a running process (C++) and want to get its current location, and thereafter in GDB (on a different machine) map the location to source location ('list' command).
On Linux, there is /proc/[pid]/stat.
From "man proc":
stat Status information about the process. This is used by
ps(1). It is defined in /usr/src/linux/fs/proc/array.c.
...
kstkeip %lu
The current EIP (instruction pointer).
AFAICT, the 29th field of the output corresponds to the current instruction pointer of the process. For example:
gdb date
GNU gdb Red Hat Linux (6.0post-0.20040223.20rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) set stop-on-solib-events 1
(gdb) run
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled]
[New Thread 182896391360 (LWP 27968)]
(no debugging symbols found)...Stopped due to shared library event
(gdb) c
[Switching to Thread 182896391360 (LWP 27968)]
Stopped due to shared library event
(gdb) where
#0 0x00000036b060bb20 in _dl_debug_state_internal () from /lib64/ld-linux-x86-64.so.2
#1 0x00000036b060b51c in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#2 0x00000036b0600f72 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#3 0x0000000000000001 in ?? ()
#4 0x0000007fbff62728 in ?? ()
#5 0x0000000000000000 in ?? ()
(gdb) shell cat /proc/27968/stat
27968 (date) T 27839 27968 8955 34817 27839 4194304 42 0 330 0 0 0 0 0 18 0 0 0 1881668573 6144000 78 18446744073709551615 4194304 4234416 548680739552 18446744073709551615 234887363360 0 0 0 0 18446744071563322838 0 0 17 0 0 0 0 0 0 0
(gdb) p/a 234887363360 <--- the value of 29th field
$1 = 0x36b060bb20 <_dl_debug_state_internal>
The instruction pointer can be retrieved on Linux with the following code:
pid_t traced_process;
struct user_regs_struct regs;
ptrace(PTRACE_ATTACH, traced_process, NULL, NULL);
ptrace(PTRACE_GETREGS, traced_process, NULL, ®s);
printf("EIP: %lx\n", regs.eip);
You will need to temporarily stop the process or thread in order to get its current instruction pointer. You can do it by attaching to the process with ptrace() or (on HP-UX) ttrace() and accessing the registers.
If you're using gdb anyway, you can simply attach yourself to a running process like this:
gdb program 1234
where program is the name of the executable you're debugging, and 1234 is the PID. You can then use all of the facilities of gdb to debug the process.