I'm trying to use Gstreamer in a C program.
I use udpsrc so I have to put caps :
GstCaps *caps = gst_caps_new_empty_simple("application/x-rtp");
With this, I get an Segmentation fault.
So, I've tried with G_DEBUG="fatal_warnings" gdb --args ./test_gst.
Here's the output :
Program received signal SIGSEGV, Segmentation fault.
0x76f010e4 in gst_mini_object_init (mini_object=0x28600, flags=0, type=0, copy_func=0x76ed6174 <_gst_caps_copy>, dispose_func=0x0, free_func=0x76ed5128 <_gst_caps_free>)
at gstminiobject.c:133
133 gstminiobject.c: No such file or directory.
(gdb) bt
#0 0x76f010e4 in gst_mini_object_init (mini_object=0x28600, flags=0, type=0, copy_func=0x76ed6174 <_gst_caps_copy>, dispose_func=0x0, free_func=0x76ed5128 <_gst_caps_free>)
at gstminiobject.c:133
#1 0x76ed57b4 in gst_caps_init (caps=0x28600) at gstcaps.c:209
#2 gst_caps_new_empty () at gstcaps.c:239
#3 0x76ed58f8 in gst_caps_new_empty_simple (media_type=0x110b4 "application/x-rtp") at gstcaps.c:282
#4 0x00010bbc in main ()
I don't know if this can help, but I'm working on a Raspberry PI 3 (raspbian).
I found a similar bug report with Segmentation fault in gst_mini_object_init(). According to this comment you should call gst_init() before using Gstreamer.
Did you call gst_init() before using Gstreamer API ?
Related
How to deal with SIGSEGV, Segmentation fault. while using Avx2 (_mm256_load_pd)(_mm256_store_pd)
(solved)
_mm256_load_pd
I've received segmentation fault wile called
_mm256_load_pd
usage are as blew
double * Val = malloc(sizeof(double)*4);
__m256d vecv = _mm256_load_pd(&Val[0]);
gdb shows
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fc5017 in _mm256_load_pd (__P=0x555555559370)
at /usr/lib/gcc/x86_64-linux-gnu/9/include/avxintrin.h:862
862 return *(__m256d *)__P;
(gdb) frame 1
#1 gemv_d_lineProduct_4_avx2 (Val=0x555555559370, indx=0x5555555592f0,
Vector_X=0x5555555592c0, Vector_Y=0x555555559340)
at someThing.c:114
114 __m256d vecv = _mm256_load_pd(&Val[0]);
(gdb)
_mm256_store_pd
while I make Val bigger
double * Val = malloc(sizeof(double)*4);
I found _mm256_load_pd works rightly but result in
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7fc50e3 in _mm256_store_pd (__A=..., __P=0x555555559390)
at /usr/lib/gcc/x86_64-linux-gnu/9/include/avxintrin.h:868
868 *(__m256d *)__P = __A;
(gdb) frame 1
#1 gemv_d_lineProduct_4_avx2 (Val=0x5555555593e0, indx=0x555555559310,
Vector_X=0x5555555592c0, Vector_Y=0x555555559390)
at something.c:122
122 _mm256_store_pd(Vector_Y,vecY);
full project
https://github.com/DevilInChina/gemv
mkdir build;cd build
cmake ..
make
cd ../bin
./line
#then might get some seg fault
Method of solving
change memory allocate function to
void *aligned_alloc (size_t __alignment, size_t __size);
first parameter should be 1024 or something else.
Thanks to igor-r
According to the Intel reference, _mm256_load_pd() requires 32-byte aligned pointer.
Please, use aligned_alloc() to allocate a memory chunk having the proper alignment.
I'm following the tutorial to adapt an acoustic model - https://cmusphinx.github.io/wiki/tutorialadapt/
When i ran the command:
sphinx_fe -argfile en-us/feat.params -samprate 16000 -c arctic20.fileids -di . -do . -ei wav -eo mfc -mswav yes
I get a Segmentation fault (core dumped) message and the program exits. My laptop runs on Ubuntu 16.04.
gdb output:
Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
and backtrace:
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x00007ffff7815980 in printf_positional (s=s#entry=0x7fffffffd0d0,
format=format#entry=0x403fb0 "Sample rate %.1f does not match configured
value in file '%s'\n", readonly_format=readonly_format#entry=0,
ap=ap#entry=0x7fffffffd248,
ap_savep=ap_savep#entry=0x7fffffffcc68, done=57, nspecs_done=1,
lead_str_end=0x403fbc "%.1f does not match configured value in file
'%s'\n",work_buffer=0x7fffffffcca0 "#\315\377\377\377\177", save_errno=17,
grouping=0x0,thousands_sep=0x7ffff7955b25 "") at vfprintf.c:2023
#2 0x00007ffff78164a6 in _IO_vfprintf_internal (s=s#entry=0x7fffffffd0d0,
format=,format#entry=0x403fb0 "Sample rate %.1f does not match configured
value in file '%s'\n", ap=ap#entry=0x7fffffffd248) at vfprintf.c:1677
#3 0x00007ffff78df896 in ___vsnprintf_chk ( s=s#entry=0x7fffffffd260
"Sample rate 0.0 does not match configured value in file '\200\272\367\377
\177", maxlen=, maxlen#entry=1024, flags=flags#entry=1,
slen=slen#entry=1024,
format=0x403fb0 "Sample rate %.1f does not match configured value in file
'%s'\n",
args=args#entry=0x7fffffffd248) at vsnprintf_chk.c:63
#4 0x00007ffff7ba80e8 in vsnprintf (__ap=0x7fffffffd248, __fmt=,
__n=1024,
__s=0x7fffffffd260 "Sample rate 0.0 does not match configured value in
file '\200\272\367\377\177") at /usr/include/x86_64-linux-gnu/bits/stdio2.h:77
#5 err_msg (lvl=lvl#entry=ERR_ERROR, path=path#entry=0x403a09
"sphinx_fe.c", ln=137,
fmt=) at err.c:96
#6 0x00000000004023a7 in detect_riff (wtf=0x60a080) at sphinx_fe.c:137
#7 0x00000000004035bc in detect_audio_type (wtf=0x60a080) at
sphinx_fe.c:750
#8 sphinx_wave2feat_convert_file (wtf=wtf#entry=0x60a080, infile=,
outfile=0x61ecc0 "./arctic_0001.mfc") at sphinx_fe.c:792
#9 0x0000000000401a14 in run_control_file (ctlfile=, wtf=0x60a080)
at sphinx_fe.c:992
#10 main (argc=, argv=) at sphinx_fe.c:1032
Anyone has a sugestion for me how to fix it?
The Solution is kind of simple,
the tutorial dont mention that the wav-files should be in 16-Bit format.
(Since audacity by default use a 32-Bit format i had to change that for my wav-files)
We're loading a symbol from a shared library via dlsym() under GNU/Linux and obviously get some kind of race condition resulting in a segmentation fault. The backtrace looks something like this:
(gdb) backtrace
#0 do_lookup_x at dl-lookup.c:366
#1 _dl_lookup_symbol_x at dl-lookup.c:829
#2 do_sym at dl-sym.c:168
#3 _dl_sym at dl-sym.c:273
#4 dlsym_doit at dlsym.c:50
#5 _dl_catch_error at dl-error.c:187
#6 _dlerror_run at dlerror.c:163
#7 __dlsym at dlsym.c:70
#8 ... (our code)
My local machine uses glibc-2.23.
I discovered, that the library handle given to __dlsym() in frame #7 is different to the handle passed to _dlerror_run(). It runs wild in the following lines in dlsym.c:
void *
__dlsym (void *handle, const char *name DL_CALLER_DECL)
{
# ifdef SHARED
if (__glibc_unlikely (_dlfcn_hook != NULL))
return _dlfcn_hook->dlsym (handle, name, DL_CALLER);
# endif
struct dlsym_args args;
args.who = DL_CALLER;
args.handle = handle; /* <------------------ this isn't my handle! */
args.name = name;
/* Protect against concurrent loads and unloads. */
__rtld_lock_lock_recursive (GL(dl_load_lock));
void *result = (_dlerror_run (dlsym_doit, &args) ? NULL : args.sym);
__rtld_lock_unlock_recursive (GL(dl_load_lock));
return result;
}
GDB says
(gdb) frame 7
#7 __dlsym at dlsym.c:70
(gdb) p *(struct link_map *)args.handle
$36 = {l_addr= 140736951484536, l_name = 0x7fffe0000078 "\300\215\r\340\377\177", ...}
so this is obviously garbage. The same occurs in the higher frames, e.g. in frame #2:
(gdb) frame 2
#2 do_sym at dl-sym.c:168
(gdb) p handle
$38 = {l_addr= 140736951484536, l_name = 0x7fffe0000078 "\300\215\r\340\377\177", ...}
Unfortunately the parameter handle in frame #7 can't be displayed:
(gdb) p handle
$37 = <optimized out>
but surprisingly in frame #8 and further down in our code the handle was correct:
(gdb) frame 8
#8 ...
(gdb) p *(struct link_map *)libHandle
$38 = {l_addr = 140737160646656, l_name = 0x7fffd8005b60 "/path/to/libfoo.so", ...}
Now my conclusion is, that the variable args must be modified during the execution inside __dlsym() but I can't see where and why.
I have to confess, there's a second aspect to this problem: It only occurs in a multi-threaded environment and only sometimes. But as you can see, there are some counter measures for race conditions in the implementation of __dlsym() since they're calling __rtld_lock_(un)lock_recursive() and the local variable args isn't shared across threads. And curiously enough, the problem still persists, if I make frame #8 mutual exclusive among my threads.
Questions: What are possible sources for the discrepancy in the library handle between frame #8 and frame #7?
Question 2: Does dlopen() yield different values for different threads? Or to put it differently: Is it possible to share the handles returned by dlopen() between different threads.
Update: I thank everybody commenting on this question and trying to answer it despite the lack of almost any viable information to do so. I found the solution of this problem. As foreseen by the commenters, it was totaly unrelated to the stacktraces and other information I provided. Hence, I consider this question as closed and will flag it for deletion. So Long, and Thanks for All the Fish
What are possible sources for the discrepancy in the library handle between frame #8 and frame #7?
The most likely cause is mismatch between ld-linux.so and libdl.so. As stated in this answer, ld-linux and libdl must come from the same build of GLIBC, or bad things will happen.
The mismatch can come from (A) trying to point to a different libc build via LD_LIBRARY_PATH, or (B) by static linking of libdl.a into the program.
The (gdb) info shared should show you which libraries are currently loaded. If you see something other than installed system ld-linux and libdl, then (A) is likely your problem.
For (B), you probably got (and ignored) a linker warning to the effect that your program will require at runtime the same libc version that you used to link it. Contrary to popular belief, fully-static binaries are less portable on Linux, not more.
gdb was reporting that my C code was crashing somewhere in malloc(), so I linked my code with Electric Fence to pinpoint the actual source of the memory error. Now my code is segfaulting much earlier, but gdb's output is even more confusing:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x30026b00 (LWP 4003)]
0x10007c30 in simulated_status (axis=1, F=0x300e7fa8, B=0x1003a520, A=0x3013b000, p=0x1003b258, XS=0x3013b000)
at ccp_gch.c:799
EDIT: The full backtrace:
(gdb) bt
#0 0x10007c30 in simulated_status (axis=1, F=0x300e7fa8, B=0x1003a520, A=0x3013b000, p=0x1003b258, XS=0x3013b000)
at ccp_gch.c:799
#1 0x10007df8 in execute_QUERY (F=0x300e7fa8, B=0x1003a520, iData=0x7fb615c0) at ccp_gch.c:836
#2 0x10009680 in execute_DATA_cmd (P=0x300e7fa8, B=0x7fb615cc, R_type=0x7fb615d0, iData=0x7fb615c0)
at ccp_gch.c:1581
#3 0x10015bd8 in do_volley (client=13) at session.c:76
#4 0x10015ef4 in do_dialogue (v=12, port=2007) at session.c:149
#5 0x10016350 in do_session (starting_port=2007, ports=1) at session.c:245
#6 0x100056e4 in main (argc=2, argv=0x7fb618f4) at main.c:271
The relevant code (slightly modified due to reasons):
796 static uint32_t simulated_status(
797 unsigned axis, struct foo *F, struct bar *B, struct Axis *A, BAZ *p, uint64_t *XS)
798 {
799 uint32_t result = A->status;
800 *XS = get_status(axis);
801 if (!some_function(p)) {
802 ...
The obvious thing to check would be whether A->status is valid memory, but it is. Removing the assignment pushes the segfault to line 800, and removing that assignment causes some other assignment in the if-block to segfault. It looks as though either accessing an argument passed to the function or writing to a local variable is what's causing the segfault, but everything points to valid memory according to gdb.
How am I to interpret this? I've never seen anything like this before, so any suggestions / pointers in the right direction would be appreciated. I'm using GNU gdb 6.8-debian, Electric Fence 2.1, and running on a PowerPC 405 (uname reports Linux powerpmac 2.6.30.3 #24 [...] ppc GNU/Linux).
I'm guessing, but your symptoms are similar to what could happen in a stack overflow situation. The -fstack-protector suggestion in the comments is on the right track here. I'd recommend adding the -fstack-check option as well.
If the SEGV is occurring because of writes to the guard page protecting the stack then an info registers and info frame in gdb would help confirm if this is the case.
I am using RSA_sign() to create dkim signatures. Sometimes , extremely unpredictably the code just crashes
I get a gdb dump like this
Thread 39 (Thread 0x41401940 (LWP 31921)):
#0 0x0000003b9dacc3bb in BN_div () from /lib64/libcrypto.so.6
#1 0x0000003b9daceb40 in BN_mod_inverse () from /lib64/libcrypto.so.6
#2 0x0000003b9dacb609 in BN_BLINDING_create_param () from /lib64/libcrypto.so.6
#3 0x0000003b9dadc9f7 in RSA_setup_blinding () from /lib64/libcrypto.so.6
#4 0x0000003b9daee954 in ?? () from /lib64/libcrypto.so.6
#5 0x0000003b9daef56b in ?? () from /lib64/libcrypto.so.6
#6 0x0000003b9da6e965 in RSA_sign () from /lib64/libcrypto.so.6
#7 0x0000000000403e7f in dkim_create (headers=0x2aaaac001840, headerc=7,
......., v=0) at firm-dkim.c:145
The firm-dkim.c is available here
http://code.google.com/p/firm-dkim/source/browse/trunk/firm-dkim.c
How can I debug this further ?
Thanks
Ram
Ok I think I got the error
The code over here
firm-dkim.c.
Does not allocate any memory for RSA *rsa_private , line 48
And this unallocated memory area is used in RSA_sign() and RSA_free()
I think that must be causing the segfault. I have alloc'ed memory now and I am running the daemon in production. Hopefully no more segfaults now.