On protocols that support creation of multiparty calls outside of
oFono's control, we need a way to detect multiparty call transitions.
This method adds a way for the driver to hint the core which calls
should be part of the multiparty call.
Right now this is relevant only to HFP. Real modem hardware should not
be using this method.
When disconnecting from D-Bus a message could be recieved with no sender:
Invalid read of size 1
at 0x4A09EE1: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x3B03C386B8: g_str_equal (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x4065D6: message_filter (watch.c:529)
by 0x3B0700F9E5: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x4052E7: message_dispatch (mainloop.c:76)
by 0x3B03C48962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C47E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x4038C5: client_proxy_removed (test-gdbus-client.c:902)
by 0x3B03C6B566: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C6B6E5: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
Address 0x0 is not stack'd, malloc'd or (recently) free'd
In case of filter_data having a watch to a service name it may call
dbus_connection_remove_filter twice causing libdbus to abort:
process 24723: Attempt to remove filter function 0x4063e0 user data (nil), but no such filter has been added
To fix this the code will now only attempt to call
dbus_connection_remove_filter once in filter_data_free which is the
counterpart of filter_data_get where dbus_connection_add_filter is called.
at 0x40570C: update_service (watch.c:601)
by 0x40584B: service_reply (watch.c:627)
by 0x3B0700C511: ??? (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x3B0700F740: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x405167: message_dispatch (mainloop.c:76)
by 0x3B03C48962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C47E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
Address 0x4c58a30 is 32 bytes inside a block of size 56 free'd
at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x3B03C4D9AE: g_free (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x406102: filter_data_remove_callback (watch.c:378)
by 0x405FC0: g_dbus_remove_watch (watch.c:798)
by 0x40A22B: g_dbus_client_unref (client.c:1227)
by 0x40570B: update_service (watch.c:599)
by 0x40584B: service_reply (watch.c:627)
This fixes double emission of PropertiesChanged introduced by flushing
changes, the flushing can happen during the pending processing so the
pending_prop flag needs to be updated in the beginning and the list of
properties can be freed before g_dbus_send_message as it is not required
anymore.
In some cases the order of the messages is altered when a message is
sent without processing the pending signals first, currently this affect
client_check_order unit test:
/gdbus/client_check_order: **
ERROR:unit/test-gdbus-client.c:795:property_check_order: assertion failed: (g_strcmp0(string, "value1") == 0)
As can be observed the value of the property is not yet updated because the
signal it is still pending, once this fix is applied the test pass:
/gdbus/client_check_order: OK
Note that the flushing only works when g_dbus_send_message is used so
places where dbus_connection_send and other variants are called directly
may still change the order.
So the value might be used directly for D-Bus property emission.
Otherwise D-Bus asserts and screws itself with:
ofonod[7427]: src/sms.c:handle_mwi()
process 7427: arguments to dbus_message_iter_append_basic() were
incorrect, assertion "*bool_p == 0 || *bool_p == 1" failed in file
../../dbus/dbus-message.c line 2549.
The affected call types for +CHUP were set to only ACTIVE calls.
Instead the affected set should include INCOMING, DIALING, ALERTING and
ACTIVE calls.
Thanks to Ionut Dediu for the diagnosing and reporting this issue.
The SIM900 module from SIMCOM does have a AT+CGDATA command.
However, it is not possible to make a ppp connection when CGDATA
has been used to bring up the gprs context.
This patch adds a quirk that uses the alternative ATD*99***<cid>#
command instead.
With the current approach if we have different CFLAGS for each binary we would
build gdbus several times for no reason.
Instead of prepending $(gdbus_sources) to several _SOURCES variable, use
a convenience library thas is used internally only, thus with a "-internal"
suffix.
Remove proxies and generate proxy_removed callbacks even when there are
no corresponding InterfaceRemoved signals.
This patch fixes having zombie gdbus proxy object when a server
disconnects without sending InterfaceRemoved signals. These objects
may interact with new server instances, for example, making
InterfaceAdded signals of new objects with the same name be filtered
out as duplicated, or staying allocated, but unused, if the new server
doesn't reuse the object paths. Note that as a side-effect, the
lifetime of a gdbus proxy becomes stricter: it lives at most for the
duration of a single connection to a single instance of a server
process.
It's not possible to be both greater than '9' and less than '0'. This
would lead to accepting things like "#$33#" as activation and "*$33#" as
deactivation, even though the string makes no sense.
Automake >= 1.13 enables parallel-tests option by default which uses a
test-driver script (copied by automake). Ignore this file and the files
generated by this script.
src/stk.c: In function ‘__ofono_cbs_sim_download’:
src/stk.c:283:45: error: argument to ‘sizeof’ in ‘memcpy’ call is the
same expression as the source; did you mean to dereference it?
[-Werror=sizeof-pointer-memaccess]
memcpy(&e.cbs_pp_download.page, msg, sizeof(msg));
^
From D-Bus documentation for dbus_connection_send_with_reply():
"Warning: if the connection is disconnected or you try to send Unix file
descriptors on a connection that does not support them, the
DBusPendingCall will be set to NULL, so be careful with this."
Fix these errors when killing D-Bus daemon with the client still
running:
process 5712: arguments to dbus_pending_call_set_notify() were
incorrect, assertion "pending != NULL" failed in file
../../dbus/dbus-pending-call.c line 596.
This is normally a bug in some application using the D-Bus library.
process 5712: arguments to dbus_pending_call_unref() were incorrect,
assertion "pending != NULL" failed in file
../../dbus/dbus-pending-call.c line 572.
This is normally a bug in some application using the D-Bus library.
Fix this crash if D-Bus exits while the client is still connected to it:
==5570== Invalid read of size 1
==5570== at 0x402D28E: strcmp (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5570== by 0x4070E22: g_str_equal (ghash.c:1704)
==5570== by 0x8055F61: message_filter (client.c:1123)
==5570== by 0x4141500: dbus_connection_dispatch (in
/lib/i386-linux-gnu/libdbus-1.so.3.5.8)
==5570== by 0x80506F7: message_dispatch (mainloop.c:76)
==5570== by 0x4081A7E: g_timeout_dispatch (gmain.c:3882)
==5570== by 0x4080D85: g_main_context_dispatch (gmain.c:2539)
==5570== by 0x4081124: g_main_context_iterate.isra.21 (gmain.c:3146)
==5570== by 0x408156A: g_main_loop_run (gmain.c:3340)
==5570== by 0x41BF4D2: (below main) (libc-start.c:226)
==5570== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==5570==
==5570==
Denis Kenzior
Vinicius Costa Gomes
Luiz Augusto von Dentz
Anthony Viallard
Marcel Holtmann
Jesper Larsen
Lucas De Marchi
Gustavo Padovan
Frederic Danis
Henrique Dante de Almeida
Lucas De Marchi
Anderson Lizardo