-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Things break on Debian Wheezy with libssl-dev 1.0.1e-2+deb7u12 on 32bit. #1
Comments
Two corrections:
|
Does this still exist? |
I think you forgot to call .read( :bin ) since you are putting it into Buf $content and not Str $content;
So from the 3rd example i'd guess this has to do with SSL forwarding in IO::Socket::SSL closing the socket, although that may be caused by the recent PR that uses IO::Socket::INET since that HTTP message should only be occuring when going to 'http://github.com' not 'https://github.com' Calling .gist/.perl on the IO::Socket::SSL object also causes a segfault, which is why your REPL example segfaults:
So I would guess that we need to add a .perl and .gist method Here is my system info:
|
I suspect the issue still exists on 32bit systems, considering there's still a problem with int sizes in NativeCall. On the other hand, ugexe's code demonstrates working behavior, so I suppose testing again on 32bit should be the next step. |
The 32bit issues have fixed in NativeCall... So one would have to use |
I can reproduce on 64 bit/FreeBSD 10 and Debian Jessie and Wheezy. Details for FreeBSD follow $ openssl version -a $ perl6 -v $ perl6
|
It looks like you are using the REPL, which is known to cause this problem regardless of OS as noted above |
Oops I missed that. But can confirm it also errors inside a script steve@burpy:~/pl6anet $ perl6 test.pl |
FWIW |
:host should be visible now (I forgot to manually rewrite the angle brackets as html entities!) |
Running the example in IO::Socket::SSL, which relies on this library the following behavior can be observed:
In the perl6-m REPL:
Run from a script:
I have added a very basic binding for liberr to try and see if there's an underlying library error that causes this, which I will open a PR for.
With that patch, the string error message came out as follows:
This pointed me towards this debian bug, which in turns points to this bug in libssl. Further searching revealed this more current debian bug, which seems to indicate this is an issue upstream.
I consider it northworthy that the command to verify the behavior on the openssl ticket above works fine and disabling AES-NI as mentioned in the discussion on the openssl ticket did not have any effect.
The text was updated successfully, but these errors were encountered: