I test now an web application at my job. I use Debian. I don't know what kind of project is, just know that is built in Perl and uses PostgreSQL. The project where Back-End is built, uses CARTON, a Perl module dependency manager (aka Bundler for Perl) http://search.cpan.org/~miyagawa/Carton-v1.0.12/lib/Carton.pm. To run the Back-End I have to start PostgreSQL sudo su postgres and then execute command carton exec foo and Back-End start to work. But today, after some updates and upgrades, I executed it and got this error message Segmentation fault. I found that to check what was going on I had to get a backtrace so I found and read this article:
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD
but still don't understand how to run the project with GDB.
Thanks
but still didn't find out how to get a backtrace. Once I start in gdb mode, I don't know what to type to run the back-end in gdb mode.
It's hard to answer your question because it's not clear exactly where you are getting stuck.
Use the first link you provided, to attach GDB to the running back end:
sudo gdb -p pid
(gdb) continue
Now execute whatever command causes your backend to crash. Once you do, GDB will stop and print something like:
Program received signal SIGSEGV, Segmentation fault.
0x00000000004004c0 in foo (p=0x0) at t.c:1
(gdb)
Now you are ready to obtain the crash stack trace, by using where GDB command.
(gdb) where
#0 0x00000000004004c0 in foo (p=0x0) at t.c:1
#1 0x00000000004004dc in bar (p=0x0) at t.c:2
#2 0x00000000004004ec in main () at t.c:4
You will likely not get file/line info and parameter values (you'll need to install debuginfo packages described in your second link for that), but you should get function names, which may be sufficient to find the relevant bug.
Related
Using Manjaro, I freshly installed PostgreSQL with an user-defined data-directory. PostgreSQL is running fine, but I can't find the postgresql*.log(s), which I used to find in /var/log/postgresql on my former system. In ksystemlog I've seen an error, that I forced by
select * from non_exist_table;
but I'm wondering, if there is no longer the postgresql*.log.
Thank you!
Here is my postgresql.conf.
With logging_collector=off, the logs will just spew to the stderr of the postmaster process. That could have been redirected to a file, or just going to some tty someplace, or just be thrown away. You would have to look at the code which launches the database server.
I am aware this question is very specific. Nontheless, maybe s.o. can help:
I was trying to compile an open-source code today. (anyone, who's interested, that's the one.) The error message described below occurs after oai_hss -j $PREFIX/hss_rel14.json --onlyloadkey - having followed the step-by-step installation guide to this point.
After typing the aforementioned command in my terminal, the following error is thrown:
terminate called after throwing an instance of 'spdlog::spdlog_ex'
what(): Failed opening file logs/hss.log for writing: No such file or directory
Aborted (core dumped)
Allright, this sounds pretty severy (core dumped). I was searching google for a meaning of that error message. I came across this other github project. Apparently the spdlog class is trying to enable logging from wherever I run my program. And it throws an spdlog_ex error whenever the file it is trying to add to the registry (in this case logs/hss.log) already exists within this registry. So, I guess, the solution to my problem would be to find this registry and delete logs/hss.log. Does this make sense?
Question: Where the heck do I find this registry?
Maybe some background knowledge would be useful: I am trying to compile the open-source code within a VM that is running Ubuntu 18.04.3 LTS bionic with a 4.15.0-66-generic kernel.
I was searching the /tmp directory for a log folder already. There is none. Where else could it be?
open this file
sudo nano /usr/local/etc/oai/hss_rel14.json
you will see some config where you can find logs/hss.log
actually you have to change these 4 value to
logname: "/var/log/hss.log"
statlogname: "/var/log/hss_stat.log"
auditlogname: "/var/log/hss_audit.log"
ossfile: "~/openair-cn/etc/oss.json"
then use sudo touch to create these files
sudo touch /var/log/hss.log
sudo touch /var/log/hss_stat.log
sudo touch /var/log/hss_audit.log
for logname, statlogname, and auditlogname you can change it to whatever file you want but i like to put them together in /var/log folder.
for ossfile , the oss.json is actually in there.
hope this help
I am using helios Eclipse for debugging my code in postgresql.
My aim is to know how postgresql uses join algorithms during the join query, so I started to debug nodenestloop.c which is in the Executor folder.
I gave break points in that file, But whenever I try to debug that file, the control goes to main.c and never comes back,How do I constraint the control only to that particular file(nodenestloop.c)
Below are the following fields which I gave in Debug configurations of Helios Eclipse.
C/C++ Application - src/backend/postgres and
project - pgsql
I followed the steps given in the following link for running the program.
https://wiki.postgresql.org/wiki/Working_with_Eclipse#
I even uncheked the field "Start on Start up=main" , but When I do that, The step in and Step over buttons are not activated and the following problem has popped up.
Could not save master table to file '/home/ravi/workspace/.metadata/.plugins/org.eclipse.core.resources/.safetable/org.eclipse.core.resources'.
/home/ravi/workspace/.metadata/.plugins/org.eclipse.core.resources/.safetable/org.eclipse.core.resources (Permission denied)
So I started eclipse using sudo, but this time the following error has come in the console of eclipse.
"root" execution of the PostgreSQL server is not permitted.
The server must be started under an unprivileged user ID to prevent
possible system security compromise. See the documentation for
more information on how to properly start the server.
Could any one help me with this.
Thank you
Problem 1: User ID mismatch
Reading between the lines, it sounds like you're trying to debug a PostgreSQL instance that's running as the postgres user, or a different user ID to your own anyway. Hence your attempt to use sudo.
That's painful, especially when using an IDE like Eclipse. With plain gdb you can just sudo the gdb command to the desired uid, e.g. sudo -u postgres -p 12345 to attach to pid 12345 running as user postgres. This will not work with Eclipse. In fact, running it with sudo has probably left your workspace with some messed up file permissions; run:
sudo chown -R ravi /home/ravi/workspace/
to fix file ownership.
If you want to debug processes under other user IDs with Eclipse, you'll need to figure out how to make Eclipse run gdb with sudo. Do not just run all of Eclipse with sudo.
Problem 2: Trying to run PostgreSQL under the control of Eclipse
This:
"root" execution of the PostgreSQL server is not permitted. The server must be started under an unprivileged user ID to prevent possible system security compromise. See the documentation for more information on how to properly start the server.
suggests that you're also attempting to let Eclipse start postgres directly. That's very useful if you're trying to debug the postmaster, but since you're talking about the query planner it's clear you want to debug a particular backend. Launching the postmaster under Eclipse is useless for that, you'll be attached to the wrong process.
I think you probably need to read the documentation on PostgreSQL's internals:
Tour of PostgreSQL Internals
PostgreSQL internals through pictures
Documentation chapter - internals
Doing it right
Here's what you need to do - rough outline, since I've only used Eclipse for Java development and do my C development with vim and gdb:
Compile a debug build of PostgreSQL (compiled with ./configure --enable-debug and preferably also CFLAGS="-ggdb -Og -fno-omit-frame-pointer"). Specify a --prefix within your homedir, like --prefix=$HOME/postgres-debug
Put your debug build's bin directory first on your PATH, e.g. export PATH=$HOME/postgres-debug/bin:$PATH
initdb -U postgres -D $HOME/postgres-debug-data a new instance of PostgreSQL from your debug build
Start the new instance with PGPORT=5599 pg_ctl -D $HOME/postgres-debug-data -l $HOME/postgres-debug-data.log -w start
Connect with PGPORT=5599 psql postgres
Do whatever setup you need to do
Get the backend process ID with SELECT pg_backend_pid() in a psql session. Leave that session open; it's the one you'll be debugging.
Attach Eclipse's debugger to that process ID, using the Eclipse project that contains the PostgreSQL extension source code you're debugging. Make sure Eclipse is configured so it can find the PostgreSQL source code you compiled with too (no idea how to do that, see the manual).
Set any desired breakpoints and resume execution
In the psql session, do whatever you need to do to make your extension run and hit the breakpoint
When execution pauses at the breakpoint in Eclipse, debug as desired.
Basic misunderstandings?
Also, in case you're really confused about how all this works: PostgreSQL is a client/server application. If you are attempting to debug a client program that uses libpq or odbc, and expecting a breakpoint to trigger in some PostgreSQL backend extension code, that is not going to happen. The client application communicates with PostgreSQL over a TCP/IP socket. It's a separate program. gdb cannot set breakpoints in the PostgreSQL server when it's connected to the client, because they are separate programs. If you want to debug the server, you have to attach gdb to the server. PostgreSQL uses one process per connection, so you have to attach gdb to the correct server process. Which is why I said to use SELECT pg_backend_pid() above, and attach to the process ID.
See the internals documentation linked above, and:
PostgreSQL site - coding
PostgreSQL wiki - developer resources
Developer FAQ
Attaching gdb to a backend on linux/bsd/unix
I also faced similar issue and resolved it after some struggle
I misunderstood the following point under Debugging with child processes in the wiki (https://wiki.postgresql.org/wiki/Working_with_Eclipse).
5."Start postmaster & one instant of postgresql client (for creating one new postgres)"
The above step should be performed from terminal by starting postgres server and one client.
Hope this helps
Once this is done then debugger in eclipse needs to be started for C/C++ Attach to Application
Occassionally a query will continue to run even after I 'stop' it in pgAdmin, run pg_cancel_backend, pg_terminate_backend and kill from the command line. The only option I've found is to fully stop and restart the postgres service (generally using pg_ctl -m immediate). I'm currently using Postgres 9.1.
Are there other options to fully terminate a running process?
This shouldn't really be happening. What is the problem backend doing? Check:
ps -C postgres -o pid,ppid,stat,start,time,%cpu,%mem,blocked,ignored,wchan:80,cmd
replacing -C postgres with -p the_pid if you know it. Make sure to include the process name which appears after the wide chan line. Update your answer with the whole line.
You may also want to get a backtrace from the backend to see what it's doing. You're probably on Linux or BSD given kill, so try:
gdb -p the_pid
(gdb) bt
... blah blah copy this blah ...
(gdb) q
eg:
gdb -p 914
......blah blah ........
(gdb) bt
#0 0x0000003c31ceacc3 in __select_nocancel () from /lib64/libc.so.6
#1 0x00000000005f73b6 in ?? ()
#2 0x00000000005f7c36 in SysLogger_Start ()
#3 0x00000000005f60b0 in PostmasterMain ()
#4 0x0000000000457039 in main ()
(gdb) q
A debugging session is active.
Inferior 1 [process 914] will be detached.
Quit anyway? (y or n) y
Detaching from program: /usr/bin/postgres, process 914
If possible install debugging symbol packages first. I haven't for Pg 9.1 on my machine, so my backtrace above isn't very useful. See the Pg wiki article.
The backtrace could be very long, so consider dropping it on a pastebin site, not directly into your question, and just linking to it here.
Revisiting this, there are places where PostgreSQL backends are doing work where there's no CHECK_FOR_INTERRUPTS for some time. These patches are avoided where possible, but still happen.
If you find such a case, report it.
You can't cleanly stop the backend until it checks for an interrupt, so you must simply wait. Or you can restart the whole database server. If you hard kill the backend of interest with (e.g.) kill -9, PostgreSQL will treat shared_buffers as potentially corrupt and immediately force a restart, disconnecting all current sessions. So you might as well use an immediate shutdown instead.
I've a memory issue in an iPhone app that I'd like to debug with MallocStackLogging. The error involves the gyroscope so I have to debug on the device not the simulator.
I've set the MallocStackLogging environment variable and the iPhone properly records the mallock stack logs:
MyApp(1856) malloc: recording malloc stacks to disk using standard recorder
MyApp(1856) malloc: stack logs being written into /private/var/mobile/Applications/1FD1F8D2-5D30-4AA7-B426-C52FE20266DE/tmp/stack-logs.1856.MyApp.index
MyApp(1856) malloc: Please issue: cp /private/var/mobile/Applications/1FD1F8D2-5D30-4AA7- B426-C52FE20266DE/tmp/stack-logs.1856.MyApp.e8z3IL.link /tmp/
Now how can I work with them?
I can transfer them to the Mac using the Xcode Organizer. But what should I do with these two files?
stack-logs.1856.MyApp.index
stack-logs.1856.MyApp.e8z3IL.link
I tried moving the files in /tmp on the Mac and called:
$ malloc_history 1856 -all_events
malloc_history cannot examine process 1856 because the process does not exist.
Clearly, the malloc_history command looks for running processes on the local machine. I'm missing an option to specify the log file manually.
Is there any way to get this to work either directly working with Xcode on the (non-jailbroken) device or after transferring the logs to the Mac?
Here is how I debug APP with malloc stack history on idevice, it's really complicate, but I have no other way to deal with an auto release pool memory problem.
You need A jailbreak idevice with developer tools installed, then you have gdb.
To enable malloc stack loggin, you need set environment variables MallocStackLoggingNoCompact and MallocStackLogging, we need some trick to do it.
First, we need grant your app root privilege.
mv -f /User/Application/xxxxxxxxxxxxx/YOUR_APP.app /Application/YOUR_APP.app
cd /Application
chown -R root:wheel YOUR_APP.app
chmod 4755 YOUR_APP.app/YOUR_APP
Rename your program
mv YOUR_APP.app/YOUR_APP YOUR_APP.app/BACK_UP_NAME
Use a short shell scrip to start your program, so we can keep the env. Save it to YOUR_APP.app/YOUR_APP
#!/bin/bash
export MallocStackLogging=1
export MallocStackLoggingNoCompact=1
exec /Applications/YOUR_APP.app/BACK_UP_NAME
Done.
Just start you app, touching on the icon or use open command, you'll see a stack log file in /tmp
directory.
Use ps aux | grep YOUR_APP find process id, gdb -p PROCESS_ID attach to the progress, make a breakpoint, try info malloc ADDRESS, malloc history will show up.
In the Instruments application, which can diagnose an app running in the simulator or on a device, the Allocations instrument records memory addresses and allocation histories. You can browse by object/allocation type or specific memory address. This is likely the most straightforward way to accomplish what you want.
Running malloc_history on the device would require either jailbreaking to enable an ssh connection to the device, or running malloc_history from within your code. But I am not certain whether malloc_history exists on an iOS device. And malloc_history's help text does not mention an option for operating on log files rather than an existing process, which you likely already know.
I don't mean to sound flippant, but have you tried plugging the device in and running it under the debugger whilst connected ?
I do extensive debugging whilst runnning the application on the device. You do need to start the application under the debugger.