MSN protocol debugs cause crash!

[Marty]

Thanks for the response, Ethan.  I agree that this is a bug in the OS/2 C runtime 
(it should not crash).  Our GCC 4.4.x C runtime library is immature and a bit buggy 
and incomplete in some areas.  For example, I had to roll my own select() function 
to get the right level of compatibility.  :-/

I'll see if I can find the time to put together a patch, but in the meantime, just 
filtering these messages is working well for me, while I get the rest of my GUI up 
and running.

On a completely different subject, has anyone given any thought to making libpurple 
thread-friendly?  I'm jumping through major hoops here to keep all of the libpurple 
stuff happening in the same thread.  OS/2 apps and APIs really lend themselves much 
more readily to multiple threads.  Serialization for libpurple isn't too much of a 
problem except when it comes to all the callback routines popping up at "random" 
times.  This can very quickly lead to deadlocks when the libpurple code initiates an 
action that should affect the GUI, and the GUI is waiting for exclusive use of 
libpurple code.  My solution so far has been just to use a socketpair and add this 
as a GLib read trigger, with a callback that handles any functions that the GUI 
needs libpurple to execute.  This ensures that all the libpurple stuff happens in 
the main GLib thread.  But this seems like a bit of overkill for just inter-thread 
communication.

On Thu, 6 May 2010 12:49:20 -0400, Ethan Blanton wrote:

>Marty spake unto us the following wisdom:
>> After much tracing around, I found that one of the debugs coming out
>> from soap.c was longer than 64KiB.  It was one of the "current: ..."
>> prints, where it shows the contents of what was received over the
>> secure connection.  When this string is sent through a single printf
>> (at least on my platform), absolutely AWEFUL and very random things
>> happen.  I'm not sure if other C runtime libraries support such a
>> large string in printf/vprintf, but mine certainly doesn't.
>
>Looking at the C standard, I believe that it is legal for OS/2 to fail
>to print this string, per the following sentence:
>
>    The number of characters that can be produced by any single
>    conversion shall be at least 4095.
>
>There seem to be no other references to length or size in the relevant
>portions of the stdio documentation, although my look was only
>cursory.  However, I would argue that *crashing* is not an acceptable
>failure mode; truncating the string in question would be an acceptable
>failure mode.  In the absence of more compelling evidence, I view this
>as an OS/2-specific operating system bug, and not something we should
>really worry about in libpurple.  (The reason being that a legal
>truncation of this string doesn't affect Pidgin's primary
>functionality; were this in such functionality, I'd argue that we need
>to truncate this to 4kB chunks.)  That said, I think we should accept
>a patch which carefully splits the logged data into 4kB chunks,
>*provided that* the large data in question is being passed through a
>%s conversion.
>
>Ethan