From: Mikel Astiz <[email protected]>
>From my understanding, a transport should exist for any non-disconnected
gateway.
These assertions sometimes fail though. So I would like to clarify if
that's a consistent state in BlueZ or there is some bug.
---
audio/media.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/audio/media.c b/audio/media.c
index a2ef437..c5fe3d9 100644
--- a/audio/media.c
+++ b/audio/media.c
@@ -28,6 +28,7 @@
#endif
#include <errno.h>
+#include <assert.h>
#include <glib.h>
#include <gdbus.h>
@@ -620,8 +621,10 @@ static void gateway_state_changed(struct audio_device *dev,
gateway_setconf_cb, dev, NULL);
break;
case GATEWAY_STATE_CONNECTED:
+ assert(endpoint->transport != NULL);
break;
case GATEWAY_STATE_PLAYING:
+ assert(endpoint->transport != NULL);
break;
}
}
--
1.7.6.4
Hi Luiz,
On 10:43 Fri 16 Dec, Luiz Augusto von Dentz wrote:
> Hi Mikel,
>
> On Thu, Dec 15, 2011 at 2:33 PM, Mikel Astiz <[email protected]> wrote:
> > From: Mikel Astiz <[email protected]>
> >
> > From my understanding, a transport should exist for any non-disconnected
> > gateway.
> >
> > These assertions sometimes fail though. So I would like to clarify if
> > that's a consistent state in BlueZ or there is some bug.
> > ---
> > ?audio/media.c | ? ?3 +++
> > ?1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/audio/media.c b/audio/media.c
> > index a2ef437..c5fe3d9 100644
> > --- a/audio/media.c
> > +++ b/audio/media.c
> > @@ -28,6 +28,7 @@
> > ?#endif
> >
> > ?#include <errno.h>
> > +#include <assert.h>
> >
> > ?#include <glib.h>
> > ?#include <gdbus.h>
> > @@ -620,8 +621,10 @@ static void gateway_state_changed(struct audio_device *dev,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?gateway_setconf_cb, dev, NULL);
> > ? ? ? ? ? ? ? ?break;
> > ? ? ? ?case GATEWAY_STATE_CONNECTED:
> > + ? ? ? ? ? ? ? assert(endpoint->transport != NULL);
> > ? ? ? ? ? ? ? ?break;
> > ? ? ? ?case GATEWAY_STATE_PLAYING:
> > + ? ? ? ? ? ? ? assert(endpoint->transport != NULL);
> > ? ? ? ? ? ? ? ?break;
> > ? ? ? ?}
> > ?}
> > --
> > 1.7.6.4
>
> IMO assert on daemon are not that great, it may help while developing
> but why not run with valgrind and let it crash?
This information may help with your worries, from the assert(3) man page:
"If the macro NDEBUG was defined at the moment <assert.h> was last included,
the macro assert() generates no code, and hence does nothing at all."
So we can have assert() do something only when it is compiled in developer mode.
>
> --
> Luiz Augusto von Dentz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
--
Vinicius
Hi Mikel,
On Fri, Dec 16, 2011 at 2:06 PM, Mikel Astiz <[email protected]> wrote:
> Hi Luiz,
>
>
> On 12/16/2011 09:43 AM, Luiz Augusto von Dentz wrote:
>>
>> IMO assert on daemon are not that great, it may help while developing but
>> why not run with valgrind and let it crash?
>
>
> I was not that much proposing to add the assertion, but to discuss if that
> assertion should hold or not.
>
> Basically my question is: is it guaranteed that a transport will exist while
> a gateway is connected or playing?
Yes it should exist if media API is being used, while we are
connecting we attempt to create the transport.
> If yes, I think there is a bug somewhere, because those assertions do fail
> sometimes.
Probably, but it should be easier if you debug the state transitions.
> I was specifically asking this regarding the internal state of the daemon,
> but the same question could be formulated for the state exposed in D-Bus.
It should be consistent, I would start by analyzing the logs, there
seems to be at least one place where it call clear_configuration
without being disconnected see media.c:endpoint_reply, that is when
the endpoint stop responding.
--
Luiz Augusto von Dentz
Hi Luiz,
On 12/16/2011 09:43 AM, Luiz Augusto von Dentz wrote:
> IMO assert on daemon are not that great, it may help while developing
> but why not run with valgrind and let it crash?
I was not that much proposing to add the assertion, but to discuss if
that assertion should hold or not.
Basically my question is: is it guaranteed that a transport will exist
while a gateway is connected or playing?
If yes, I think there is a bug somewhere, because those assertions do
fail sometimes.
I was specifically asking this regarding the internal state of the
daemon, but the same question could be formulated for the state exposed
in D-Bus.
Regards,
Mikel
Hi Mikel,
On Thu, Dec 15, 2011 at 2:33 PM, Mikel Astiz <[email protected]> wrote:
> From: Mikel Astiz <[email protected]>
>
> From my understanding, a transport should exist for any non-disconnected
> gateway.
>
> These assertions sometimes fail though. So I would like to clarify if
> that's a consistent state in BlueZ or there is some bug.
> ---
> ?audio/media.c | ? ?3 +++
> ?1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/audio/media.c b/audio/media.c
> index a2ef437..c5fe3d9 100644
> --- a/audio/media.c
> +++ b/audio/media.c
> @@ -28,6 +28,7 @@
> ?#endif
>
> ?#include <errno.h>
> +#include <assert.h>
>
> ?#include <glib.h>
> ?#include <gdbus.h>
> @@ -620,8 +621,10 @@ static void gateway_state_changed(struct audio_device *dev,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?gateway_setconf_cb, dev, NULL);
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?case GATEWAY_STATE_CONNECTED:
> + ? ? ? ? ? ? ? assert(endpoint->transport != NULL);
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?case GATEWAY_STATE_PLAYING:
> + ? ? ? ? ? ? ? assert(endpoint->transport != NULL);
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?}
> ?}
> --
> 1.7.6.4
IMO assert on daemon are not that great, it may help while developing
but why not run with valgrind and let it crash?
--
Luiz Augusto von Dentz