Our client have an WTL Windows Application that uses libgaim 1.5, and some time ago I started an update effort to libgaim 2.0 (with beta 6 release).
After the expected adjustments on some files and MSVC projects, build of binaries, and initial connecting tests, I started the full test job that is taking me completely lost.
Starting with ICQ protocol, I was having some problems with connection establishment, contact addition, sometimes I have exceptions during disconnection, and other problems.
To fix the connecting establishment problem I was forced to add some "Sleep" instructions, and now it works fine. But, this is not an acceptable solution for me.
And I found nothing at all on Internet that can be of any help.
I have a strong impression that I'm facing lots of sincronization problems.
It's the same with the add contact situation. When I debug the application stopping on almost all stages of contact adding procedure, the process is completed successfully.
But, when I try to do the same thing without debuging the application (running with CTRL+F5 on VisualStudio), the operation is not completed and the protocol hangs up.
Considering that the application was not developped by us, I'm trying to find out any possible change or inconsistency analysing the GTK code agains the adapted code of this application, but after some adjustments, the problem persists.
On an attempt to get things better, I compiled almost all the dependency libraries with MSVC, that are: glib version 2.12.7, gettext version 0.14.5, libiconv version 1.9.1, libxml2 version 2.6.24, zlib version 1.2.3, and libpng version 1.2.16 (although I don't know whether the last 2 of them are required by the application or libgaim).
I've done that because I saw that the available binaries were linked with msvcrt.dll, while the libgaim and the application was linked against msvcr71.dll (I'm using VS 2003), what was considered a bad situation by some foruns that I was looking for answer.
As nothing worked, I chose to not build the "NSS version 3.11.4" and "NSPR version 4.6.4" binaries too, using the binaries available on Internet.
So... that's it.
I confess I've never got so lost on my entire life, and expect you guys could put some light on this.
Any help will be very appreciated!
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It sounds very much like you're running into problems related to the new win32 GIOChannel implementation in Glib >= 2.8.0.
In the win32 build of Pidgin (the GTK+ UI), we override the current Glib implemenation to use the one from Glib 2.6.10 (see gtkeventloop.c:99). You'll need to do the same thing.
I'm very curious about this win32 UI that you've created. Is it available somewhere?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, I've done that update already.
Without it, even debugging I couldn't create a contact.
Analising the callstack when debugging with old glib versions gave me the idea to search on GTK's version of this file for changes agains the one used by our client.
After that change, I could finally acchieve the condition I could replicate only with old glib binaries, that is to add the contact while debugging.
With neither situations I got success adding the contact with no application debug.
That's why I think this could be a sincronization problem. Although, a friend of mine suggested that this could be a memory corruption problem too.
Well... I'll be very thankfull whether you can suggest anything else as the possible source of my problem.
Thanks in advance, and bye.
P.S. This application was created by out customer and we are only making some adjustments/improvements, but you can find it out on "http://messenger.uol.com.br/".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
// Add buddy to Gaim local buddy list and to remote server list...
if (pBuddy != NULL)
{
// Create/get group
if (pGroup == NULL)
{
pGroup = gaim_group_new(pszUTF8Group);
gaim_blist_add_group(pGroup, NULL);
}
libpurple isn't at all thread safe, so you need to make sure that all access are from a single thread. If several threads are involved, something elsewhere may be causing the problems here.
Of course, this may not be problem.
It is hard to say what could be the specific problem since I haven't seen any details about what is happening.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anyway, I think it should not be that sort of problem, because the application is the same and everything works fine with libgaim 1.5.
Considering that I'm completely clueless about that for a considerable time, I'm thinking whether I should try to get to the origins and build libpurple, and all plugins and protocols (including our customer's one) using gcc on cygwin, instead of insist on those binaries created by MSVC.
Is a fact that our customer insist on using MSVC projects to build all binaries, and that this wasn't a problem until now, but I think this is a good try.
Thank's anyway, and please post any new ideia you can have about this, ok?
Best regards, Mauro.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello there!
Our client have an WTL Windows Application that uses libgaim 1.5, and some time ago I started an update effort to libgaim 2.0 (with beta 6 release).
After the expected adjustments on some files and MSVC projects, build of binaries, and initial connecting tests, I started the full test job that is taking me completely lost.
Starting with ICQ protocol, I was having some problems with connection establishment, contact addition, sometimes I have exceptions during disconnection, and other problems.
To fix the connecting establishment problem I was forced to add some "Sleep" instructions, and now it works fine. But, this is not an acceptable solution for me.
And I found nothing at all on Internet that can be of any help.
I have a strong impression that I'm facing lots of sincronization problems.
It's the same with the add contact situation. When I debug the application stopping on almost all stages of contact adding procedure, the process is completed successfully.
But, when I try to do the same thing without debuging the application (running with CTRL+F5 on VisualStudio), the operation is not completed and the protocol hangs up.
Considering that the application was not developped by us, I'm trying to find out any possible change or inconsistency analysing the GTK code agains the adapted code of this application, but after some adjustments, the problem persists.
On an attempt to get things better, I compiled almost all the dependency libraries with MSVC, that are: glib version 2.12.7, gettext version 0.14.5, libiconv version 1.9.1, libxml2 version 2.6.24, zlib version 1.2.3, and libpng version 1.2.16 (although I don't know whether the last 2 of them are required by the application or libgaim).
I've done that because I saw that the available binaries were linked with msvcrt.dll, while the libgaim and the application was linked against msvcr71.dll (I'm using VS 2003), what was considered a bad situation by some foruns that I was looking for answer.
As nothing worked, I chose to not build the "NSS version 3.11.4" and "NSPR version 4.6.4" binaries too, using the binaries available on Internet.
So... that's it.
I confess I've never got so lost on my entire life, and expect you guys could put some light on this.
Any help will be very appreciated!
Thanks!
It sounds very much like you're running into problems related to the new win32 GIOChannel implementation in Glib >= 2.8.0.
In the win32 build of Pidgin (the GTK+ UI), we override the current Glib implemenation to use the one from Glib 2.6.10 (see gtkeventloop.c:99). You'll need to do the same thing.
I'm very curious about this win32 UI that you've created. Is it available somewhere?
Hi Daniel, and thank's for the post.
If you're talking about the litle change on gtkeventloop given by lines:
<!-- CODE FRAGMENT -- BEGIN -->
#ifdef _WIN32
channel = wgaim_g_io_channel_win32_new_socket(fd);
#else
channel = g_io_channel_unix_new(fd);
#endif
<!-- CODE FRAGMENT -- END -->
Yeah, I've done that update already.
Without it, even debugging I couldn't create a contact.
Analising the callstack when debugging with old glib versions gave me the idea to search on GTK's version of this file for changes agains the one used by our client.
After that change, I could finally acchieve the condition I could replicate only with old glib binaries, that is to add the contact while debugging.
With neither situations I got success adding the contact with no application debug.
That's why I think this could be a sincronization problem. Although, a friend of mine suggested that this could be a memory corruption problem too.
Well... I'll be very thankfull whether you can suggest anything else as the possible source of my problem.
Thanks in advance, and bye.
P.S. This application was created by out customer and we are only making some adjustments/improvements, but you can find it out on "http://messenger.uol.com.br/".
You're not trying to use libpurple from multiple threads, are you?
Sorry Daniel, but I'm not quite sure I understood your question.
Are you questioning me whether our customer's application uses more than one thread when interfacing with libpurple ?
Is this your question about ?
If it is, I'm not sure about the application as a whole, but for this especific situation (contact creation), no aditional thread is created.
A confirmation window is presented to the user and after that we proceed with a very similar code used on GTK example, as follows:
<!-- CODE FRAGMENT -- BEGIN -->
// New contact, create gaim buddy
pBuddy = gaim_buddy_new(pAccount, pszNormalizedUTF8Contact, NULL);
// Add buddy to Gaim local buddy list and to remote server list...
if (pBuddy != NULL)
{
// Create/get group
if (pGroup == NULL)
{
pGroup = gaim_group_new(pszUTF8Group);
gaim_blist_add_group(pGroup, NULL);
}
if (pGroup != NULL)
{
gaim_blist_add_buddy(pBuddy, NULL, pGroup, NULL);
gaim_account_add_buddy(pAccount, pBuddy);
retError = IM_PROTOCOL_ERROR_SUCCESS;
}
}
<!-- CODE FRAGMENT -- END -->
I hope my reply be helpfull on some way.
Thanks.
libpurple isn't at all thread safe, so you need to make sure that all access are from a single thread. If several threads are involved, something elsewhere may be causing the problems here.
Of course, this may not be problem.
It is hard to say what could be the specific problem since I haven't seen any details about what is happening.
Yeah... I know.
Anyway, I think it should not be that sort of problem, because the application is the same and everything works fine with libgaim 1.5.
Considering that I'm completely clueless about that for a considerable time, I'm thinking whether I should try to get to the origins and build libpurple, and all plugins and protocols (including our customer's one) using gcc on cygwin, instead of insist on those binaries created by MSVC.
Is a fact that our customer insist on using MSVC projects to build all binaries, and that this wasn't a problem until now, but I think this is a good try.
Thank's anyway, and please post any new ideia you can have about this, ok?
Best regards, Mauro.