GError can be NULL thus causing invalid read when trying to a message
member such as bellow:
Invalid read of size 8
at 0x41190F: g_obex_send_internal (gobex.c:531)
by 0x4130A6: g_obex_send_req (gobex.c:756)
by 0x4268A5: obc_session_unref (session.c:289)
by 0x41396A: incoming_data (gobex.c:1397)
by 0x59712A5: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x5971627: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x5971A39: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x40D78C: main (main.c:320)
Address 0x0 is not stack'd, malloc'd or (recently) free'd
Since GLib 2.39 calling g_source_remove on already removed source
is causing critical warning.
This was affecting unit/test-gobex-transfer when running with
GLib 2.40.
/gobex/test_packet_get_req_suspend_resume:
(./unit/test-gobex-transfer:28879): GLib-CRITICAL **: Source ID 263 was
not found when attempting to remove it
Trace/breakpoint trap
This fixes a regression caused by 35938b779d
where the current pending_req is set to NULL while processing the
response but cause the request to timeout since it is no longer removed
properly.
This fixes the following leak introduced by the authentication patches:
16 bytes in 1 blocks are definitely lost in loss record 62 of 158
at 0x4C291D4: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x4E7FEC6: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x403226: prepare_auth_rsp.isra.4 (gobex.c:564)
by 0x404DE4: handle_response (gobex.c:1015)
by 0x405C7B: incoming_data (gobex.c:1351)
by 0x4E7A2A5: g_main_context_dispatch (in
/usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4E7A627: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4E7AA39: g_main_loop_run (in
/usr/lib64/libglib-2.0.so.0.3800.2)
by 0x40DC34: test_auth (test-gobex.c:966)
by 0x4E9E5E0: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4E9E7A5: ??? (in /usr/lib64/libglib-2.0.so.0.3800.2)
by 0x4E9EB1A: g_test_run_suite (in
/usr/lib64/libglib-2.0.so.0.3800.2)
In case connect requests needs to be resent to authenticate the timeout
handle should be removed otherwise it may end up asserting:
ERROR:gobex/gobex.c:251:req_timeout: assertion failed: (p != NULL)
In case a GET operation is in progress with SRM the same request id is
valid for the whole transfer otherwise it is not possible to cancel the
transfer after the first response.
If SRM is not confirmed by both ends the setup should be disregarded and
the data associated to it can be freed otherwise the next command may
reuse the same setup assuming it is still valid and probably cause SRM
to be enabled without remote consent.
This adds support for suspending/resuming GET requests GET when SRM is
active, in this case suspending the TX queue wont stop the remote
to continue sending packets, to do that SRMP header should be set to wait
so the remote should wait.
This reverts the changes introduced in
9095deb825 that made pending_req_abort
public which is not necessary considering g_obex_cancel_req can do the
same and is safe to call even if the request is not pending.
It is not safe to call g_obex_pending_req_abort directly as pending_req
can be NULL:
Invalid read of size 4
at 0x41231E: g_obex_pending_req_abort (gobex.c:693)
by 0x416A8A: g_obex_cancel_transfer (gobex-transfer.c:647)
by 0x42DEF2: obc_transfer_cancel (transfer.c:180)
by 0x43D833: process_message.isra.5 (object.c:259)
by 0x3B0701CE85: ??? (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x3B0700FA30: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x43A5B7: 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 0x40D53C: main (main.c:319)
Address 0x30 is not stack'd, malloc'd or (recently) free'd
The __func__ macro is part of the C99 standard whereas __FUNCTION__ is a
legacy gcc specific alias for it:
http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html
Additionally, checkpatch.pl that's commonly used to verify coding style
also recommends to use __func__ instead of __FUNCTION__.
g_atomic_* end up using G_STATIC_ASSERT, causing gcc 4.8 to yell due to
-Wunused-local-typedefs.
/usr/include/glib-2.0/glib/gmacros.h:162:53: error: typedef ‘_GStaticAssertCompileTimeAssertion_2’ locally defined but not used [-Werror=unused-local-typedefs]
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
Most of the uses of atomic operations were wrong. They were fixed as
well. If we are using atomic operations, reading the variable again
later for logging is not an option, we should use the return of the
atomic function used to fetch the variable.
This reverts commit 8a03376544.
The patch needs to be split up and the gdbus/ changes were bogus
compared to the original commit message.
Conflicts:
Makefile.am
Makefile.obexd
profiles/cyclingspeed/cyclingspeed.c
profiles/heartrate/heartrate.c
src/error.c
Instead of trying to include config.h in each file over the tree and
possibly forgetting to include it, give a "-include config.h" argument
to the compiler so it's guaranteed that a) it will be included for all
source files and b) it will be the first header included.
gdbus/ directory is left out, since it would break other projects using
it.
GUINT_TO_POINTER does not cast properly in older version of GLib (< 2.31)
causing the following errors:
cc1: warnings being treated as errors
gobex/gobex-apparam.c: In function ‘g_obex_apparam_set_bytes’:
gobex/gobex-apparam.c:176:38: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_uint8’:
gobex/gobex-apparam.c:243:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_uint16’:
gobex/gobex-apparam.c:261:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_uint32’:
gobex/gobex-apparam.c:282:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_uint64’:
gobex/gobex-apparam.c:303:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_string’:
gobex/gobex-apparam.c:324:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_bytes’:
gobex/gobex-apparam.c:342:43: error: cast to pointer from integer of
different size
make[1]: *** [gobex/gobex-apparam.o] Error 1
make: *** [all] Error 2
This introduce 2 new convenient functions: g_obex_header_get_apparam
which parses and decode an header into GObexApparam and
gobex_header_new_apparam that encode GObexApparam into GObexHeader.
GObexApparam abstract the handling of application parameter tags, it
can be used to read/parse application parameter header data using
g_obex_apparam_get_* functions or to generate the data using
g_obex_apparam_set_*.
If callback is provided in g_obex_cancel_transfer() current complete
callback will be replaced by the new one and user will be informed
when abort completes.
ENOSYS correspond to function not implemented which is exactly what the
OBEX error code means.
Also since EINVAL means invalid argument that now map to OBEX bad request
This patch create a map between posix errors code and OBEX response
opcode and use it to generate a proper response in case a transfer
failed instead of always responding with internal error.
GOEP 2.0 test specification forbids the server to include SRM headers in
CONNECT response:
"3.16 TP/SRM/BI-03-C Process an OBEX CONNECT request (incorrectly)
containing a SRM header:
• Expected Outcome
Pass Verdict:
– On receiving the invalid SRM header in the OBEX_CONNECT request, the
IUT responds with a SUCCESS without a SRM header.
– OBEX/L2CAP channel is established.
Fail Verdict:
– On receiving the invalid SRM header in the OBEX_CONNECT request, the
IUT does not respond with a SUCCESS and/or includes a SRM header in the
response.
– OBEX/L2CAP channel is not established or OBEX/RFCOMM channel is
established."
