[flexi-streams-devel] [Fwd: Problem with TLS connection on Franz/ACL8.1]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a report I also sent to cl-xmpp-devel as that is where I discovered it. It does however seem to be more related to Flexi-Streams on ACL8.1. Thanks in advance for any ideas you might have about how to resolve this issue. Best, - -Jason - -------- Original Message -------- Subject: [cl-xmpp-devel] Problem with TLS connection on Franz/ACL8.1 Date: Thu, 25 Oct 2007 18:16:29 +0200 From: Jason S. Cornez <jcornez@alum.mit.edu> To: cl-xmpp-devel@common-lisp.net Hi I know this is a small list and that this problem is likely not to do specifically with CL-XMPP code, but with one of the libraries it uses. So if you can help by even suggesting where better I might ask this, it would be appreciated. Thank you. What follows is run using the latest cl-xmpp and cxml/closure-commons from CVS along with other libraries from asdf-install tarballs. I use ACL8.1 on linux-x86.32. The net result is that the lisp crashes and dies with a segmentation violation. Obviously that in itself is a Franz issue, but this happens because (figure-encoding...) calls (read-byte ...) on a flexi-stream. And I figure this doesn't make much sense. I've traced figure-encoding to see that this is clear. Perhaps there should be a specialized method of figure-encoding for flexi-streams? Again, if you can help me to direct this query to a better place, please let me know. Best, - -Jason CL-USER(6): (trace runes::figure-encoding) (RUNES::FIGURE-ENCODING) CL-USER(7): (xmpp:connect-tls :hostname "localhost") <?xml version='1.0' ?><stream:stream to='localhost' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> 0[2]: (RUNES::FIGURE-ENCODING #<MULTIVALENT stream socket connected from localhost/56698 to localhost/5222 @ #x72766952>) 0* #<STANDARD-METHOD RUNES::FIGURE-ENCODING (STREAM)> 0[2]: returned :UTF-8 (60 115) <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> <?xml version='1.0' ?><stream:stream to='localhost' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> 0[2]: (RUNES::FIGURE-ENCODING #<FLEX::FLEXI-LATIN-1-IO-STREAM @ #x722197ca>) 0* #<STANDARD-METHOD RUNES::FIGURE-ENCODING (STREAM)> _______________________________________________ cl-xmpp-devel mailing list cl-xmpp-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-xmpp-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHIMSBQlm6HDTMLyMRAulqAJ9k3pDbNKbvwFYc/6ZAuywkze2IyACgmr2t qgpe65voZq71z9OqocyY4eg= =e96r -----END PGP SIGNATURE-----
On Thu, 25 Oct 2007 18:29:53 +0200, "Jason S. Cornez" <jcornez@alum.mit.edu> wrote:
This is a report I also sent to cl-xmpp-devel as that is where I discovered it. It does however seem to be more related to Flexi-Streams on ACL8.1.
Thanks in advance for any ideas you might have about how to resolve this issue.
It would be helpful if you could provide a self-contained test case which I can use to reproduce the problem - preferably without the need to load other libraries. Cheers, Edi.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, perfectly understood about the test case. At this point I was just trying to see if this problem sounded familiar to anyone. If I can generate an isolated test case, I certainly will. In the meantime, David Lichteblau wrote me the following that may help: - ---- CL+SSL is known to be broken on Allegro with a failure mode like this. I can only guess why, but since Allegro already includes SSL support, perhaps there is some kind of conflict between the two FFI uses. I think the workaround Edi used in his libraries was to do #+allegro (excl:make-ssl-client-stream ...) #-allegro (cl+ssl:make-ssl-client-stream ...) but if the problem stays unsolved, it would be better to move this kind of hack into CL+SSL itself, so that it wraps the built-in streams on Allegro instead of doing things itself. Unfortunately I don't really have the time for CL+SSL development at the moment, but patches are always welcome, of course. - ---- I'll see what I can do about producing some code that gets past this. - -Jason Edi Weitz wrote:
It would be helpful if you could provide a self-contained test case which I can use to reproduce the problem - preferably without the need to load other libraries.
Cheers, Edi.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHIMdMQlm6HDTMLyMRAkCkAKCLPo19P8mnXTVp1eIxzj8ceoYUsgCgqDbi rgCzNA35fN3V6OXnQ9/14Os= =aes5 -----END PGP SIGNATURE-----
participants (2)
-
Edi Weitz -
Jason S. Cornez