Skip to content
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

SIGSEGV in scrypt_1024_1_1_256_sp with musl #723

Open
TheBiggerGuy opened this issue Oct 20, 2017 · 6 comments
Open

SIGSEGV in scrypt_1024_1_1_256_sp with musl #723

TheBiggerGuy opened this issue Oct 20, 2017 · 6 comments

Comments

@TheBiggerGuy
Copy link

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
Copy link
Author

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 libuv/libuv#1507 for similar issue I belive

TheBiggerGuy added a commit to TheBiggerGuy/bfgminer that referenced this issue Oct 20, 2017
When using musl libc the default statck size is too small for the scrypt
code that uses alloca.

see: luke-jr#723
TheBiggerGuy added a commit to TheBiggerGuy/bfgminer that referenced this issue Oct 20, 2017
When using musl libc the default statck size is too small for the scrypt
code that uses alloca.

see: luke-jr#723
@luke-jr
Copy link
Owner

luke-jr commented Oct 21, 2017

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

@TheBiggerGuy
Copy link
Author

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
Copy link
Author

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

@jstefanop
Copy link
Collaborator

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

@jstefanop
Copy link
Collaborator

@TheBiggerGuy what scrypt device are you using?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants