Segmentation fault in pg_dump utility from PostgreSQL 9.2.3 - gdb

I am using PostgreSQL 9.2.3 in my development board,I am taking backup of database using following command and get segmentation fault.
/bin/pg_dump -U db_admin -t mytable -b -C -Ft MYDB|gzip >/home/mydb.tar.gz
I have analyzed dump core using gdb and found that pg_dump gives segmentation from dopr() function
gdb output
(gdb)bt
#0 0x00429c4c in dopr ()
#1 0x0042acda in pg_sprintf ()
#2 0x004249fc in _tarAddFile ()
#3 0x00424d88 in tarClose ()
#4 0x004259a0 in _CloseArchive ()
#5 0x0041e712 in CloseArchive ()
#6 0x0041862e in main ()
(gdb)
Please let me know if anyone found solution for this problem.

Related

gcc 7.3 LTO (-flto) crash (SIGSEGV) on exit () / static variable?

I had an old app that I need to maintain. Thousands of lines of code.
When I switched to the gcc 7.3 compiler and I enabled -flto application started to crash o exit:
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x1ee0c6b0 in ?? () from /lib/libc.so.6
#2 0x1ee0c840 in exit () from /lib/libc.so.6
#3 0x1edf0d5c in ?? () from /lib/libc.so.6
#4 0x1edf0f10 in __libc_start_main () from /lib/libc.so.6
#5 0x00000000 in ?? ()
When I removed -flto option app stopped crashing.
I've traced that unused static variable in a body of one of functions caused the problem:
static std::vector<C_Param*> vpParam;
When I removed 'static' or removed variable at all app stopped crashing.
This is very strange to me because the variable is not used and only happens with the -flto option.
What could be the main cause?

GDB produce ?? symbols for segmentaion fault on ubuntu

I am trying to debug my c++ programming assignment application using gdb on an Ubuntu server, because it produces segmentation fault.
But the file produces ?? symbols that are unreadable to me when I try bt it gives me.
(gdb) bt
#0 0x00007f141956d277 in ?? ()
#1 0x00007ffc1a866bd0 in ?? ()
#2 0x000055e1f101d5e0 in ?? ()
#3 0x00007ffc1a866db0 in ?? ()
#4 0x000055e1f1433e70 in ?? ()
#5 0x00007ffc1a866bd0 in ?? ()
#6 0x000055e1f10224a9 in ?? ()
#7 0x000055e1f14341f8 in ?? ()
#8 0x00000001f14344d0 in ?? ()
#9 0x0000000000000000 in ?? ()
I was following this link, and it told me to load these symbols
symbol-file /path/to/my/binary
sharedlibrary
The sharedlibrary was found, but the symbol-file path is not there. So,it did change bt command output somehow
(gdb) bt
#0 tcache_get (tc_idx=0) at malloc.c:2943
#1 _GI__libc_malloc (bytes=19) at malloc.c:3050
#2 0x000055e1f10224a9 in ?? ()
#3 0x000055e1f14341f8 in ?? ()
#4 0x00000001f14344d0 in ?? ()
#5 0x0000000000000000 in ?? ()
I still don't understand the bug.
Now, I don't know it's a problem from the GDB for not having this symbol-file or its a compilation problem which I don't know how or that's enough for me to debug, but I was following Debugging a Segmentation Fault and it was much clearer to troubleshoot.
When I search for similar cases, all of them were answered only for their case, not a general solution how to deal with these kinds of error. I also thought of installing or locating that symbol-file but I didn't understand how.
If someone could help me, I need to understand what is my problem and how should I fix it.
Note: core dump is produced in the /tmp not in current application directory
I was following this link, and it told me to load these symbols
Don't follow this link (it's unnecessarily complicated for your use case).
Instead, do this:
gdb /path/to/my/binary
(gdb) run
... GDB will stop when your program encounters SIGSEGV
(gdb) bt # should produce meaningful output now.

GDB shows more number of backtraces (90) for my core file

GDB 7.7 shows more number of backtraces (90) for my core file. It is problem with GDB or core file or stack corruption issue?
(gdb) bt
Python Exception exceptions.ImportError No module named traceback:
#0 0x00007f422fd04c37 in ?? () from /users/jegan/lib/x86_64-linux-gnu/libc.so.6
#1 0x0000000000002929 in ?? ()
#2 0x7328203c20746e63 in ?? ()
.......................
......................
#88 0x544143494649544e in ?? ()
#89 0x29295d305b4e4f49 in ?? ()
#90 0x0000000000000000 in ?? ()
(gdb)
GDB 7.7 shows more number of backtraces (90) for my core file.
There are a few likely causes for this:
You didn't invoke GDB correctly, or
You are analysing a core dump on a different host from the one it was produced on (or the same host has had its system libraries updated).
Answer for #1.
Answer for #2.

