[PATCH] stk: Handle null Text field.

[PATCH] stk: Handle null Text field.

[Andrzej Zaborowski]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

Add a NULL check in dbus_apply_text_attributes because in some places
(like DisplayText handler) we call it without checking and we just check
the return value once.
---
 src/stk.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/stk.c b/src/stk.c
index 18beee6..291d7d2 100644
--- a/src/stk.c
+++ b/src/stk.c
@@ -303,6 +303,9 @@ static char *dbus_apply_text_attributes(const char *text,
 	const uint8_t *j = attr->attributes;
 	const uint8_t *end = j + attr->len;
 
+	if (!text)
+		return NULL;
+
 	if (attr->len & 3)
 		return NULL;
 
-- 
1.7.1.86.g0e460.dirty

[PATCH] gatchat: make sure to unsubscribe the GAtIO write handler on disconnect.

[Andrzej Zaborowski]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

There's a small probability that we call chat_wakeup_writer
just before the channel disonnects and for some reason glib then
calls can_write_data after we have unrefed the io and freed all the
resources.  Calling at_chat_suspend unsubscribes can_write_data
from the io.
---
 gatchat/gatchat.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/gatchat/gatchat.c b/gatchat/gatchat.c
index 218f592..957181c 100644
--- a/gatchat/gatchat.c
+++ b/gatchat/gatchat.c
@@ -40,6 +40,7 @@
 
 struct at_chat;
 static void chat_wakeup_writer(struct at_chat *chat);
+static void at_chat_suspend(struct at_chat *chat);
 
 static const char *none_prefix[] = { NULL };
 
@@ -364,6 +365,7 @@ static void io_disconnect(gpointer user_data)
 	struct at_chat *chat = user_data;
 
 	chat_cleanup(chat);
+	at_chat_suspend(chat);
 	g_at_io_unref(chat->io);
 	chat->io = NULL;
 
-- 
1.7.1.86.g0e460.dirty

Re: [PATCH] stk: Handle null Text field.

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

Hi Andrew,

On 11/21/2010 10:43 PM, Andrzej Zaborowski wrote:
> Add a NULL check in dbus_apply_text_attributes because in some places
> (like DisplayText handler) we call it without checking and we just check
> the return value once.
> ---
>  src/stk.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 

Patch has been applied, thanks.

Regards,
-Denis

Re: [PATCH] gatchat: make sure to unsubscribe the GAtIO write handler on disconnect.

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

Hi Andrew,

On 11/21/2010 10:43 PM, Andrzej Zaborowski wrote:
> There's a small probability that we call chat_wakeup_writer
> just before the channel disonnects and for some reason glib then
> calls can_write_data after we have unrefed the io and freed all the
> resources.  Calling at_chat_suspend unsubscribes can_write_data
> from the io.
> ---
>  gatchat/gatchat.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/gatchat/gatchat.c b/gatchat/gatchat.c
> index 218f592..957181c 100644
> --- a/gatchat/gatchat.c
> +++ b/gatchat/gatchat.c
> @@ -40,6 +40,7 @@
>  
>  struct at_chat;
>  static void chat_wakeup_writer(struct at_chat *chat);
> +static void at_chat_suspend(struct at_chat *chat);

This is really against the coding standard ;)

>  
>  static const char *none_prefix[] = { NULL };
>  
> @@ -364,6 +365,7 @@ static void io_disconnect(gpointer user_data)
>  	struct at_chat *chat = user_data;
>  
>  	chat_cleanup(chat);
> +	at_chat_suspend(chat);
>  	g_at_io_unref(chat->io);
>  	chat->io = NULL;
>  

Actually I think the right fix is to remove the write watcher in
io_shutdown.

I pushed an experimental patch 99107c6c9d0ae42eb96621b0fc34972e418f1755,
please let me know if this fixes the issue.

Regards,
-Denis

Re: [PATCH] gatchat: make sure to unsubscribe the GAtIO write handler on disconnect.

[Andrzej Zaborowski]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

On 23 November 2010 10:22, Denis Kenzior <denkenz@gmail.com> wrote:
> Actually I think the right fix is to remove the write watcher in
> io_shutdown.
>
> I pushed an experimental patch 99107c6c9d0ae42eb96621b0fc34972e418f1755,
> please let me know if this fixes the issue.

Yes, seems to have fixed the issue as well.

Thanks