search

fireice-uk / xmr-stak

Free Monero RandomX Miner and unified CryptoNight miner
GNU General Public License v3.0
4.05k stars 1.79k forks source link

Dev mining crashes xmr-stak #2256

Open jwatte opened 5 years ago

jwatte commented 5 years ago

I'm running 4 cores of a core i5-8400 on Ubuntu 18.04.2 running inside docker-ce 18.09.2 (the docker container hosts the xmr-stak environment in an ubuntu server image, but binds the state from a local mount)

When xmr-stak decides to disconnect from my regular pool and connect to the "dev" pool for its 2% mining donation, it crashes, everytime:

[2019-02-22 05:57:39] : Fast-connecting to dev pool ...
/var/lib/xmr-stak/run.sh: line 3:     7 Done                    echo ""
     8 Segmentation fault      (core dumped) | /var/lib/xmr-stak/xmr-stak-linux-2.8.3-cpu/xmr-stak --currency monero -u 49bPQLH4VNG89NRr6DjfqVenBSNjCpWV8JSrNy1777cHc15brT2MAU2BqVPtt58AeohBsxkyEHs8nMdxw8yzqNyjBMxUjK9.cube -O ca.minexmr.com:6666 -i 9840 -c /var/lib/xmr-stak/config.txt --cpu /var/lib/xmr-stak/cpu.txt -p ""

The command line is:

echo "" | /var/lib/xmr-stak/xmr-stak-linux-2.8.3-cpu/xmr-stak --currency monero -u 49bPQLH4VNG89NRr6DjfqVenBSNjCpWV8JSrNy1777cHc15brT2MAU2BqVPtt58AeohBsxkyEHs8nMdxw8yzqNyjBMxUjK9.cube -O ca.minexmr.com:6666 -i 9840 -c /var/lib/xmr-stak/config.txt --cpu /var/lib/xmr-stak/cpu.txt -p ""

xmr-stak.log

cpu.txt

config.txt

Spudz76 commented 5 years ago

I wouldn't use -p "" because that's just weird and probably not doing exactly what you want (which is just not creating a pools.txt? that is not a tested option but nice try)

Let it generate pools.txt because the commandline options always override it anyway so it doesn't matter one bit if its there and you have pools on the commandline.

Giving it a blank name is probably what is crashing it. There is no check for that and so it passed an empty string into file access functions which probably explodes because you can't have a blank filename.

jwatte commented 5 years ago

Huh? -p is pool password:

xmr-stak --help
-p, --pass PASSWD          pool password, in the most cases x or empty ""

Note that it mines fine on minexmr.com for 98 minutes before it dies trying to connect to the developer pool for the 2 minute donation. This is much more likely to be related to, say, turning on TLS, and maybe the dev pool doesn't like that. It's OK for me because docker restarts the miner, but that means the developer share isn't actually being mined.

Spudz76 commented 5 years ago

I never use the short opts, so not really surprising I didn't know which short opt was which long opt.

So then if you use a non TLS pool port does it switch and work fine?

jwatte commented 5 years ago

No idea. Not really a problem that affects me.

psychocrypt commented 5 years ago

I will try to reproduce it. Do you mine with gpu or cpu?

Jon Watte notifications@github.com schrieb am Sa., 23. Feb. 2019, 06:31:

No idea. Not really a problem that affects me.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fireice-uk/xmr-stak/issues/2256#issuecomment-466618799, or mute the thread https://github.com/notifications/unsubscribe-auth/AYsxtiaDtWkk4-kpwckEcAhhQok2ZRaYks5vQNJKgaJpZM4bKOCd .

Forbo commented 5 years ago

I am getting the same problem while CPU mining.

psychocrypt commented 5 years ago

which currency do you mine?

Forbo commented 5 years ago

Monero.

fusionstream commented 5 years ago

Same here on Fedora. Cpu mining only.

Forbo commented 5 years ago

Still happening with 2.10.4, CPU only mining Monero. Is there a way I can increase verbosity so that I might be able to provide something more than Fast-connecting to dev pool ... Segmentation fault (core dumped)

Spudz76 commented 5 years ago

