dlopen core dumped when play sound - c++

I got a core dump on embeded linux platform when playing sound.
I used QT for GUI, the callstack is:
Program terminated with signal 11, Segmentation fault.
#0 0x411740e4 in dlopen () from /lib/libdl.so.0
(gdb) bt
#0 0x411740e4 in dlopen () from /lib/libdl.so.0
#1 0x40194a04 in snd_dlopen () from /nand/usr/lib/libasound.so.2
#2 0x40190cc8 in ?? () from /nand/usr/lib/libasound.so.2
(gdb) thread apply all bt
Thread 7 (process 511):
#0 0x405e15c8 in ?? () from /nand/usr/lib/libQtGui.so.4
Cannot access memory at address 0x2
Thread 6 (process 538):
#0 0x410dda1c in read () from /lib/libc.so.0
#1 0x40fdbe14 in read () from /lib/libpthread.so.0
#2 0x4014b924 in SysUtil_GetALSEventValue () at ALSPSensor.cpp:46
#3 0x00040af0 in ALSensor::operateBackLight (this=<value optimized out>) at src/PALSSensorHandle.cpp:97
#4 0x00040c04 in ALSensor::run (this=0x12a218) at src/PALSSensorHandle.cpp:76
#5 0x40d4d4f8 in ?? () from /nand/usr/lib/libQtCore.so.4
Thread 5 (process 537):
#0 0x410dda1c in read () from /lib/libc.so.0
#1 0x40fdbe14 in read () from /lib/libpthread.so.0
#2 0x4014b5fc in SysUtil_GetPSEventValue () at ALSPSensor.cpp:163
#3 0x00040c54 in PSensor::operateBackLight (this=<value optimized out>) at src/PALSSensorHandle.cpp:83
#4 0x00040d20 in PSensor::run (this=0x11ecf8) at src/PALSSensorHandle.cpp:66
#5 0x40d4d4f8 in ?? () from /nand/usr/lib/libQtCore.so.4
Thread 4 (process 536):
#0 0x4117e730 in mq_receive () from /lib/librt.so.0
#1 0x40219fa4 in BidirctMsgQueue::get (this=0x130ba8, msg_len=0xbe5ffd3c) at BidirctMsgQueue.cpp:56
#2 0x0003fb0c in MqReceiver::run (this=0x12b270) at src/MqReceiver.cpp:45
#3 0x40d4d4f8 in ?? () from /nand/usr/lib/libQtCore.so.4
Thread 3 (process 535):
#0 0x410ddfd8 in select () from /lib/libc.so.0
#1 0x4009897c in ipc_block_recv (sock=27, recv_message=0xbe7ffc90) at ipc.cpp:123
#2 0x40022c74 in CSipMsgControl::InitSipMsg (this=0x145ea8) at sipmsgcontrol.cpp:170
#3 0x40022cb8 in CSipMsgControl::run (this=0xfffffdfe) at sipmsgcontrol.cpp:119
#4 0x40d4d4f8 in ?? () from /nand/usr/lib/libQtCore.so.4
Thread 2 (process 534):
#0 0x410dd5ac in poll () from /lib/libc.so.0
#1 0x40fd87d4 in __pthread_manager () from /lib/libpthread.so.0
Backtrace stopped: frame did not save the PC
Thread 1 (process 1416):
#0 0x411740e4 in dlopen () from /lib/libdl.so.0
#1 0x40194a04 in snd_dlopen () from /nand/usr/lib/libasound.so.2
#2 0x40190cc8 in ?? () from /nand/usr/lib/libasound.so.2
(gdb)

Related

Segmentation Fault with SOCI rowset

I get a segmentation fault when using SOCI rowset. Here is a simplified version of my code:
query << "select * from mytable";
soci::rowset<MyObject> rs = (sql.prepare << query.str());
Here is an excerpt from gdb:
Thread 3 "MyProgram" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffef14c700 (LWP 15369)]
0x00007ffff6b73428 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff6b73428 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff6b7502a in __GI_abort () at abort.c:89
#2 0x00007ffff6bc0503 in malloc_printerr (ar_ptr=<optimized out>, ptr=<optimized out>, str=<optimized out>, action=<optimized out>) at malloc.c:5010
#3 _int_malloc (av=av#entry=0x7ffff6f02b20 <main_arena>, bytes=bytes#entry=33) at malloc.c:3386
#4 0x00007ffff6bc0e59 in malloc_check (sz=32, caller=<optimized out>) at hooks.c:295
#5 0x0000000001307668 in operator new(unsigned long) ()
#6 0x0000000001298b25 in soci::postgresql_statement_backend::make_into_type_backend() ()
#7 0x00000000012941b4 in soci::details::standard_into_type::define(soci::details::statement_impl&, int&) ()
#8 0x000000000128fd13 in soci::details::statement_impl::define_for_row() ()
#9 0x0000000001292be8 in soci::details::statement_impl::execute(bool) ()
#10 0x0000000000db420a in soci::statement::execute (this=0x3d261d0, withDataExchange=false) at /usr/include/soci/statement.h:210
#11 0x0000000001076d46 in soci::details::rowset_impl<MyObject>::rowset_impl (this=0xb027c80, prep=...) at /usr/include/soci/rowset.h:126
#12 0x0000000001072fb1 in soci::rowset<sim_mob::SinglePath>::rowset (this=0x7fffef14a890, prep=...) at /usr/include/soci/rowset.h:185

