nullclient-ecore: move away the fdhandler re-usage introduced in 96e2dc7
Thanks to new ecore svn changes this is not needed, and causes connection troubles

Posted in enlightenment-devel on 15/04/2009

Ok, It seems that this was a my fault and now I've fixed it too :P

On the first days of the development I found that the only way to
complete the connection was not to create a new fd handler if the client
was asked for one already in use, but using the previous one (also Adium
seems to do this). And I the "connection-fix" patch .
After implementing this I was able to connect, but... Not with my
account using the "pure" MSN protocol (I mean, without using the
"http_method").

Now, after some debugging, I've reverted the patch I did, and do you
know what? The client connects correctly to all the protocols I've
tested and with all the accounts I have. I neither get any error or
segmentation fault.

You can find as attachment what I think can be hopefully considered the
"final version" with the patch against the previous version.

nullclient-ecore: use different lists for timers and inputs to prevent segfaults.
Posted in the enlightenment-devel on 10/04/2009

Well, tonight I've made some new tests with this skeleton client and it
seems that after the ecore svn commit r39913 (that basically removed all
the parts which caused the library to abort as stated in a previous
mail) there are no more crashes related to the e libs.

After few changes (attached) I've also moved away any other experienced
segfault, so it seems that the code is pretty finished and so re-usable
for a GUI client I guess/hope.

However I've to report some tests I've made that unfortunately aren't
all 100% positive :/ :
 - Using the "prpl-msn" protocol in HTTP mode I was always able to
   connect, get messages, notifications and so on.

 - Using the "purple-jabber" protocol (Google Talk) I was always able
   to connect, get messages, notifications and so on.

 - Using the "prpl-msn" in standard mode (so, like this client generally
   does) with my account (that is a very "heavy" one since I've to load
   something like 450 contacts) I can connect, load contacts and so on
   but I really I can sign-in in the server (I mean that I'm visible to
   others and I get notification/messages) only if I run the client in
   valgrind and with libpurple debug enabled! Yes, this is so weird as
   it seems!
   I only once was able to connect to it running it in the normal way...
   Nevertheless, the "valgrind+debug" way seems to work always! :|

 - Using the "prpl-msn" in standard mode with some other MSN accounts
   which count less contacts (yes, I know, I've to contacts! :D), both
   the "standard" and the HTTP connection methods work as expected.

   So, I don't really know what I can do more with this; BTW I figure that
   the bug I've experienced is not so much related to the client, and I
   hope that it is just a "particular" issue (also if the glib nullclient
   isn't affected :().

nullclient-ecore: better description

nullclient-ecore: connection fixes, use the previous used fdhandler
Posted in enlightenment-devel on 02/04/2009:

Ok, I've made some work on this and I've found that the connection
didn't continue because if ecore_purple_input_add was asked for a
previously used fd, it create a new fd_handler instead of using the
existing one.
After this modification (the patch and the fixed client are attached
here), I was able to get Msn connected too without getting anymore the
errors I posted initially.

However, unfortunately, the bugs are not over!  :(

I continued my tests with msn, using the "prpl-msn" protocol. Now, if I
enable the "http_method" option I can connect to it (and receive
messages) correctly with no experienced segfaults.

By the way, if use the standard connection, the client connects but as
soon as the connection is established it segfaults.
Gdb doesn't help me so much (also if I've installed libe* and libpurple
with debugging symbols, so it must come from some other place) giving me
this:
 0xb7ce2c23 in strlen () from /lib/tls/i686/cmov/libc.so.6

It seems like when you strlen a null pointer, but I can't understand why
and where it happens. :|

The only thing that the libpurple debug says me before the crash is
something like:
  (18:52:40) dns: Got response for '(null)'
  (18:52:55) dns: Got response for '\x21\x55\x94'

And this seems all a little strange, since they doesn't seem right dns
requests. Maybe the bugs stays there... Mhmhmh....

Testing again the client with Google talk (so a xmpp server using the
"prpl-jabber" protocol), it continues working like before (i.e.:
connects, gets IMs), but I always get random crashes after that the
connection has been established with ecore that reports:
       max_fd: 98
       cr: 2, cw: 0, ce: 0
       Aborted

I don't really know why this happens (and neither what it means exactly,
I guess something like "too many fd handlers resources requested"?!),
however it never happens after a first fresh compilation.
It uses to happen after that I kill an instance and I re-run it many
times... It's all so weird for me :|.

nullclient-ecore: change the #define's according to the new name

nullclient-ecore: first commit of a libpurple based client working with ecore
Posted on enlightenment-devel on 31/03/2009:

Hello, today as a first step, I've tried to port the libpurple example
"nullclient.c" to make it use the ecore_loop instead of the GMainLoop.

To get this, I had mostly to write the wrapper functions needed to
populate the PurpleEventLoopUiOps struct.
Thanks to the ecore_timer* and the ecore_main_fd* functions all this was
quite easy, and you can see my result looking at the nullclient-ecore.c
attached file.

Unfortunately testing it with the msn-purple plugin (I've tried also
with Facebook, but I've some issues with the certs) the test client
attached segfaults. As you can easily try (but I could attach also some
logs, if you need) the client runs correctly and initializes the
connection, however after getting and sending some data (wireshark
confirms it too :P), it crashes.  :(

Using the standard connection mode with gdb I get this:

> > (01:42:42) dns: DNS query for 'login.live.com' queued
> > (01:42:42) dns: Successfully sent DNS request to child 2317
> > (01:42:43) dns: Got response for '(null)'
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread -1214175024 (LWP 2314)]
> > 0xb7ef469d in host_resolved (data=0x80ade50, source=12, cond=PURPLE_INPUT_READ)
> >     at dnsquery.c:558
> > 558             purple_input_remove(query_data->resolver->inpa);
> > (gdb) dns[2317]: nobody needs me... =(

While using the Http mode (in the case of msn) I get this:

> > (01:44:38) certificate: Successfully verified certificate for login.live.com
> > (01:44:39) soap: Sending secure request.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread -1213843248 (LWP 2330)]
> > 0xb7685386 in msn_soap_write_cb_internal (data=0x80adf10, fd=<value optimized out>,
> >     cond=<value optimized out>, initial=0) at soap.c:546
> > 546             written = purple_ssl_write(conn->ssl, conn->buf->str + conn->handled_len,

However I figure that they depends on the same issue, but from my
knowledges I can't really understand where I'm wrong  :( .

nullclient: let's move to nullclient-ecore!

nullclient: remove the defines.h
To few things there to be useful :P

nullclient: first import of the glib nullclient to be ported to ecore!