| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| | |
Port to gupnp-1.2
This has been approved
|
|/
|
|
|
|
|
|
|
|
| |
The latest version of gupnp breaks backwards compatibility. Fortunately,
there are not many calls to gupnp functions in core, so we just needed
to bump the dependencies.
There is one deprecated gupnp_service_proxy_cancel_action call but
I am not sure how to change it without breaking Dleyna API.
Let's leave it for now.
|
| |
|
| |
|
|\
| |
| | |
Remove all queues before dleyna_task_processor_t->on_quit_cb is run
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If dleyna_task_processor_t->on_quit_cb is run while there are still
queues present in the processor, it can lead to a crash if one of the
queue's task_queue_finally_cb handler didn't expect to be run after
the control point has been stopped. For example,
dleyna-renderer-service crashes with this backtrace:
%0 __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
%1 __GI_abort () at abort.c:89
%2 g_assertion_message (domain="GLib",
file="ghash.c",
line=373,
func="g_hash_table_lookup_node",
message="assertion failed:
(hash_table->ref_count > 0)")
at gtestutils.c:2429
%3 g_assertion_message_expr (domain="GLib",
file="ghash.c",
line=373,
func="g_hash_table_lookup_node",
expr="hash_table->ref_count > 0")
at gtestutils.c:2452
%4 g_hash_table_lookup_node (hash_return=<synthetic pointer>,
key=0x561e98ca21c0,
hash_table=0x561e985899e0)
at ghash.c:373
%5 g_hash_table_insert_internal (hash_table=0x561e985899e0,
key=0x561e98ca21c0,
value=0x561e98a581f0,
keep_new_key=0)
at ghash.c:1227
%6 prv_device_chain_end (cancelled=<optimized out>,
data=0x561e98e3acb0)
at upnp.c:85
%7 prv_free_cb (data=0x561e98b97280)
at libdleyna/core/task-processor.c:103
%8 g_hash_table_remove_all_nodes (hash_table=0x561e98549240,
notify=<optimized out>,
destruction=<optimized out>)
at ghash.c:548
%9 g_hash_table_remove_all_nodes (destruction=1,
notify=1,
hash_table=0x561e98549240)
at ghash.c:1093
%10 g_hash_table_unref (hash_table=0x561e98549240) at ghash.c:1097
%11 dleyna_task_processor_free (processor=0x561e985543a0)
at libdleyna/core/task-processor.c:136
%12 prv_context_free () at libdleyna/core/main-loop.c:108
%13 dleyna_main_loop_start (server=<optimized out>,
control_point=<optimized out>,
user_data=0x0)
at libdleyna/core/main-loop.c:167
%14 __libc_start_main (main=0x561e97db5990 <main>,
argc=1,
argv=0x7fff905cb0a8,
init=<optimized out>,
fini=<optimized out>,
rtld_fini=<optimized out>,
stack_end=0x7fff905cb098)
at ../csu/libc-start.c:289
%15 _start ()
The processor's on_quit_cb handler is set to prv_context_quit_cb,
which calls control_point->stop_service and quits the GMainLoop. Then
the processor is destroyed, which in turn destroys any queues that
might have been left inside it. Unfortunately, a queue's
task_queue_finally_cb handler might be set to something that assumes
that the control_point has not been stopped. For example,
dleyna-renderer-service sets task_queue_finally_cb to
prv_device_chain_end, which will crash due to accessing invalid memory
(specifically the dlr_upnp_t) if prv_control_point_stop_service has
already been invoked. We see the same problem in dleyna-server-service
too.
Therefore, let's remove any leftover queues from the processor just
before dleyna_task_processor_t->on_quit_cb is scheduled to run. We are
about to terminate the process anyway, so it shouldn't hurt to do it
slightly earlier in the sequence.
https://bugzilla.redhat.com/show_bug.cgi?id=1360209
|
|\ \
| |/
| | |
Don't schedule dleyna_task_processor_t->on_quit_cb more than once
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even if there are some running tasks, cancelling all the queues will
set processor->running_tasks to zero. It will call
dleyna_task_queue_task_completed for each running task, which will
keep decrementing processor->running_tasks and schedule the on_quit_cb
handler once it is zero. Therefore, it is meaningless to check the
value of processor->running_tasks after prv_cancel_all_queues.
Instead, we should do it before.
Otherwise, it can confuse client code which doesn't expect to have the
on_quit_cb handler invoked multiple times. For example, it causes
dleyna-render-service to crash with this backtrace:
%0 __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:55
%1 __GI_abort () at abort.c:89
%2 __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7f89f83f0e20 "*** Error in `%s':
%s: 0x%s ***\n")
at ../sysdeps/posix/libc_fatal.c:175
%3 malloc_printerr (ar_ptr=<optimized out>,
ptr=<optimized out>,
str=0x7f89f83f0ee8 "double free or corruption
(fasttop)",
action=3)
at malloc.c:5000
%4 _int_free (av=<optimized out>,
p=<optimized out>,
have_lock=0)
at malloc.c:3861
%5 __GI___libc_free (mem=<optimized out>) at malloc.c:2962
%6 g_free (mem=0x558aa23b0000) at gmem.c:192
%7 dlr_upnp_delete (upnp=<optimized out>) at upnp.c:423
%8 prv_control_point_stop_service () at server.c:725
%9 prv_context_quit_cb (user_data=<optimized out>)
at libdleyna/core/main-loop.c:61
%10 g_main_dispatch (context=0x558aa237a140) at gmain.c:3122
%11 g_main_context_dispatch (context=context@entry=0x558aa237a140)
at gmain.c:3737
%12 g_main_context_iterate (context=0x558aa237a140,
block=block@entry=1,
dispatch=dispatch@entry=1,
self=<optimized out>)
at gmain.c:3808
%13 g_main_loop_run (loop=0x558aa23aecc0) at gmain.c:4002
%14 dleyna_main_loop_start (server=<optimized out>,
control_point=<optimized out>,
user_data=0x0)
at libdleyna/core/main-loop.c:155
%16 _start ()
https://bugzilla.redhat.com/show_bug.cgi?id=1251366
|
|\
| |
| | |
m4: use portable shell
|
| |
| |
| |
| |
| |
| | |
Also get rid of unnecessary subshells.
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
|
|/
|
|
|
|
|
|
|
| |
Fixes the following configure error:
checking for --with-log-level=7... ./configure: 12691:
./configure.lineno: let: not found
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
|
|
|
|
| |
Updated Copyright from 2013 to 2015
|
|
|
|
| |
dleyna_core_prv_convert_udn_to_path to support persistent path identifier
|
|
|
|
| |
This reverts commit 69ba527aa9c68823b5f686a40775864c35ba3509.
|
| |
|
|\
| |
| | |
Gracefully exit in case of dbus session crash
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Fixes #41.
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
|
|/
|
|
|
|
|
|
|
|
|
|
| |
Update the compiler flags to enable the check of undefined function at link time.
It seems the option '-no-undefined' pass in libdleyna_core_1_0_la_LDFLAGS
is not enough. Using libtool, this option should be set to the compiler flags.
Signed-off-by: Ludovic Ferrandis <ludovic.ferrandis@intel.com>
Fixes #33.
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
|
|
|
|
| |
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
|
|
|
|
| |
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Partial fix for https://github.com/01org/dleyna-renderer/issues/137
The signature of dleyna_service_task_get_user_data was wrong and has
now been fixed.
We also need to align structures in virtual inheritence hierarchies.
Signed-off-by: Mark Ryan <mark.d.ryan@intel.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make settings & white list independant.
Settings doesn't call directly WhiteList API.
Settings 'never_quit' & 'netf_enabled' & 'netf_entries' are now save to the settings file
when set using the new API below:
- dleyna-settings_set_never_quit
- dleyna_settings_set_white_list_enabled
- dleyna_settings_set_white_list_entries
Monitoring has been removed.
Signed-off-by: Ludovic Ferrandis <ludovic.ferrandis@intel.com>
|
|
|
|
| |
Signed-off-by: Ludovic Ferrandis <ludovic.ferrandis@intel.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
|
|
|
|
|
| |
Newer versions of checkpatch check for the use of camel case in the
code. Although, dLeyna does not itself use camel case, it uses a lot
of glib structures and functions that do. Therefore, this warning needs
to be disabled, otherwise you see a lot of spurious errors.
Signed-off-by: Mark Ryan <mark.d.ryan@intel.com>
|
|
|
|
|
|
|
| |
When the action callback failed and it returns 'failed' parameter set to FALSE,
the queued task was not completed and the process blocked.
Signed-off-by: Ludovic Ferrandis <ludovic.ferrandis@intel.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
| |
Signed-off-by: Ludovic Ferrandis <ludovic.ferrandis@intel.com>
|
|
|
|
|
|
| |
Fix issue #20: <https://github.com/01org/dleyna-core/issues/20>
Signed-off-by: Ludovic Ferrandis <ludovic.ferrandis@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add Network Filtering support in dLeyna.
Add API to the core library to manage the GUPnPWhiteList object
Manage 2 new settings:
1 - netf_enabled (boolean): To activate or deactivate the network filtering
2 - netf_entries (str list): List of supported network
Signed-off-by: Ludovic Ferrandis <ludovic.ferrandis@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The interface_index parameter relates to the corresponding xml
part from the introspection data passed to initialize().
This was convenient for the d-bus connector implementation, but
required xml parsing for other connector implementations.
This commit replaces the interface_index parameter with the
actual interface name to avoid the xml parsing task.
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The first fix correctly ensured that all queues were cancelled when shutting down
but unfortunately the queue cancellation code was buggy. It could result in a
hash table entry being removed from a hash table during a call to g_hash_table_for_each.
This meant that if multiple devices were being constructed at once, not all of
the queues responsible for device construction got cancelled. The uncancelled queues
were executing code during shutdown which lead to nasty things happening.
Signed-off-by: Mark Ryan <mark.d.ryan@intel.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even when using autoreconf an autogen.sh script is usually expected, as
it save users from needing to know which flags to pass to autoreconf
(ie. '-i').
It is also usually responsible of launching autoreconf from the right
directory, calling utilities like intltoolize and gtkdocize, checking
out git submodules and running ./configure unless $NOCONFIGURE is set.
Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
| |
Signed-off-by: Regis Merlino <regis.merlino@intel.com>
|
|
|
|
| |
Signed-off-by: Ludovic Ferrandis <ludovic.ferrandis@intel.com>
|
|
|
|
| |
Signed-off-by: Ludovic Ferrandis <ludovic.ferrandis@intel.com>
|