I run the debugger via
mpirun -n 4 xterm -e gdb -x commands.gdb ./my_mpi_programm
where the file "commands.gdb" just contains the commands
start
continue
The problem is that my 4 xterm immediately close before I get a chance to inspect the error message or do any debugging.
I'm using the latest ubuntu distribution. However, on my friend's old Suse-distribution, xterm is held open.
How can I force the xterms to stay?
EDIT: the "-hold" option doesnt work as well as
mpirun -n 4 xterm -e "gdb -x commands.gdb ./my_mpi_programm;bash"
Try
mpirun -n 4 xterm -e bash -c 'gdb -x commands.gdb ./my_mpi_programm; sleep 60'
Related
I need to launch 2 executables (program1 and program2) with the same mpirun (mpich) command, and I'm trying to debug program1 with gdb. I use this command:
mpirun -n 1 gdb program1 : -n 1 program2
The command correctly opens the gdb console, but if I set a breakpoint somewhere after mpi_init, the screen gets flooded with the standard output of program2. Is there a simple way to redirect the standard output of program2 (only program2) to a file?
My fast solution was to hard-code a cut of stdout in program2, but I'm sure there must be a more elegant one ...
You could try this:
create a wrapper.sh that redirect the stdout and stderr to the file output :
cat > wrapper.sh << EOF
#!/bin/bash
\$* 1>>output 2>&1
EOF
make it executable
chmod +x wrapper.sh
mpirun with the wrapper
mpirun -n 1 gdb program1 : -n 1 ./wrapper.sh program2
Sending a pcap file on port 0. I get the following error. Any fix would be appreciated!
The command used is:
sudo ./app/x86_64-native-linuxapp-gcc/pktgen -c 0X01 -n 1 --file-prefix=pg -w 4:00.1 -- -m 1.0 -T -P -s 0:~/Downloads/bigFlows.pcap
There are 2 obvious reasons for the failure.
Number of CPU cores for pktgen to work is 1 + number of ports in use
you have extra argument in comamnd executed in pktgen.
Checking the link, it show the command used is sudo ./app/x86_64-native-linuxapp-gcc/pktgen -c 0X01 -n 1 --file-prefix=pg -w 4:00.1 -- -m 1.0 -T -P -s 0:[~/Downloads/bigFlows.pcap]. You should not sue [] instead use 0:actual path to pcap.
Note: #SaifUllah during the live debug both core and pcap were show cased for you.
I have a issue with gdb printf in version 9.1
echo -e '#include<stdio.h> \n int main(){ \n printf("Hello"); \n }' > test.c
gcc -g test.c -o test
echo 'break test.c:4' > test.gdb
echo 'run' >> test.gdb
echo 'set $aux = (char*)malloc(256)' >> test.gdb
echo 'set $e = strcpy($aux, "abc")' >> test.gdb
echo 'printf "%s", $aux' >> test.gdb
gdb --batch --command=test.gdb test
Output with gdb 9.1:
Breakpoint 1 at 0x1167: file test.c, line 4.
Breakpoint 1, main () at test.c:4
4 }
�e���
Expected output (same as gdb v8):
Breakpoint 1 at 0x1167: file test.c, line 4.
Breakpoint 1, main () at test.c:4
4 }
abc
I've checked charset, but it seems ok.
Any idea about that?
This is Bug 25650 - GDB can't 'printf' a convenience variable holding an inferior address, fixed in gdb 9.2.
If you can't upgrade to gdb 9.2 but can recompile your existing distro's gdb 9.1, there is a two-line patch.
On Ubuntu 20.04, which comes with gdb 9.1-0ubuntu1:
run apt build-dep gdb to haul in the packages needed to build gdb from source
run apt install dpkg-dev (to get /usr/bin/dpkg-source)
uncomment the deb-src lines in /etc/apt/sources.list
run apt update
cd to an empty directory and run apt source gdb . Doing this in a fresh new directory will make it easier to clean things up after the compilation.
cd to gdb-9.1 and apply the patch to gdb/printcmd.c
build and install gdb. For example, to put it in /usr/local/bin, the default, you'd run
mkdir build
cd build
../configure
make
make install
I'm trying to run 2 C++ programs simultaneously. Both programs make use of inotify to each watch a folder for file creation, then handle the events (in a different manner) respectively. The programs also run indefinitely so they are forever watching their respective folders for new files.
I have a shell script that simply does the following:
./program1 -i input_file -o output_file
./program2 -i input_file -o output_file
I'm worried that because program1 is blocking and runs indefinitely, program2 will never get to execute. Is this the case? How should I work around this then?
Will ./program1 -i input_file -o output_file & ./program2 -i input_file -o output_file work?
Can I get gdb to automatically load the binary that's specified in the core file?
Given a core file I now usually do:
gdb -c corefile
GNU gdb 6.8
...
Core was generated by `/path/to/binary'
Then i copy-paste that and run:
gdb -c corefile /path/to/binary
It seems like an unnecessary two-step process and yet I don't seen an obvious way of doing it based on the man page. Am I missing something?
You could just script it?
#!/bin/bash
gdb "`file "$1" | awk -F \' '{print $2}'`" "$1"
This is what I usually endup doing:
var=$(file corefile)
echo ${var##*from}
gdc() {
gdb -c "$1" "$(file "$1" | sed -r -e "s#.*execfn: '([^\']+)'.*#\1#")"
}
$ gdc corefile