GDB reports a crash but program runs fine

I have a program that when I run from terminal (wihtout GDB) prints some outputs. Assume the output looks like
welcome to CMP simulator
initializing
finish initialization
now run
goodbye
Now, when I want to use GDB, the program gives a PID and I use that to attach to GDB. Assume the output of the program now looks like
welcome to CMP simulator
gdb - 5932 (Run this command on another terminal and type "continue" at GDB prompt)
While the program waits for SIGCONT, I run gdb - 5932 on anther terminal. As I type "continue", GDB reports a crash like this:
Loaded symbols for /home/mahmood/results/temp/libCMP_iface_gcc.so
0x00007fd3a499fb7b in raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
42 ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
(gdb) c
Continuing.
Program received signal SIGSTOP, Stopped (signal).
[Switching to Thread 0x7fd3a343f700 (LWP 21014)]
0x00007fd3a408e303 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>)
at ../sysdeps/unix/sysv/linux/poll.c:87
87 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) bt
#0 0x00007fd3a408e303 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>)
at ../sysdeps/unix/sysv/linux/poll.c:87
#1 0x00007fd3a4c0fc4c in ?? () from /home/mahmood/simics-3.0.31/amd64-linux/bin/libsimics-common.so
#2 0x00007fd3a4997e9a in start_thread (arg=0x7fd3a343f700) at pthread_create.c:308
#3 0x00007fd3a4099cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4 0x0000000000000000 in ?? ()
(gdb)
At this point, the program still is waiting for SIGCONT.
What does the back trace means?
As you can see without GDB, the program prints more line on the output. However GDB shows a crash. My guess is that there is a problem with creating thread.
Any feedback is appreciated.
UPDATE:
If I ran "continue" again, I see the same output on GDB
(gdb) c
Continuing.
Program received signal SIGSTOP, Stopped (signal).
0x00007f09b653c303 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout= <optimized out>)
at ../sysdeps/unix/sysv/linux/poll.c:87
87 in ../sysdeps/unix/sysv/linux/poll.c
(gdb) bt
#0 0x00007f09b653c303 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>)
at ../sysdeps/unix/sysv/linux/poll.c:87
#1 0x00007f09b70bdc4c in ?? () from /home/mahmood/simics-3.0.31/amd64-linux/bin/libsimics-common.so
#2 0x00007f09b6e45e9a in start_thread (arg=0x7f09b58ed700) at pthread_create.c:308
#3 0x00007f09b6547cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4 0x0000000000000000 in ?? ()
(gdb)
The system is ubuntu 12.04 amd64
GDB isn't showing a crash, a SIGSTOP just means the program wasa stopped and you just have to continue it using gdb command 'continue' or just asking to GDB to send the signal using 'sig SIGCONT'
I hope I help you.
pt-raise.c: No such file or directory
This error can be fixed by rebuilding gdb from sources

produce "_Unwind_Resume" call seeing under gbd backtracing

Here is the problem which I'm trying to address:
We've got a core dump while processing data. The result of backtracing is:
#0 0x00a99402 in __kernel_vsyscall ()
#1 0x00306df0 in raise () from /lib/libc.so.6
#2 0x00308701 in abort () from /lib/libc.so.6
#3 0x001c4530 in _gnu_cxx::_verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#4 0x001c1f35 in ?? () from /usr/lib/libstdc++.so.6
#5 0x001c12ca in ?? () from /usr/lib/libstdc++.so.6
#6 0x001c1d99 in __gxx_personality_v0 () from /usr/lib/libstdc++.so.6
#7 0x00d1c7e6 in ?? () from /lib/libgcc_s.so.1
#8 0x00d1cb62 in _Unwind_Resume () from /lib/libgcc_s.so.1
........
I've looked through the code base of our application and it is not clear that the problem is due to uncaught exception or whatever (but i know it somehow connected with exceptions because of _Unwind_Resume call is there). So I'm trying to write simple program which also fails with core dump and its gdb backtracing contains the lines above.
os: CentOS, compiler: gnu gcc 4.1.2, language: c/c++
Any suggestions about the problem/code would be much appreciated