SIGSEGV in scrypt_1024_1_1_256_sp with musl

TheBiggerGuy commented 7 years ago

When using Alpine Linux with musl libc on an ARM32v6 system

Thread 14 "miner_GSD0aa" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 13764]
0xb6fb437c in memcpy () from /lib/ld-musl-armhf.so.1
(gdb) backtrace 
#0  0xb6fb437c in memcpy () from /lib/ld-musl-armhf.so.1
#1  0x00455210 in scrypt_1024_1_1_256_sp (input=0xb6b9ba4c, input@entry=0xb6b9ba6c,
    scratchpad=scratchpad@entry=0xb6b7b840 ":\204\332\070\061Spv,`\tH\266\063`k\216j\202\247\031\001\211\277\370t=\v\200\367\363\325\033%\355<-'q\203\262\376\252{\326\vI\343\071\304\023\065w\a\264\001v\006Zy\254\265\027\243\345\237\022L\236\203+i\"\246\240\f\262H\216&|\342{\nZ.\200
\226\307\064[\021\201\355D\216\022\347kn\371\300\247Ky\275HL\200\240f?~\031\312\037U\226\347\024\241\210\216_j\257%!\256X\261\333\302/A:w\352Hp\316\063\234\325#)\250\210m\263 \035\340_&\212HY\267\255\235\244ܟ\275i*z\241f$\276\346\344\001", <incomplete sequence \320>,
    ostate=0xb6b7b694, ostate@entry=0xb6b9ba4c) at malgo/scrypt.c:386
#2  0x00456df0 in scrypt_hash_data (out_hash=0x514a30, pdata=<optimized out>) at malgo/scrypt.c:502
#3  0x00416850 in work_hash (work=0x514970) at miner.c:10631
#4  _test_nonce2 (work=0x514970, nonce=<optimized out>, checktarget=<optimized out>) at miner.c:10656
#5  0x0042d688 in submit_noffset_nonce (thr=0x4984d0, work_in=0x54e950, nonce=3865654045, noffset=<optimized out>) at miner.c:10715
#6  0x0045d57c in gridseed_submit_nonce (thr=0x48df50, work=0xb6b9cb90, buf=0xb6b9cb98 <incomplete sequence \302>) at driver-gridseed.c:273
#7  gridseed_scanhash (thr=thr@entry=0x48df50, work=0xb6b9cb90, work@entry=0x54e950, max_nonce=<optimized out>) at driver-gridseed.c:322
#8  0x0043a0b0 in minerloop_scanhash (mythr=0x48df50) at deviceapi.c:274
#9  0x0043b19c in miner_thread (userdata=0x48df50) at deviceapi.c:772
#10 0xb6fb89d4 in ?? () from /lib/ld-musl-armhf.so.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

TheBiggerGuy commented 7 years ago

Current working theory is the alloca fails due to a small thread stack size. This only later on first reference causes an error.

https://github.com/luke-jr/bfgminer/blob/bfgminer/malgo/scrypt.c#L501

See https://github.com/libuv/libuv/issues/1507 for similar issue I belive

luke-jr commented 7 years ago

scrypt is not maintained. Would you like to maintain it?

TheBiggerGuy commented 7 years ago

I would not go as far as a full maintainer but I am looking into getting it stable for my use case. Is it "stable" or is another miner advised for scrypt (using ASICs)?

TheBiggerGuy commented 7 years ago

The #724 pull request has fixed the above issue for me (over two hours sable vs. sub 30 seconds crash).

jstefanop commented 7 years ago

ill check the PR and see if I can duplicate the issue with my scrypt drivers

jstefanop commented 7 years ago

@TheBiggerGuy what scrypt device are you using?

luke-jr / bfgminer

SIGSEGV in scrypt_1024_1_1_256_sp with musl #723