MBP not enough allocatable device-memory

[BeanBagKing]

I'm wondering if anyone else has run into this issue when using a Macbook Pro. If I force Device 1 (-D 1), everything seems to work fine. However, anything using device 2 (-D 2 or -D 1,2) eventually runs into a allocatable device-memory error and stops. Judging by the location of the benchmark, the error is occuring when it reaches the scrypt hashtype.

I suspect this is expected given the small amount of memory available to that device. If not though, I wanted to make sure others were aware of it, and I'll post it to the github issues. Even if it's expected, would the desired behavior be to skip that hashtype and move on?

Code:

XXX@XXX:~/xxx/hashcat-3.00$ ./hashcat.app -b
hashcat () starting in benchmark-mode...

OpenCL Platform #1: Apple
=========================
- Device #1: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, skipped
- Device #2: Intel(R) Iris(TM) Graphics 6100, 384/1536 MB allocatable, 48MCU

[..]

Hashtype: phpass, MD5(Wordpress), MD5(phpBB3), MD5(Joomla)

Speed.Dev.#2.:   254.6 kH/s (94.43ms)

- Device #2: Device does not provide enough allocatable device-memory to handle this attack

XXX@XXX:~/xxx/hashcat-3.00$

Edit: I take that back, -D 1 eventually fails as well.

Code:

XXX@XXX:~/xxx/hashcat-3.00$ ./hashcat.app -D 1 -b
hashcat () starting in benchmark-mode...

OpenCL Platform #1: Apple
=========================
- Device #1: Intel(R) Core(TM) i5-5287U CPU @ 2.90GHz, 2048/8192 MB allocatable, 4MCU
- Device #2: Intel(R) Iris(TM) Graphics 6100, skipped

[...]

Hashtype: SSHA-512(Base64), LDAP {SSHA512}

Speed.Dev.#1.:  7360.3 kH/s (95.66ms)

Hashtype: LM



ERROR: clEnqueueNDRangeKernel() : -54 : CL_INVALID_WORK_GROUP_SIZE


XXX@XXX:~/xxx/hashcat-3.00$

[atom]

- Device #2: Device does not provide enough allocatable device-memory to handle this attack

This kind of error is actually that you do not have enough (device) memory to handle scrypt. But you're right, it should skip over the error and continue. Please post a GitHub issue for that.

ERROR: clEnqueueNDRangeKernel() : -54 : CL_INVALID_WORK_GROUP_SIZE

This is a known error. For some reason on OSX, on CPU, it's not allowed to use a 2nd (or 3rd) dimension for the kernel execution in GPGPU. It's a runtime limitation which is basically not there, it's a pure software limitation. I can't workaround this, because for bitsliced DES kernel (like LM) it's required. However the problem is the same. It should skip over and continue with the benchmark.