Hey Héctor,
> We are using ModemManager 1.18.8 library and sometimes we got segmentation
> fault when calling mm_object_get_modem function. It happens from time to
> time, no clues about circumstances, as our code is continuously inquiring
> for modem object in this function:
>
>
>
> MMModemPtr ModemManagerFacade::getModemPtr(const std::string &imei)
>
> {
>
> MMObject *object = getObject(imei);
>
> if (object == nullptr) {
>
> return MMModemPtr(nullptr, &g_object_unref);
>
> }
>
>
>
> return MMModemPtr(mm_object_get_modem(object), &g_object_unref);
>
> }
>
>
>
> It returns a MMModemPtr type, which is a unique pointer:
>
> using MMModemPtr = std::unique_ptr<MMModem, decltype(&g_object_unref)>;///<
> MMModem Unique pointer with custom deleter
>
>
>
> and it’s checked every time that function is called as in:
>
> MMModemPtr modem = getModemPtr(imei);
>
> if (modem == nullptr) {
>
> return DPY_UNAVAILABLE;
>
> }
>
>
>
> MMobject is stored in a map
>
> std::map<std::string, MMObject*> mImeiToObjectMap;
>
>
>
> and obtained in
>
> MMObject* ModemManagerFacade::getObject(std::string imei)
>
> {
>
> /* Some previous checkings …
>
> …and*/
>
> auto it = mImeiToObjectMap.find(imei);
>
> if (it == mImeiToObjectMap.end()) {
>
> return nullptr;
>
> }
>
> return (it->second);
>
> }
>
>
>
> But I don’t think MMobject pointer is the problem as it’s checked inside
> mm_object_get_modem function:
>
> MMModem *
>
> mm_object_get_modem (MMObject *self)
>
> {
>
> MMModem *modem;
>
>
>
> g_return_val_if_fail (MM_IS_OBJECT (MM_GDBUS_OBJECT (self)), NULL);
>
>
>
> modem = (MMModem *)mm_gdbus_object_get_modem (MM_GDBUS_OBJECT (self));
>
> g_warn_if_fail (MM_IS_MODEM (modem));
>
> return modem;
>
> }
>
>
>
> and the backtrace shows that the program terminates after calling
> mm_gdbus_object_get_modem
>
>
>
> Program terminated with signal SIGSEGV, Segmentation fault.
>
> #0 0x0000ffffad048ab8 in g_hash_table_lookup () from
> /usr/lib/libglib-2.0.so.0
>
> [Current thread is 1 (LWP 10802)]
>
> (gdb) bt
>
> #0 0x0000ffffad048ab8 in g_hash_table_lookup () from
> /usr/lib/libglib-2.0.so.0
>
> #1 0x0000ffffad2f5824 in ?? () from /usr/lib/libgio-2.0.so.0
>
#2 0x0000ffffad4629dc in mm_gdbus_object_get_modem () from
> /usr/lib/libmm-glib.so.0
>
> #3 0x0000ffffad422e2c in mm_object_get_modem () from
> /usr/lib/libmm-glib.so.0
>
> #4 0x0000aaaabff73124 in
> ModemManagerFacade::getModemPtr(std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&) ()
>
> #5 0x0000aaaabff745f0 in
> ModemManagerFacade::getDominantTechnologySignalQuality(std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> > const&,
> dpyModem::SignalQuality&, bool&) ()
>
> #6 0x0000aaaabff5d97c in ModemManagerDevice::update_signalQuality() ()
>
> #7 0x0000aaaabffbb050 in ModemSupervisor::updateModemParameters() ()
>
> #8 0x0000aaaabffbbc44 in
> ModemSupervisor::checkModemStatus(boost::system::error_code const&,
> dpyModem::ModemState) ()
>
> #9 0x0000aaaabffbcfe8 in
> boost::asio::detail::wait_handler<boost::_bi::bind_t<void,
> boost::_mfi::mf2<void, ModemSupervisor, boost::system::error_code const&,
> dpyModem::ModemState>,
> boost::_bi::list3<boost::_bi::value<ModemSupervisor*>, boost::arg<1> (*)(),
> boost::_bi::value<dpyModem::ModemState> > > >::do_complete(void*,
> boost::asio::detail::scheduler_operation*, boost::system::error_code
> const&, unsigned long) ()
>
> #10 0x0000aaaabff0de38 in
> boost::asio::detail::scheduler::do_run_one(boost::asio::detail::conditionally_enabled_mutex::scoped_lock&,
> boost::asio::detail::scheduler_thread_info&, boost::system::error_code
> const&) ()
>
> #11 0x0000aaaabffe704c in
> ModemService::operator()(boost::application::basic_context&) ()
>
> #12 0x0000aaaabffd019c in int
> boost::application::launch<boost::application::common,
> boost::application::auto_handler<ModemService>,
> boost::application::basic_context>(boost::application::auto_handler<ModemService>&,
> boost::application::basic_context&, boost::system::error_code&) ()
>
> #13 0x0000aaaabfedc9a0 in main ()
>
>
>
> Any ideas about why this can be happening? Has it ever been seen before?
>
i'd bet this is some memory corruption happening somewhere. Is the issue
easily reproducible? maybe you can prepare a small reproducer program that
triggers this issue for us to analyze? Otherwise, I suggest you try to run
under valgrind to see if you get any memory related issues reported there.
The only thing I can say about this issue is that I don't recall anything
similar to this reported lately in the past years. libmm-glib is used by
multiple other projects, so there's a high chance that the issue is indeed
a memory corruption somewhere in your project. Maybe a double free, or a
use-after-free, or something like that.
Also please note that the g_return_if_fail() calls may be disabled in the
build! you should ensure these are being used in your build before assuming
they're being called.
Sorry I cannot help more :/
--
Aleksander