Gstreamer warning GStreamer-CRITICAL **: _gst_util_uint64_scale_int: assertion 'num >= 0' failed

I develop an audio player which uses following Gstreamer pipeline:
appsrc ! mpegaudioparse ! queue ! mad ! volume ! audioconvert ! audioresample ! autoaudiosink
The application works. However, sometimes it notifies some annoying warning messsages as follows:
GStreamer-CRITICAL **: _gst_util_uint64_scale_int: assertion 'num >= 0' failed
xcb_connection_has_error() returned true
I don't call the gst_util_uint64_scale_int() in my application.
Here is version of Gstreamer and plugin I used:
gstreamer1.0(1.8.3)
gstreamer1.0-plugins-base(1.8.3)
gstreamer1.0-plugins-good(1.8.3)
gstreamer1.0-plugins-ugly(1.8.3)
gstreamer1.0-alsa(1.8.3)
gstreamer1.0-pulseaudio(1.8.3)
I already spent much time to solve this issue but have not found out the cause.
If anybody knows a reason of these warning messages, please help.
Update #2: When I set GST_DEBUG=fatal_criticals and run my player inside GDB, I got following stack trace:
[New Thread 0xaa01cb40 (LWP 22656)]
Thread 149 "source:src" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0xab82fb40 (LWP 22655)]
0xb7878749 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0
(gdb) backtrace
#0 0xb7878749 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0
#1 0xb7878805 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0
#2 0xb7878839 in g_return_if_fail_warning () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3 0xb7a53ed6 in ?? () from /usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#4 0xb7545910 in gst_base_parse_push_frame () from /usr/lib/i386-linux-gnu/libgstbase-1.0.so.0
#5 0xb7549fbd in gst_base_parse_finish_frame () from /usr/lib/i386-linux-gnu/libgstbase-1.0.so.0
#6 0xb518158e in ?? () from /usr/lib/i386-linux-gnu/gstreamer-1.0/libgstaudioparsers.so
#7 0xb75419f5 in ?? () from /usr/lib/i386-linux-gnu/libgstbase-1.0.so.0
#8 0xb7546a67 in ?? () from /usr/lib/i386-linux-gnu/libgstbase-1.0.so.0
#9 0xb7a169df in ?? () from /usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#10 0xb7a1e98c in gst_pad_push () from /usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#11 0xb755f393 in ?? () from /usr/lib/i386-linux-gnu/libgstbase-1.0.so.0
#12 0xb7a497ca in ?? () from /usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#13 0xb7a4a767 in ?? () from /usr/lib/i386-linux-gnu/libgstreamer-1.0.so.0
#14 0xb7899a64 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#15 0xb789900a in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#16 0xb7814295 in start_thread (arg=0xab82fb40) at pthread_create.c:333
#17 0xb7d50eee in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:114
(gdb)

Boost iostreams long time to open memory mapped file

When I call open on a boost::iostreams::mapped_file_source my program hangs for around two minutes. I tried attaching gdb to the process at this point and the backtrace shows
(gdb) backtrace
#0 0x00007f779226687a in mmap64 () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f7793c60f58 in boost::iostreams::detail::mapped_file_impl::try_map_file(boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>) () from /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0
#2 0x00007f7793c61028 in boost::iostreams::detail::mapped_file_impl::map_file(boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>&) () from /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0
#3 0x00007f7793c614d2 in boost::iostreams::detail::mapped_file_impl::open(boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path>) () from /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0
#4 0x00007f7793c6168e in boost::iostreams::mapped_file_source::open_impl(boost::iostreams::basic_mapped_file_params<boost::iostreams::detail::path> const&) () from /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0
#5 0x0000000000e07f86 in boost::iostreams::mapped_file_source::open<boost::iostreams::detail::path> (this=this#entry=0x1db63f8, p=...) at /usr/include/boost/iostreams/device/mapped_file.hpp:406
#6 0x0000000000e08011 in boost::iostreams::mapped_file_source::open<boost::filesystem::path> (this=this#entry=0x1db63f8, path=..., length=length#entry=18446744073709551615, offset=offset#entry=0)
at /usr/include/boost/iostreams/device/mapped_file.hpp:416
Why is the call to open so slow here? Shouldn't it return quickly here?

GDB: stepping into a library

