ssl causes faults on sbcl
Closed this issue · 20 comments
There seems to be an issue where if you ssl uris with carrier and lastest cl-async it cases memory faults and other issues.
This works:
(as:with-event-loop ()
(asf:alet ((result (carrier:request "http://www.apple.com/" :return-body t)))
(format t "result: ~s" result))) This one explodes:
(as:with-event-loop ()
(asf:alet ((result (carrier:request "https://www.apple.com/" :return-body t)))
(format t "result: ~s" result)))Let me know if I can help test anything or if you need more information.
Thanks
Sorry, things are a bit crazy right now with work and family stuff. Will look into this as soon as I get the time =]
No worries, thanks for the update. Let me know. :)
Reproduced. Recently merged some PRs in cl-async/cl-libuv, I'm going to pull those down and see if it fixes it.
Great! Let me know ;)
Thanks again.
With the latest cl-libuv I get this (no longer explodes, but has a different error message now):
(as:with-event-loop ()
(asf:alet ((mine (carrier:request "https://www.apple.com/" :return-body t)))
(format t "~%mine: ~s~&" mine)))
<INFO> [23:58:10] carrier carrier.lisp (request) - request: "GET NIL HTTP/1.1^M
Host: www.apple.com^M
^M
"
<INFO> [23:58:30] carrier carrier.lisp (request) -
carrier error: #<TCP-EOF #<SOCKET {100E8C3723}> {100EA93CD3}>
<INFO> [23:58:30] carrier carrier.lisp (request) - c eof
There is no applicable method for the generic function
#<STANDARD-GENERIC-FUNCTION CL-ASYNC:SOCKET-CLOSED (1)>
when called with arguments
(NIL). @nightshade427 Try it with latest cl-async master, this looks quite like one of errors I've fixed in orthecreedence/cl-async#106
Ok, actually fixed it as part of orthecreedence/cl-async#107 (not merged yet at the moment of writing). There was :int vs :pointer confusion in libssl cffi bindings that caused crashes on Linux x86_64 and probably other platforms.
Awesome, look forward to the merge. Will test once merged.
Thanks again :)
Merged, please give it a shot =]
Same, only slightly different it doesnt explode it just hangs:
This works:
(as:with-event-loop ()
(asf:alet ((result (carrier:request "http://www.apple.com/" :return-body t)))
(format t "result: ~s" result))) This one hangs:
(as:with-event-loop ()
(asf:alet ((result (carrier:request "https://www.apple.com/" :return-body t)))
(format t "result: ~s" result)))Try now, please. I'm no longer seeing problems on my end (linux x86_64, sbcl)
The above still hangs for me.
I'm using latest master of cl-async, cl-libuv, carrier.
sbcl --version
SBCL 1.2.6
uname -a
Linux localhost 3.17.2-x86_64-linode48 SMP Mon Nov 3 13:26:05 EST 2014 x86_64 x86_64 x86_64 GNU/Linux
Here is the error after it hangs for long time:
There is no applicable method for the generic function
#<STANDARD-GENERIC-FUNCTION CL-ASYNC:STREAMISH-CLOSED (1)>
when called with arguments
(NIL).
[Condition of type SIMPLE-ERROR]
Restarts:
0: [RETRY] Retry calling the generic function.
1: [ABORT-CALLBACK] Abort cl-async callback.
2: [*EXIT-EVENT-LOOP] Exit the current event loop
3: [RETRY] Retry SLIME REPL evaluation request.
4: [ABORT] Return to SLIME's top level.
5: [ABORT] Abort thread (#<THREAD "repl-thread" RUNNING {100ADE80B3}>)
Backtrace:
0: ((:METHOD NO-APPLICABLE-METHOD (T)) #<STANDARD-GENERIC-FUNCTION CL-ASYNC:STREAMISH-CLOSED (1$
1: (SB-PCL::CALL-NO-APPLICABLE-METHOD #<STANDARD-GENERIC-FUNCTION CL-ASYNC:STREAMISH-CLOSED (1)$
2: ((LAMBDA NIL :IN CARRIER:REQUEST))
3: ((LAMBDA (FAST-HTTP::DATA &KEY (FAST-HTTP::START 0) FAST-HTTP::END) :IN FAST-HTTP:MAKE-PARSE$
4: ((LAMBDA (CARRIER::EV) :IN CARRIER:REQUEST) #<CL-ASYNC:SOCKET-EOF {1013D5B543}>)
5: (CL-ASYNC::EVENT-HANDLER -4095 #<CLOSURE (LAMBDA (CARRIER::EV) :IN CARRIER:REQUEST) {1013C3D$
6: (CL-ASYNC-UTIL:RUN-EVENT-CB CL-ASYNC::EVENT-HANDLER -4095 #<CLOSURE (LAMBDA (CARRIER::EV) :I$
7: ((LAMBDA NIL :IN CL-ASYNC::STREAMISH-READ-CB))
8: (CL-ASYNC-UTIL:CALL-WITH-CALLBACK-RESTARTS #<CLOSURE (LAMBDA NIL :IN CL-ASYNC::STREAMISH-REA$
9: (CL-ASYNC::STREAMISH-READ-CB #.(SB-SYS:INT-SAP #X7FFFDC057E50) -4095 #<unavailable argument>$
10: ((LAMBDA (SB-ALIEN::ARGS-POINTER SB-ALIEN::RESULT-POINTER FUNCTION) :IN "/root/.cache/common$
11: ("foreign function: call_into_lisp")"
It doesnt appear to be carrier direct. Its when you load carrier and drakma-async together. I can repo with smallest setup from my project. Can you use the below and see if you have the same result I do. I use drakma-async to get cookie support util carrier can (#4) and use carrier for everything else because drakma-async has issues downloading large files. So I use the library I can for each use case.
This has the issue
(ql:quickload "carrier")
(ql:quickload "drakma-async")
(as:with-event-loop ()
(asf:alet ((result (carrier:request "https://www.apple.com/" :return-body t)))
(format t "result: ~s" result)))This works
(ql:quickload "carrier")
(as:with-event-loop ()
(asf:alet ((result (carrier:request "https://www.apple.com/" :return-body t)))
(format t "result: ~s" result)))drakma-async uses drakma which includes cl+ssl. cl-async is now using its own ssl implementation and i wonder if its butting heads with cl+ssl. that's my first guess. i'll try to look at this tonight if i get a chance...thanks for the test case.
Yeah no problem, sorry it took so long to narrow down the issue to something more easily reproducable.
Thanks! Let me know what you find out :)
Let me know if there is anything I can do to help :)
Hi Nick, sorry for the delay, been trying to improve the error reporting of cl-async to track this one down (see orthecreedence/cl-async#108). Looks like including cl+ssl with cl-async-ssl creates a memory fault in sbcl. Good catch! I am going to pick away at this today, although we're still doing some holiday stuff over here so I may not finish today.
I think this is fixed. Please pull cl-async (in fact, pull cl-libuv, carrier, and blackbird while you're at it, I want to make sure you're all up to date).
Note that the way this was fixed may cause problems when trying to use cl+ssl with cl-async-ssl loaded, but I haven't tested this and I'm not sure if there's a way to make the two play nicely.
I think this is fixed now. I will re-open if I encounter it again