On 7 Oct 2017, at 00:11, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
2017-10-06 2:39 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>>:
On 6 Oct 2017, at 05:34, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Hi Nicolas
2017-10-05 16:04 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2017-10-05 15:42 GMT+02:00 Hernán Morales Durand <hernan.morales@gmail.com>:
I tried, now I get an exception "Use ExternalAddress instead!"
I guess the message means Use ExternalAddres in the "out" parameter. But replacing byte with ExternalAddress also crashes the VM (crash.dmp attached).
2017-10-05 10:03 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 5 Oct 2017, at 14:55, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Forgot to comment that Nacl worked in Pharo 5.
yes but that was with NB and there are some minimum differences. I do not have the library and I lack the time to try more, but seems to me that here:
apiCryptoHashSha512Output: outByteArray input: inByteArray inputLength: inByteArrayLength
^ self ffiCall: #(long crypto_hash_sha512_ref (byte * outByteArray, byte * inByteArray, ulonglong * inByteArrayLength)) module: 'libsodiumâ.
instead "byte * outByteArrayâ, you want "byte **outByteArrayâ
can you try?
Esteban
Hmm no, internet reference says:
extern int crypto_hash_sha512_ref(unsigned char *,const unsigned char *,unsigned long long);
The error is rather that you pass the address of length rather than the length... So you pass an erroneous length that may lead to a segfault...
Yes, that extra * was the error indeed. Thank you Nicolas.
I do not know the VM internals, however I wonder if it is understandable to expect a VM crash for a typo like this? Maybe it is too difficult to catch in the VM side?
Just asking, not criticizing anyone's work.
Of course that is normal. This is C code, any error has the potential to crash your program. In C there are no runtime safe guards.
There is a reason why we like/use Pharo.
However there are a couple of lightweight libraries which claim to provide exceptions for C: https://github.com/guillermocalvo/exceptions4c <https://github.com/guillermocalvo/exceptions4c> or this one https://github.com/psevon/exceptions-and-raii-in-c <https://github.com/psevon/exceptions-and-raii-in-c>
I wonder if something like that could be used in UFFI
Nothing in C *ever* will save you from accessing bad memory blocks. And yes, it will always crash your program. those links you point are exception mechanisms, a set of tools to easy the catch of programming exceptions. But, if you try to read a chunk of memory in, say 0x8000 and the data/function that should be there is now garbage, youâre screw. as Sven pointed, thatâs why we use higher level languages, with GC and all that. Esteban
Hernán
Cheers,
Hernán
2017-10-05 3:23 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:
H Hernani,
Most probably is a problem in the library and not UFFI, but I could not know without a crash report.
Esteban
On 5 Oct 2017, at 06:00, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Hi,
I ported Nacl (a libsodium wrapper) from the old FFI apicall: format to use the UFFI ffiCall:, but there should be something terribly wrong because is crashing the VM, in both Windows 8.1 and Linux.
How to reproduce in Pharo 6.1
Metacello new smalltalkhubUser: 'tonyg' project: 'Crypto-Nacl'; configuration: 'Nacl'; version: #development; load.
(Nacl hashString: 'The quick brown fox jumps over the lazy dog') hex
This one does deserve a bug entry?
Cheers,
Hernán