If there was an actual core dumped, you can use that to find out a backtrace of sorts about what went wrong. I have never done it I just know that's what it's for. GDB maybe?

most by default are set to not dump actual core files (even when it says core dumped) you may have to enable that

Are you SSL on normal pool? Suspecting that shifting from SSL to non (for devpool which is and will not be SSL) may be part of what causes this, because not everyone sees it and maybe running non-SSL pools would 'fix' it.

I wouldn't know as I do code stuff and spend a lot of time here so I've never had devpool enabled. You could also compile with devpool off, and manually donate some coindusts on your favorite holiday or whatever.

psychocrypt commented 5 years ago

please post your pools.txt

Forbo commented 5 years ago 

/*
 * pool_address    - Pool address should be entered as "pool_address:port" (e.g "pool.ryo-currency.com:4444"). Only stratum pools are supported.
 * wallet_address  - Your wallet, or pool login.
 * rig_id          - Rig identifier for pool-side statistics (needs pool support).
 * pool_password   - Can be empty in most cases or "x".
 * use_nicehash    - Limit the nonce to 3 bytes as required by nicehash.
 * use_tls         - This option will make us connect using Transport Layer Security.
 * tls_fingerprint - Server's SHA256 fingerprint. If this string is non-empty then we will check the server's cert against it.
 * pool_weight     - Pool weight is a number telling the miner how important the pool is. Miner will mine mostly at the pool
 *                   with the highest weight, unless the pool fails. Weight must be an integer larger than 0.
 */

"pool_list" :
[
    {"pool_address" : "monerohash.com:9999", "wallet_address" : "REDACTED", "rig_id" : "", "pool_password" : "x", "use_nicehash" : false, "use_tls" : true, "tls_fingerprint" : "", "pool_weight" : 1 },
],

/*
 * Currency to mine. Supported values:
 *
 *    aeon7 (use this for Aeon's new PoW)
 *    bbscoin (automatic switch with block version 3 to cryptonight_v7)
 *    bittube (uses cryptonight_bittube2 algorithm)
 *    freehaven
 *    graft
 *    haven (automatic switch with block version 3 to cryptonight_haven)
 *    intense
 *    masari
 *    monero (use this to support Monero's Oct 2018 fork)
 *    qrl - Quantum Resistant Ledger
 *    ryo
 *    turtlecoin
 *    plenteum
 *    xcash
 *
 * Native algorithms which do not depend on any block versions:
 *
 *    # 256KiB scratchpad memory
 *    cryptonight_turtle
 *    # 1MiB scratchpad memory
 *    cryptonight_lite
 *    cryptonight_lite_v7
 *    cryptonight_lite_v7_xor (algorithm used by ipbc)
 *    # 2MiB scratchpad memory
 *    cryptonight
 *    cryptonight_gpu (for Ryo's 14th of Feb fork)
 *    cryptonight_superfast
 *    cryptonight_v7
 *    cryptonight_v8
 *    cryptonight_v8_double (used by xcash)
 *    cryptonight_v8_half (used by masari and stellite)
 *    cryptonight_v8_reversewaltz (used by graft)
 *    cryptonight_v8_zelerius
 *    # 4MiB scratchpad memory
 *    cryptonight_bittube2
 *    cryptonight_haven
 *    cryptonight_heavy
 */

"currency" : "monero",
Spudz76 commented 5 years ago

SSL is the trigger, seems confirmed. Every other post about this type of crash the userpool was also SSL.

fusionstream commented 5 years ago 

// generated by xmr-stak/2.5.1/4e72408ff/master/win/nvidia-amd-cpu/20

/*
 * pool_address    - Pool address should be in the form "pool.supportxmr.com:3333". Only stratum pools are supported.
 * wallet_address  - Your wallet, or pool login.
 * rig_id          - Rig identifier for pool-side statistics (needs pool support).
 * pool_password   - Can be empty in most cases or "x".
 * use_nicehash    - Limit the nonce to 3 bytes as required by nicehash.
 * use_tls         - This option will make us connect using Transport Layer Security.
 * tls_fingerprint - Server's SHA256 fingerprint. If this string is non-empty then we will check the server's cert against it.
 * pool_weight     - Pool weight is a number telling the miner how important the pool is. Miner will mine mostly at the pool
 *                   with the highest weight, unless the pool fails. Weight must be an integer larger than 0.
 *
 * We feature pools up to 1MH/s. For a more complete list see M5M400's pool list at www.moneropools.com
 */