Runnning my application I get a Segmentation fault. I ran gdb to check where my code was failing but I get the following output:
Program received signal SIGSEGV, Segmentation fault.
0x39ca8000 in ?? ()
(gdb) bt
#0 0x39ca8000 in ?? ()
#1 0xb7d5df9a in sc_core::sc_port_base::complete_binding() () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#2 0xb7d5e104 in sc_core::sc_port_registry::complete_binding() () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#3 0xb7d5e13e in sc_core::sc_port_registry::elaboration_done() () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#4 0xb7dc669d in sc_core::sc_simcontext::elaborate() () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#5 0xb7dc8567 in sc_core::sc_simcontext::initialize(bool) () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#6 0xb7dc8b19 in sc_core::sc_simcontext::simulate(sc_core::sc_time const&) () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#7 0xb7dc9708 in sc_core::sc_start(sc_core::sc_time const&) () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#8 0x080555a8 in sc_core::sc_start (duration=40000, time_unit=sc_core::SC_MS) at /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h:608
#9 0x08055119 in sc_main (argc=1, argv=0xbffff524) at module_pfn.cpp:49
#10 0xb7dbc698 in sc_elab_and_sim () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#11 0xb7d522e7 in main () from /opt/systemc-2.2-rel/lib/libsystemc.so.2.2
#12 0xb7a2e4d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#13 0x08054da1 in _start ()
As you can see, everything comes from a library, except the 'main' call and 'start',where I set breakpoints, but they fail immediately there. I mean:
#8 0x080555a8 in sc_core::sc_start (duration=40000, time_unit=sc_core::SC_MS) at /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h:608
#9 0x08055119 in sc_main (argc=1, argv=0xbffff524) at module_pfn.cpp:49
...
(gdb) br /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h:608
Breakpoint 2 at 0x8055584: file /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h, line 608.
(gdb) r
Starting program: /home/guest/Solutions/eln/systemc-ams/module_pfn
...
Breakpoint 2, sc_core::sc_start (duration=40000, time_unit=sc_core::SC_MS) at /opt/systemc-2.2-rel/include/sysc/kernel/sc_simcontext.h:608
608 sc_start( sc_time( duration, time_unit ) );
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x39ca8000 in ?? ()
And we go back to the start.
I am not able to understand where this is failing. I see there is the name of the place in which this is failing: sc_core::sc_port_base::complete_binding() and I have access to the cpp where this function can be found, but only in the source files (not the library). The problem is that I would really like to go step by step through that code, is it possible?
Thanks :)
Thanks guys!
I used a library with debug info and now I can go through the library code.

Using Gdb debugger, how should I proceed to find out the cause of "Program terminated with signal 11, Segmentation fault."

Here is the backtrace of gdb,
Program terminated with signal 11, Segmentation fault.
#0 0xb7e78830 in Gtk::Widget::get_width () from /usr/lib/libgtkmm-2.4.so.1
(gdb) bt
#0 0xb7e78830 in Gtk::Widget::get_width () from /usr/lib/libgtkmm-2.4.so.1
#1 0x08221d5d in sigc::bound_mem_functor0<bool, videoScreen>::operator() (this=0xb1c04714)
at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787`enter code here`
#2 0x08221d76 in sigc::adaptor_functor<sigc::bound_mem_functor0<bool, videoScreen> >::operator() (this=0xb1c04710)
at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:251
#3 0x08221d96 in sigc::internal::slot_call0<sigc::bound_mem_functor0<bool, videoScreen>, bool>::call_it (rep=0xb1c046f8)
at /usr/include/sigc++-2.0/sigc++/functors/slot.h:103
#4 0xb7b1ed35 in ?? () from /usr/lib/libglibmm-2.4.so.1
#5 0xb73c6bb6 in ?? () from /usr/lib/libglib-2.0.so.0
#6 0xb28ff1f8 in ?? ()
#7 0xb647479c in __pthread_mutex_unlock_usercnt () from /lib/libpthread.so.0
#8 0xb73c6446 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#9 0xb73c97e2 in ?? () from /usr/lib/libglib-2.0.so.0
#10 0xb3d11af8 in ?? ()
#11 0x00000000 in ?? ()
I figured out the line of crash,here is the code around that line.
1:currPicLoaded = 1;
2:int status = -1;
3:zoomedPicWidth = drawVideo1->get_width();
I figured out that above line is 3 is the cause of crash, but this line execute 5 times before crash.So I do not know why it does crash at 6th time.
PS : Above line of code is with in a thread which run continuously.
Any help is more than welcome :)
how should I proceed
Your very first step should be to find out which instruction caused the SIGSEGV. Do this:
(gdb) x/i $pc
The most likely cause is that your drawVideo1 object is either dangling (has been deleted), or is corrupt in some other way.
Since you are apparently on Linux (you didn't say, but you should always say), the first tool to reach for for debugging "strange" problems like this is Valgrind.