There is no much of point to have a user_data if it is always the same
type, besides this code is very inefficient and cause a lookup in the list
of pending calls everytime a reply is received.
This fixes regression introduced by
63becff48820dc50a30ae495e286e858a886d9dd, causing obex-client to crash
in cases of e.g. remote site rejecting pushed file.
The req->function set by user of agent API may request agent object
deletion. This in turn checks if agent->pending is set and if it is,
it tries to cancel the pending call and frees pending call data. As at
this point we are already handling call response and we are going to
free this pending call data, agent->pending can be set to NULL prior to
calling req->function, thus preventing premature freeing of later
dereferenced req.
Invalid read of size 8
at 0x413DA1: get_file_callback (ftp.c:184)
by 0x40A74E: transfer_complete (gobex-transfer.c:73)
by 0x40AB91: transfer_response (gobex-transfer.c:172)
by 0x40847A: handle_response (gobex.c:629)
by 0x408C06: incoming_data (gobex.c:811)
by 0x3E01043DBC: g_main_context_dispatch (in /lib64/libglib-2.0.so.0.2910.0)
by 0x3E010445A7: ??? (in /lib64/libglib-2.0.so.0.2910.0)
by 0x3E01044AF4: g_main_loop_run (in /lib64/libglib-2.0.so.0.2910.0)
by 0x404CD4: main (main.c:102)
Address 0x8 is not stack'd, malloc'd or (recently) free'd
This simplify target matching to a single place making it easier to add
new targets/profiles.
Matching is done by either friendly name e.g. opp, ftp... or Bluetooth
UUID.
Drivers are probed when a session is established and removed when the
session is destroyed.
Session data should not be acessible directly otherwise it cause too
much dependency by profile specific code which is quite inefficient in
the long term.
Connection of RFCOMM and SDP are extracted from session_create function
into session_connect. Such allows making asynchronous calls before
creating connections.
From stat documentation:
"(stat()) path refers to a file whose size cannot be represented in the
type off_t. This can occur when an application compiled on a 32-bit
platform without -D_FILE_OFFSET_BITS=64 calls stat() on a file whose size
exceeds (2<<31)-1 bits."
To fix this now size header is omitted when the file is over 32-bit, but
it is able to transfer it by using 64-bit variables. In addition to that
folder-listing now should report such big sizes properly.
Since obex-client and obexd share the same log code they both were using
obexd for openlog which makes it very confusing when reading the logs.
To fix this now __obex_log_init takes the binary name so that each daemon
can be properly labeled.
If the callback removes the pending data it cause this:
==20639== Invalid read of size 4
==20639== at 0x80553E9: free_pending (session.c:112)
==20639== by 0x8056C83: session_request_reply (session.c:837)
==20639== by 0x412F7E0: ??? (in /lib/libdbus-1.so.3.5.2)
==20639== by 0x411D975: ??? (in /lib/libdbus-1.so.3.5.2)
==20639== by 0x4120B81: dbus_connection_dispatch (in /lib/libdbus-1.so.3.5.2)
==20639== by 0x804C27F: message_dispatch (mainloop.c:80)
==20639== by 0x407EFCB: ??? (in /lib/libglib-2.0.so.0.2600.1)
==20639== by 0x407E854: g_main_context_dispatch (in /lib/libglib-2.0.so.0.2600.1)
==20639== by 0x4082667: ??? (in /lib/libglib-2.0.so.0.2600.1)
==20639== by 0x4082BA6: g_main_loop_run (in /lib/libglib-2.0.so.0.2600.1)
==20639== by 0x8055171: main (main.c:625)
==20639== Address 0x4363c88 is 0 bytes inside a block of size 12 free'd
==20639== at 0x40257ED: free (vg_replace_malloc.c:366)
==20639== by 0x4087485: g_free (in /lib/libglib-2.0.so.0.2600.1)
==20639== by 0x80553FE: free_pending (session.c:115)
==20639== by 0x805543C: agent_free (session.c:127)
==20639== by 0x80566A6: session_free (session.c:149)
==20639== by 0x8056BCA: session_terminate_transfer (session.c:914)
==20639== by 0x8056F61: session_prepare_put (session.c:1397)
==20639== by 0x8056C74: session_request_reply (session.c:835)
==20639== by 0x412F7E0: ??? (in /lib/libdbus-1.so.3.5.2)
==20639== by 0x411D975: ??? (in /lib/libdbus-1.so.3.5.2)
==20639== by 0x4120B81: dbus_connection_dispatch (in /lib/libdbus-1.so.3.5.2)
==20639== by 0x804C27F: message_dispatch (mainloop.c:80)
To fix this agent->pending is now reset to NULL before calling the
callback, so even if the session is terminated it won't cause a free to
pending data, which is fine since it is latter freed on callback return.
