* [RFC] media: assertion to check that transport exists
@ 2011-12-15 12:33 Mikel Astiz
2011-12-16 8:43 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 5+ messages in thread
From: Mikel Astiz @ 2011-12-15 12:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Mikel Astiz
From: Mikel Astiz <mikel.astiz@bmw-carit.de>
>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
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [RFC] media: assertion to check that transport exists
2011-12-15 12:33 [RFC] media: assertion to check that transport exists Mikel Astiz
@ 2011-12-16 8:43 ` Luiz Augusto von Dentz
2011-12-16 12:06 ` Mikel Astiz
2011-12-16 17:45 ` Vinicius Costa Gomes
0 siblings, 2 replies; 5+ messages in thread
From: Luiz Augusto von Dentz @ 2011-12-16 8:43 UTC (permalink / raw)
To: Mikel Astiz; +Cc: linux-bluetooth, Mikel Astiz
Hi Mikel,
On Thu, Dec 15, 2011 at 2:33 PM, Mikel Astiz <mikel.astiz.oss@gmail.com> wrote:
> From: Mikel Astiz <mikel.astiz@bmw-carit.de>
>
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] media: assertion to check that transport exists
2011-12-16 8:43 ` Luiz Augusto von Dentz
@ 2011-12-16 12:06 ` Mikel Astiz
2011-12-16 13:02 ` Luiz Augusto von Dentz
2011-12-16 17:45 ` Vinicius Costa Gomes
1 sibling, 1 reply; 5+ messages in thread
From: Mikel Astiz @ 2011-12-16 12:06 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Mikel Astiz, linux-bluetooth
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] media: assertion to check that transport exists
2011-12-16 12:06 ` Mikel Astiz
@ 2011-12-16 13:02 ` Luiz Augusto von Dentz
0 siblings, 0 replies; 5+ messages in thread
From: Luiz Augusto von Dentz @ 2011-12-16 13:02 UTC (permalink / raw)
To: Mikel Astiz; +Cc: Mikel Astiz, linux-bluetooth
Hi Mikel,
On Fri, Dec 16, 2011 at 2:06 PM, Mikel Astiz <mikel.astiz@bmw-carit.de> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] media: assertion to check that transport exists
2011-12-16 8:43 ` Luiz Augusto von Dentz
2011-12-16 12:06 ` Mikel Astiz
@ 2011-12-16 17:45 ` Vinicius Costa Gomes
1 sibling, 0 replies; 5+ messages in thread
From: Vinicius Costa Gomes @ 2011-12-16 17:45 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Mikel Astiz, linux-bluetooth, Mikel Astiz
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 <mikel.astiz.oss@gmail.com> wrote:
> > From: Mikel Astiz <mikel.astiz@bmw-carit.de>
> >
> > 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
--
Vinicius
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-12-16 17:45 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-15 12:33 [RFC] media: assertion to check that transport exists Mikel Astiz
2011-12-16 8:43 ` Luiz Augusto von Dentz
2011-12-16 12:06 ` Mikel Astiz
2011-12-16 13:02 ` Luiz Augusto von Dentz
2011-12-16 17:45 ` Vinicius Costa Gomes
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.