"pool_list" :
[
        {"pool_address" : "xmr-asia1.nanopool.org:14433", "wallet_address" : "mywalletaddress.myminer/myemail@domain.tld", "rig_id" : "", "pool_password" : "x", "use_nicehash" : false, "use_tls" : true, "tls_fingerprint" : "", "pool_                                                                                         weight" : 1 },
],

/*
 * Currency to mine. Supported values:
 *
 *    aeon7 (use this for Aeon's new PoW)
 *    bbscoin (automatic switch with block version 3 to cryptonight_v7)
 *    bittube (uses cryptonight_bittube2 algorithm)
 *    graft
 *    haven (automatic switch with block version 3 to cryptonight_haven)
 *    intense
 *    masari
 *    monero (use this to support Monero's Oct 2018 fork)
 *    qrl - Quantum Resistant Ledger
 *    ryo
 *    turtlecoin
 *
 * Native algorithms which not depends on any block versions:
 *
 *    # 1MiB scratchpad memory
 *    cryptonight_lite
 *    cryptonight_lite_v7
 *    cryptonight_lite_v7_xor (algorithm used by ipbc)
 *    # 2MiB scratchpad memory
 *    cryptonight
 *    cryptonight_v7
 *    cryptonight_v8
 *    # 4MiB scratchpad memory
 *    cryptonight_bittube2
 *    cryptonight_haven
 *    cryptonight_heavy
 */

"currency" : "monero",
NaiveWang commented 5 years ago

same issue, i was trying to mine monero on supportXMR and then encountered a segmentation fault, i think it is the problem of connections. I've used the latest version of 2.10.4 cpu linux release, currency was set to cryptonight_r. when i use gdb i found this below:

[2019-05-10 15:52:41] : Fast-connecting to pool.supportxmr.com:3333 pool ...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Thread 2 "xmr-stak" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7ff8700 (LWP 21438)]
0x00007ffff4fc7703 in ?? () from /usr/lib/libnss_resolve.so.2

then i ran the benchmark, the results seemed bizarre:

[2019-05-10 15:56:15] : Mining coin: cryptonight_r
!!!! Doing only a benchmark and exiting. To mine, remove the '--benchmark' option. !!!!
[2019-05-10 15:56:15] : Prepare benchmark for block version 0
[2019-05-10 15:56:15] : Starting 1x thread, affinity: 0.
[2019-05-10 15:56:15] : hwloc: memory pinned
[2019-05-10 15:56:15] : Starting 1x thread, affinity: 2.
[2019-05-10 15:56:15] : hwloc: memory pinned
[2019-05-10 15:56:15] : Starting 1x thread, affinity: 4.
[2019-05-10 15:56:15] : hwloc: memory pinned
[2019-05-10 15:56:15] : Wait 30 sec until all backends are initialized
[2019-05-10 15:56:45] : Start a 60 second benchmark...
[2019-05-10 15:57:45] : Benchmark Thread 0 cpu: 0.0 H/S
[2019-05-10 15:57:45] : Benchmark Thread 1 cpu: 0.0 H/S
[2019-05-10 15:57:45] : Benchmark Thread 2 cpu: 0.0 H/S
[2019-05-10 15:57:45] : Benchmark Total: 0.0 H/S

+++++++++++++ meanwhile the version 2.8 works fine while it was outdated since the cn/r was not implemented yet....

fusionstream commented 4 years ago

The workaround is to run the executable from bash with a while loop.

fusionstream commented 4 years ago

I say workaround, but that probably impacts performance. Nevertheless, I can now leave it unattended.

psychocrypt commented 4 years ago

could you please update to the latest version and try it again.

NaiveWang commented 4 years ago

After compiled from source with latest version, no problem any more. It seems like a connection issue, now it has been solved.