I'm facing some problems with an application that uses libpurple.
In fact, it's a messenger app build with WTL as interface library.
The problems are generally related with simultaneous gaim "invocations", like: establishment of multiple connections for different protocols simultaneously; sign-off of an account during the sign-on process; and others...
Most of time, those actions results on application crash.
I was informed by "datallah" on another thread that libgaim is not thread safe at all.
So I would like to just check this out, mostly considering the situations describe above.
Thanks, and best regards you all!!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank's a lot for the post.
I just realized that the problem with my application is always related with ICQ protocol.
All other protocols work pretty fine, and after the necessary adjustments on our client's application to be compliant with new libgaim 2.0 (I haven't got the names change release yet), everything seems to be ok.
Differently, the ICQ protocol has a very abnormal behavior, that I suspect could be related with the mess of allocation/deallocation metods used (g_mallocs() being dealloced with normal free(), and so on).
It seems to be a problem mainly because we build everything here using MSVC .net 2003.
I'm trying to find out what can be happening with the ICQ protocol, considering that it's mandatory to be released with the adjustments that we are making here.
I need to be honest... I'm getting completely lost with that.
Everything works fine when the application is receiving information of another client, like status updates from the contacts, or messagens as well. But, when I try to send anything back, propagate a new status, send a message, etc, the protocol is abruptly disconnected.
Just to get things stranger, when I debug the application stopping on the breakpoints all throught the code, the problem doesn't happen any more, and everything works fine for sending too.
This only happens with the ICQ protocol.
Does anyone have any idea about why is that happening ?
Thank's and best regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, is there no serialization during the access to libgaim interfaces.
Nevertheless, could it be possible that only the ICQ protocol is affected by this multi-thread condition?
None of other protocols present such behavior...
Is there no other possibility that figures out as an considerable souce of problem ?
Thank's and best regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In fact, the problem is caused exactly by this multi-thread condition.
Using Ethereal, I noticed that some ICQ primitives are sent with the same "sequence number" and right after that, the connection is reset by the server.
Considering that I couldn't change so hardly our client's application (like making it to work as a single threaded one), and that this only happens with ICQ protocol, I'm thinking to make a more specific adjustment.
I'll try to use a GStaticMutex to syncronize the method responsible for the creation of the ICQ protocol primitives and where the snacid (or primitive's "sequence number") is established.
I think it will solve my problems for now.
But I'll update you about the results.
Thank's again, and best regards!!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am surprised that this is only problematic in ICQ, it may be the case that this race condition only shows up in ICQ in your application _for_now_, but the long term solution is still synchronize all the calls into libpurple.
I am curious about your application though, is this something that is publicly available?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, I know this is the desired scenario, but I want to kill all other possibilities before taking this path, mainly because we are expected to make the less as possible changes on our client's application.
Althought firstly I thoght this could be happening just on ICQ protocol because of the intense traffic of primitives demanded by it (mainly set status request primitives, that cause most of problems), I'm tricked with some messagens I'm getting on my debug output, as you can see below:
"HEAP[uimd.exe]: HEAP: Free Heap block 336d028 modified at 336d080 after it was freed"
Maybe this could lead me to a point of convergence that explain more satisfactorily why does it happen only with ICQ.
Anyway, answering your question, the application could be retrieved on "http://messenger.uol.com.br/", and one thing I can assure you... you'll probably have much fun with their "cow visual approuch" :-))).
It's quite fun (the cow`s bell sound for new messages is hilarious).
I'll update you of my results.
Thanks's and best regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You'll probably have problems using it...
It's not internationalized at all...
Pity... it would be great receive a feedback from you about it...
But, fell free to contact me whether you want some help on that...
Anyway... digging on ICQ problem I have, firstly I thought that the origin of my problems with replicated sequence number primitives was caused by multiple threads accessing the method that increments the sequence number concurrently...
But now, I think the primitives are being entirely replicated, or sent twice...
I'll get back to you as soon as I found the real source of the problem...
Thanks, and best regards!!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank's for your sugestion, but I think I solved the problem.
At least, it seems to don't happen anymore.
I used a GMutex to sincronize the "send_cb" method on "flap_connection.c" file.
Actually the responsible for effectively send the Oscar primitives throught the net...
For a matter of time, I think to leave things as they are, and inform our customer of our decision.
Only by their request, we'll contact the devel mailing list and spend more time on this.
Anyway, thanks a lot for all your help and time, and best regards!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello there!
I'm facing some problems with an application that uses libpurple.
In fact, it's a messenger app build with WTL as interface library.
The problems are generally related with simultaneous gaim "invocations", like: establishment of multiple connections for different protocols simultaneously; sign-off of an account during the sign-on process; and others...
Most of time, those actions results on application crash.
I was informed by "datallah" on another thread that libgaim is not thread safe at all.
So I would like to just check this out, mostly considering the situations describe above.
Thanks, and best regards you all!!!
libpurple is not thread safe, you need to make sure that only one thread calls libpurple functions.
Thank's a lot for the post.
I just realized that the problem with my application is always related with ICQ protocol.
All other protocols work pretty fine, and after the necessary adjustments on our client's application to be compliant with new libgaim 2.0 (I haven't got the names change release yet), everything seems to be ok.
Differently, the ICQ protocol has a very abnormal behavior, that I suspect could be related with the mess of allocation/deallocation metods used (g_mallocs() being dealloced with normal free(), and so on).
It seems to be a problem mainly because we build everything here using MSVC .net 2003.
I'm trying to find out what can be happening with the ICQ protocol, considering that it's mandatory to be released with the adjustments that we are making here.
I need to be honest... I'm getting completely lost with that.
Everything works fine when the application is receiving information of another client, like status updates from the contacts, or messagens as well. But, when I try to send anything back, propagate a new status, send a message, etc, the protocol is abruptly disconnected.
Just to get things stranger, when I debug the application stopping on the breakpoints all throught the code, the problem doesn't happen any more, and everything works fine for sending too.
This only happens with the ICQ protocol.
Does anyone have any idea about why is that happening ?
Thank's and best regards!
Have you fixed it so that only 1 thread uses libpurple?
No, is there no serialization during the access to libgaim interfaces.
Nevertheless, could it be possible that only the ICQ protocol is affected by this multi-thread condition?
None of other protocols present such behavior...
Is there no other possibility that figures out as an considerable souce of problem ?
Thank's and best regards!
As I said in the original post, libpurple is not thread safe, you need to make sure that only one thread uses it at a time.
Thank's a lot for your time and patience...
In fact, the problem is caused exactly by this multi-thread condition.
Using Ethereal, I noticed that some ICQ primitives are sent with the same "sequence number" and right after that, the connection is reset by the server.
Considering that I couldn't change so hardly our client's application (like making it to work as a single threaded one), and that this only happens with ICQ protocol, I'm thinking to make a more specific adjustment.
I'll try to use a GStaticMutex to syncronize the method responsible for the creation of the ICQ protocol primitives and where the snacid (or primitive's "sequence number") is established.
I think it will solve my problems for now.
But I'll update you about the results.
Thank's again, and best regards!!!
I am surprised that this is only problematic in ICQ, it may be the case that this race condition only shows up in ICQ in your application _for_now_, but the long term solution is still synchronize all the calls into libpurple.
I am curious about your application though, is this something that is publicly available?
Yeah, I know this is the desired scenario, but I want to kill all other possibilities before taking this path, mainly because we are expected to make the less as possible changes on our client's application.
Althought firstly I thoght this could be happening just on ICQ protocol because of the intense traffic of primitives demanded by it (mainly set status request primitives, that cause most of problems), I'm tricked with some messagens I'm getting on my debug output, as you can see below:
"HEAP[uimd.exe]: HEAP: Free Heap block 336d028 modified at 336d080 after it was freed"
Maybe this could lead me to a point of convergence that explain more satisfactorily why does it happen only with ICQ.
Anyway, answering your question, the application could be retrieved on "http://messenger.uol.com.br/", and one thing I can assure you... you'll probably have much fun with their "cow visual approuch" :-))).
It's quite fun (the cow`s bell sound for new messages is hilarious).
I'll update you of my results.
Thanks's and best regards!
Ahh, this is what the wikipedia article was talking about. Too bad I don't understand Brazilian.
Yeah... yeah...
I forgot this "litle" detail... :-)))
Sorry!
You'll probably have problems using it...
It's not internationalized at all...
Pity... it would be great receive a feedback from you about it...
But, fell free to contact me whether you want some help on that...
Anyway... digging on ICQ problem I have, firstly I thought that the origin of my problems with replicated sequence number primitives was caused by multiple threads accessing the method that increments the sequence number concurrently...
But now, I think the primitives are being entirely replicated, or sent twice...
I'll get back to you as soon as I found the real source of the problem...
Thanks, and best regards!!!
You will have better luck mailing the devel mailing list about it. The OSCAR maintainer doesn't look at this forum.
Thank's for your sugestion, but I think I solved the problem.
At least, it seems to don't happen anymore.
I used a GMutex to sincronize the "send_cb" method on "flap_connection.c" file.
Actually the responsible for effectively send the Oscar primitives throught the net...
For a matter of time, I think to leave things as they are, and inform our customer of our decision.
Only by their request, we'll contact the devel mailing list and spend more time on this.
Anyway, thanks a lot for all your help and time, and best regards!