I need to use gdb to debug greenplum, the distributed version of PostgreSQL database. Now I have successfully installed greenplum and was able to use psql to run a sql. However, when I use gdb to debug it, it is difficult to get the code trace. It reports "no such file" frequently. I did not find useful documents online. Does anyone has related experience? Thanks.
For the greenplum database, I have one master node and two segment nodes.
In terminal A, I first use pg_backend_pid() on the master node to get the backend thread id.
[testDB=# select pg_backend_pid();
pg_backend_pid
----------------
9893
(1 row)
In a different terminal B, I then use gdb to attach to the backend process:
gpadmin#greenplum-mdw:/home/build/gpdb$ sudo gdb -p 9893
I can see the threads information by "info thre":
(gdb) info thre
Id Target Id Frame
* 1 Thread 0x7fe0a51a7740 (LWP 9893) "postgres" 0x00007fe0a24d587f in __libc_recv (fd=11, buf=buf#entry=0x102db80 <PqRecvBuffer>, n=n#entry=8192, flags=flags#entry=0)
at ../sysdeps/unix/sysv/linux/x86_64/recv.c:28
2 Thread 0x7fe08cee7700 (LWP 9894) "postgres" 0x00007fe0a194974d in poll () at ../sysdeps/unix/syscall-template.S:84
In terminal A, I run a sql through the psql interface:
[testDB=# select count(*) from customers;
In terminal B, I run the program by steps, but it says no such file or directory like this:
(gdb) n
29 ../sysdeps/unix/sysv/linux/x86_64/recv.c: No such file or directory.
and this
(gdb) n
pq_recvbuf () at pqcomm.c:925
925 pqcomm.c: No such file or directory.
I want to look at function PostgresMain, so I did:
(gdb) b PostgresMain
Note: breakpoint 1 also set at pc 0x87c860.
Breakpoint 2 at 0x87c860: file postgres.c, line 4590.
But after I run continue like this:
(gdb) c
Continuing.
It just never stop.
I finally found that greenplum did not add -g and -ggdb flags when compiling. I added it and then it works.
Related
Recently I am working on upgrading my opensips version manually from 2.2 to 3.3.
Upgradation is done from my side but in old opensips(2.2) I was able to show registered user(SIP) using opensipsctl ul show command but in new version 3.3 opensipsctl is deprecated(I guess not sure).
So I am trying to get details using opensips-cli but I didn't find out correct command for show register and show dump list, I try to follow below link but did not find correct command.
https://www.opensips.org/Documentation/Interface-CoreMI-3-0
Also, my opensips-cli -x command not working giving the below error. (mi_fifo module loaded correctly)
# opensips-cli -o output_type=yaml -x mi uptime
ERROR: cannot access fifo file /tmp/opensips_fifo: [Errno 13] Permission denied: '/tmp/opensips_fifo'
ERROR: starting with Linux kernel 4.19, processes can no longer read from FIFO files
ERROR: that are saved in directories with sticky bits (such as /tmp)
ERROR: and are not owned by the same user the process runs with.
ERROR: To fix this, either store the file in a non-sticky bit directory (such as /var/run/opensips),
ERROR: or disable fifo file protection using 'sysctl fs.protected_fifos=0' (NOT RECOMMENDED)
/tmp/opensips_fifo file also created correctly.
# ls -l /tmp/opensips_fifo
prw-rw-rw- 1 opensips opensips 0 Dec 29 06:52 /tmp/opensips_fifo
Using opensips-cli command I am able to create database and add table but not able to perform -x command.
Can anyone help me to find out a command for show register and show dump list also any suggestion related -x command not working on opensips-cli.
I had a similar error and i found the following:
if you state in the opensips-cli.cfg file that the fifo_file is located at /tmp/opensips_fifo, it will produce this error, try changing this setting to /var/run/opensips/opensips_fifo
PC: Debian 9.4.0, x64, ip 192.168.1.10
Qt: Qt Creator 4.6.1 Based on Qt5.11.0
BeagleBone Black: Debian 9.3.0, armv7, ip 192.168.1.20
I cross-compiled an GUI application for the BeagleBone Black on my PC and I can execute it successfully on my BeagleBone.
But when I remotely debug the application with F5(Menu: Debug->Start Debugging), I encounter an issue as follow.
QXcbConnection: Could not connect to display
The application crashes in main() at the line:
QApplication a(argc, argv);
The following are the details when compiling and debugging:
debug details:
Checking available ports...
Found 101 free ports.
Starting gdbserver...
Debugging starts
Listening on port 10001
Remote debugging from host 192.168.1.10
Process /home/debian/gdb/armtest3 created; pid = 13981
Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Could not load shared library symbols for 25 libraries, e.g. /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
-----------------armtest3 start------------
QXcbConnection: Could not connect to display
compile output:
09:31:33: Running steps for project armtest3...
09:31:33: Configuration unchanged, skipping qmake step.
09:31:33: Starting: "/usr/bin/make"
make: Nothing to be done for 'first'.
09:31:33: The process "/usr/bin/make" exited normally.
09:31:33: The remote file system has 218 megabytes of free space, going ahead.
09:31:33: Deploy step finished.
09:31:33: Trying to kill "/home/debian/gdb/armtest3" on remote device...
09:31:37: Remote application killed.
09:31:37: Deploy step finished.
09:31:37: No deployment action necessary. Skipping.
09:31:37: Deploy step finished.
09:31:37: Elapsed time: 00:04.
The following are my BeagleBone Kit：
BeagleBone Kit configuration
main.c
main.c
#include "mainwindow.h"
#include <QApplication>
#include <iostream>
#include <QDateTime>
#include <QDebug>
using namespace std;
int main(int argc, char *argv[])
{
cout << "-----------------armtest3 start------------" << endl;
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
Relevant question: QXcbConnection: Could not connect to display, when trying to debug Linux app with Qt Creator
When you deploy your application and run it from within the X11 system on device itself, you're finding it works because here it has access to the DISPLAY environment variable which (briefly put) tells it where to display itself. This environment variable has been set further up the process tree in your X session.
When you launch a program via the debugger, Qt Creator is connecting to the remote device (via your settings in Tools > Options > Devices), and running the program via ssh. In this context your program no longer knows where to display itself, as obviously it can't display in ssh. It faults on the line you indicated because this is where the XCB subsystem is trying to determine which X-Server to connect to for this purpose.
So to answer your question: you need to manually provide the DISPLAY environment variable when remote debugging.
An easy way to test this is to go to Projects Mode, find the kit you are using to build for the remote device, and select the Run settings. Under this, you should find an Run Environment section. Here you can add a new variable called DISPLAY and set its value to the identifier of the display you are running on (I'm guessing you'll want :0.0, indicating the first available screen on localhost, although you should read about the DISPLAY variable e.g. here or here).
A longer-term, potentially better solution would be to set the same variable in the settings of your Kit (Tools > Options > Build & Run > Kits > Environment). This will then apply for future programs you create using this.
I am working with Ubuntu 16.04 and I have two shell scripts:
run_roscore.sh : This one fires up a roscore in one terminal.
run_detection_node.sh : This one starts an object detection node in another terminal and should start up once run_roscore.sh has initialized the roscore.
I need both the scripts to execute as soon as the system boots up.
I made both scripts executable and then added the following command to cron:
#reboot /path/to/run_roscore.sh; /path/to/run_detection_node.sh, but it is not running.
I have also tried adding both scripts to the Startup Applications using this command for roscore: sh /path/to/run_roscore.sh and following command for detection node: sh /path/to/run_detection_node.sh. And it still does not work.
How do I get these scripts to run?
EDIT: I used the following command to see the system log for the CRON process: grep CRON /var/log/syslog and got the following output:
CRON[570]: (CRON) info (No MTA installed, discarding output).
So I installed MTA and then systemlog shows:
CRON[597]: (nvidia) CMD (/path/to/run_roscore.sh; /path/to/run_detection_node.sh)
I am still not able to see the output (which is supposed to be a camera stream with detections, as I see it when I run the scripts directly in a terminal). How should I proceed?
Since I got this working eventually, I am gonna answer my own question here.
I did the following steps to get the script running from startup:
Changed the type of the script from shell to bash (extension .bash).
Changed the shebang statement to be #!/bin/bash.
In Startup Applications, give the command bash path/to/script to run the script.
Basically when I changed the shell type from sh to bash, the script starts running as soon as the system boots up.
Note, in case this helps someone: My intention to have run_roscore.bash as a separate script was to run roscore as a background process. One can run it directly from a single script (which is also running the detection node) by having roscore& as a command before the rosnode starts. This command will fire up the master as a background process and leave the same terminal open for following commands to be executed.
If you could install immortal you could use the require option to start in sequence your services, for example, this is could be the run config for /etc/immortal/script1.yml:
cmd: /path/to/script1
log:
file: /var/log/script1.log
wait: 1
require:
- script2
And for /etc/immortal/script2.yml
cmd: /path/to/script2
log:
file: /var/log/script2.log
What this will do it will try to start both scripts on boot time, the first one script1 will wait 1 second before starting and also wait for script2 to be up and running, see more about the wait and require option here: https://immortal.run/post/immortal/
Based on your operating system you will need to configure/setup immortaldir, her is how to do it for Linux: https://immortal.run/post/how-to-install/
Going more deep in the topic of supervisors there are more alternatives here you could find some: https://en.wikipedia.org/wiki/Process_supervision
If you want to make sure that "Roscore" (whatever it is) gets started when your Ubuntu starts up then you should start it as a service (not via cron).
See this question/answer.
I have multiple entries of a process "solr" on linux. It is installed as service on system and I can see following entries:
Inside file rc.local
Start solr on VM start-up
/sbin/service solr start
Also under following files:
file: rc1.d
entry: K29solr -> ../init.d/solr
file: rc2.d
entry: K29solr -> ../init.d/solr
file: rc3.d
entry: S79solr -> ../init.d/solr
file: rc4.d
entry: S79solr -> ../init.d/solr
file: rc5.d
entry: S79solr -> ../init.d/solr
My question is will these multiple entries lead to triggering of multiple starting of this process solr? Currently only one process is running but logs depict another process might have got triggered but just want to be sure is these entries could be reason. I am linux expert so please bear with me.
It seems like you want this process to run regardless of the runlevel (rc.#). You should only need the one entry in rc.local.
Here is more information on runlevels and startup scripts:
https://www.linux.com/news/enterprise/systems-management/8116-an-introduction-to-services-runlevels-and-rcd-scripts
When the system starts, it finds the default run level from the /etc/inittab file.
It will then run any scripts that have symbolic-links in the relevant rcn.d directory.
If the symbolic-link starts with S it will pass "start" to the linked script, if it starts with K it will pass "stop" to the linked script.
That is why you will find mostly K-prefixed symbolic-links in the rc0.d and rc6.d directories, because runlevel 0 is shutdown and 6 is reboot.
I have accidentally delete source code of nodejs application, but this application is running, so how can I get source code back from running app?
I hope source code has been cached in some directory.
I was able to recover the full file by attaching the debugger (as TGrif suggested).
To actually recover the code:
Use setBreakpoint('app.js', 10), where 10 is a line of the code you know will be ran over again in the running process
Say pause, then next until it's paused on the script you want to recover.
Finally, say list(5000), where 5000 is an arbitrarily long number of lines to list.
You will now have your full script printed out, albeit with line numbers at the front, but you can use a site like this to remove them.
Hope this helps anyone who encounters this unique issue in the future, as this took me a couple hours to figure out.
There is maybe a way to retrieve some of your source code with the Nodejs debugger.
Assuming Linux OS, you need to get the process id of your application:
$ ps -e | grep node
Next you entering your app in debug mode with something like that:
$ kill -s USR1 PID
where PID is the pid of your node app.
Then your start the debug console:
$ node debug -p PID
If you have an app console, you'll see:
Starting debugger agent.
Debugger listening on port 5858
In your debug console you should see a debug prompt and you can get available commands with:
debug> help
I am able to show some of the running app source with the list command:
debug> list(NUMBER_OF_LINE)
where NUMBER_OF_LINE is the number of source code line you want to display.
I'm not sure this is a one shot try for you or not because my source code was not deleted.
Hope you can get some results.