If device probe and removal happen in short succession, it's possible
that the idle handler registered in the probe function doesn't run before
the device is removed. In this case, the idle handler needs to be
unregistered so that it does not run and try to access the data that's
destroyed during the removal.
We might have mis-interpreted how 27.007 intends for CBS to work. After
studying the implementation notes of the IMC 6260 modem, the spec intent
made a little bit more sense.
Delay registering DBus.Properties interface until the moment there are
properties on that path. This is needed for objects that currently don't
expose any property to not export the interface.
The newer IFX firmware was changed, it no longer accepts AT commands
until the UA frame has been sent back to the AP. The commands are
simply dropped on the floor. This requires a proper fix in GAtMux, but
until then simply bump up the timeout to get around this issue.
During STK Set Up Call, we have modem-originated calls that do not go
through the core 'Dial' method. Make sure the calls are still detected
in this case.
Set Up Call with extra DTMF characters after the phone number should be
set up with only the dialed number. Otherwise we get a sequence like
this:
{VoiceCallManager} [CallAdded] /ifx_0/voicecall01 { LineIdentification =
+012340123456c1c2, Name = , Emergency = False, Multiparty = False,
RemoteHeld = False, State = alerting, RemoteMultiparty = False }
ofonod[32055]: ++++++++ backtrace ++++++++
ofonod[32055]: #0 0x7f6af0ee3b30 in /lib64/libc.so.6
ofonod[32055]: #1 0x4c2466 in __ofono_watchlist_remove_item() at
src/watch.c:57
ofonod[32055]: #2 0x4b5b73 in ofono_sim_remove_spn_watch() at
src/sim.c:2715
ofonod[32055]: #3 0x497c30 in netreg_unregister() at src/network.c:1817
ofonod[32055]: #4 0x4912e1 in __ofono_atom_unregister() at
src/modem.c:277
ofonod[32055]: #5 0x491387 in flush_atoms() at src/modem.c:425
ofonod[32055]: #6 0x4b6cb8 in __ofono_sim_refresh() at src/sim.c:3154
ofonod[32055]: #7 0x4b8c41 in handle_command_refresh() at
src/stk.c:2302
ofonod[32055]: #8 0x4baf0d in
ofono_stk_proactive_command_handled_notify() at src/stk.c:3048
ofonod[32055]: #9 0x46c60f in satn_notify() at
drivers/ifxmodem/stk.c:229
ofonod[32055]: #10 0x7f6af1711455 in /usr/lib64/libglib-2.0.so.0
ofonod[32055]: #11 0x43e729 in at_chat_match_notify() at
gatchat/gatchat.c:421
ofonod[32055]: #12 0x440da8 in received_data() at gatchat/gatio.c:125
ofonod[32055]: #13 0x441834 in dispatch_sources() at
gatchat/gatmux.c:157
ofonod[32055]: #14 0x441bbd in received_data() at gatchat/gatmux.c:215
ofonod[32055]: #15 0x7f6af173dfc3 in /usr/lib64/libglib-2.0.so.0
ofonod[32055]: #16 0x7f6af16ef065 in /usr/lib64/libglib-2.0.so.0
ofonod[32055]: #17 0x7f6af16efd0f in /usr/lib64/libglib-2.0.so.0
ofonod[32055]: #18 0x7f6af16efef9 in /usr/lib64/libglib-2.0.so.0
ofonod[32055]: #19 0x7f6af16f032f in /usr/lib64/libglib-2.0.so.0
ofonod[32055]: #20 0x48f5f8 in main() at src/main.c:249
ofonod[32055]: #21 0x7f6af0ed04bd in /lib64/libc.so.6
ofonod[32055]: +++++++++++++++++++++++++++
When performing a SIM REFRESH, particularly NAA Initialization, we need
to wait until the modem sends XSIMSTATE: 7, not XSIMSTATE:2. Even on
normal initialization it seems safer to wait until XSIMSTATE:2.
When modem is brought online, then sim removed and re-inserted. We
crash when going online again due to the spn related data-structures not
being initialized properly
Since these are simple #define strings, we are defining it here
instead of upgrading to D-Bus 1.5 or later.
Log:
CC gdbus/object.o
gdbus/object.c: In function ‘properties_set’:
gdbus/object.c:876:7: error: ‘DBUS_ERROR_UNKNOWN_PROPERTY’ undeclared
(first use in this function)
gdbus/object.c:876:7: note: each undeclared identifier is reported
only once for each function it appears in
gdbus/object.c:881:6: error: ‘DBUS_ERROR_PROPERTY_READ_ONLY’
undeclared (first use in this function)
make[1]: *** [gdbus/object.o] Error 1
make: *** [all] Error 2
The reply to a DBus.Properties.Set() method call should go through the
same D-Bus connection. Thus remove the DBusConnection parameter from the
following functions:
- g_dbus_pending_property_success()
- g_dbus_pending_property_error_valist()
- g_dbus_pending_property_error()
If an interface is removed from the root path during the same mainloop
iteration that it was added we need to check for data->added before
doing the check for data->parent == NULL in the remove_interface()
function. Otherwise the added interface doesn't get removed from the
data->added list and will result in accessing freed memory:
==337== Invalid read of size 8
==337== at 0x4F65AFA: dbus_message_iter_append_basic (in /usr/lib64/libdbus-1.so.3.7.1)
==337== by 0x1247B5: append_interface (object.c:556)
==337== by 0x4C8DC5C: g_slist_foreach (gslist.c:840)
==337== by 0x1261F7: process_changes (object.c:594)
==337== by 0x126372: generic_unregister (object.c:997)
==337== by 0x4F69669: ??? (in /usr/lib64/libdbus-1.so.3.7.1)
==337== by 0x4F5CE51: dbus_connection_unregister_object_path (in /usr/lib64/libdbus-1.so.3.7.1)
==337== by 0x125E81: object_path_unref (object.c:1236)
==337== by 0x126136: g_dbus_unregister_interface (object.c:1361)
==337== by 0x14CDF0: service_exit (service.c:581)
==337== by 0x177556: plugin_cleanup (plugin.c:242)
==337== by 0x12221F: main (main.c:559)
==337== Address 0x5bc1550 is 0 bytes inside a block of size 56 free'd
==337== at 0x4A079AE: free (vg_replace_malloc.c:427)
==337== by 0x4C7850E: g_free (gmem.c:252)
==337== by 0x125DB0: remove_interface (object.c:671)
==337== by 0x125E3B: object_path_unref (object.c:1230)
==337== by 0x126136: g_dbus_unregister_interface (object.c:1361)
==337== by 0x14CDF0: service_exit (service.c:581)
==337== by 0x177556: plugin_cleanup (plugin.c:242)
==337== by 0x12221F: main (main.c:559)
If there's a pending property but its exists() callback returns false
the property should be considered invalidated and included in the
relevant list of the PropertiesChanged signal.
Minor fixes to make setter actually work:
- Add propdata in pending_property_set
- Break loop when we are removing propdata from list and we
found it
- in_args and out_args were swapped
- interface and method name arguments were swapped
If an interface is added and removed on the same mailoop iteration,
ObjectManager would try to send InterfacesAdded signal while running the
idler because the interface was added to data->added list.
This is easily reproduced by forcing an error path in a plugin
registration, like on sap_server_register(), resulting in the following
error:
==11795== Invalid read of size 4
==11795== at 0x496F592: dbus_message_iter_append_basic (dbus-message.c:2598)
==11795== by 0x117B39: append_interface (object.c:554)
==11795== by 0x48955E7: g_slist_foreach (gslist.c:840)
==11795== by 0x11923B: process_changes (object.c:592)
==11795== by 0x11956D: generic_unregister (object.c:980)
==11795== by 0x4973BAC: _dbus_object_tree_unregister_and_unlock (dbus-object-tree.c:516)
==11795== by 0x4965240: dbus_connection_unregister_object_path (dbus-connection.c:5776)
==11795== by 0x1178A5: object_path_unref (object.c:1219)
==11795== by 0x118517: g_dbus_unregister_interface (object.c:1344)
==11795== by 0x19AF5B: sap_exit (sap.c:385)
==11795== by 0x13E9E2: sap_server_register (server.c:1428)
==11795== by 0x13C092: sap_server_probe (manager.c:44)
With this patch we don't send the InterfacesAdded signal, removing it
from data->added while unregistering.
Marcel Holtmann
Denis Kenzior
Mingli Wu
Luiz Augusto von Dentz
Lucas De Marchi
Lucas De Marchi
Szymon Janc
Syam Sidhardhan
Johan Hedberg