For devices which are not 'real' phone modems, the voicecall
initialization can happen outside of the pre-sim state. In this case
the voicecall atom detection logic fails. Try to detect the voicecall
atom separately, and register the profile if the SIM atom is already
present and in state 'READY'.
For all other cases, the previous logic still applies.
"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."
Check this in g_dbus_send_message_with_reply so that callers don't need
to double check for NULL if g_dbus_send_message_with_reply returned
TRUE.
This also fix crash if passing FD over D-Bus is blocked e.g. by SELinux
policy.
bluetoothd[1894]: profiles/audio/avdtp.c:session_cb()
bluetoothd[1894]: profiles/audio/avdtp.c:avdtp_parse_cmd() Received
SET_CONFIGURATION_CMD
bluetoothd[1894]: profiles/audio/a2dp.c:endpoint_setconf_ind() Source
0x6c5000: Set_Configuration_Ind
bluetoothd[1894]: profiles/audio/avdtp.c:avdtp_ref() 0x6df360: ref=1
bluetoothd[1894]: profiles/audio/a2dp.c:setup_ref() 0x6d32b0: ref=1
process 1894: arguments to dbus_pending_call_set_notify() were incorrect,
assertion "pending != NULL" failed in file dbus-pending-call.c line
636.
This is normally a bug in some application using the D-Bus library.
As we won't allow any card to be registered when the kernel doesn't
support defer_setup, we don't need to have the listening SCO socket
open in this case.
If the kernel doesn't support defer_setup for SCO, we shouldn't allow
cards to be registered, because in that case we won't be able to
properly send the file descriptor to the Agent.
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.
Krzysztof Wilk
Denis Kenzior
Andrew Earl
Slava Monich
Bastien Nocera
Marcel Holtmann
Szymon Janc
Vinicius Costa Gomes
Luiz Augusto von Dentz