Does anyone have any issues with there scrypt miners just stopping after like 10 minutes of mining? Its driving me crazy trying to get them to not drop out, the hashrate drops to 0 and no shares. I dont get this issue on any other pool
ongoing issue with sha/scrypt ports. Shouldn't be every 10 mins though that sounds like it's something else. There can ben stretches of 6-8 hours without a stratum reset, but can also be times of one or two an hour...
Hope to have new stratum code some day soon.
If anyone is handy with C++ this is the most common of a few segfaults I seem to get:
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffcebff5700 (LWP 23435)]
0x00007ffff65ffc37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0 0x00007ffff65ffc37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff6603028 in __GI_abort () at abort.c:89
#2 0x00007ffff663c2a4 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7ffff674a6b0 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3 0x00007ffff66479b2 in malloc_printerr (ptr=
#4 malloc_consolidate (av=av@entry=0x7ffd50000020) at malloc.c:4165
#5 0x00007ffff6648ce8 in _int_malloc (av=0x7ffd50000020, bytes=6016) at malloc.c:3423
#6 0x00007ffff664b6c0 in __GI___libc_malloc (bytes=6016) at malloc.c:2891
#7 0x00007ffff739cdad in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x0000000000412855 in client_thread (p=0x7a) at client.cpp:418
#9 0x00007ffff7bc4184 in start_thread (arg=0x7ffcebff5700) at pthread_create.c:312
#10 0x00007ffff66c337d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
https://github.com/tpruvot/yiimp/tree/next/stratum
Caveat: I am not strong in c++ but have lots of exepience analysing system crashes.
The traceback only contains system code, I don't know if you trimmed it but if you have level #11 it might be where
the application called clone.
The crash itself occurred while allocating memory while cloning a process. malloc detected memory corruption:
#3 0x00007ffff66479b2 in malloc_printerr (ptr=
This is not an error in the code in the traceback, it likely tripped over prexisting corruption. The data was probably corrupted the last time it
was accessed prior to calling clone.
If you are seeing different crashes it is quite possible they are all the result of the same bug. It may be the same data being corrupted
every time or possibly other data. The victim just happened to be the first proceess to access the data after it was corrupted.
The application probably got hold of a bad pointer somehow and used it to write some data to the wrong place. Due to the cause
being disconnected from the crash these kinds of bugs are hard to find. If the problem is recent it narrows the scope of the problem
to a recent change.
I suggest you try to look for the point of deviation, ie when the crashes first started to see what was changed just prior. Since the crashes
seem fairly consistent you could backout recent changes until the crashes stop.
The well, crashing has been an issue since the start but not these ones, likely because the other bugs were occurring before these crashes were apparent. #8 makes reference to the stratum code but I agree a lot has to do with system code.
#8 0x0000000000412855 in client_thread (p=0x7a) at client.cpp:418
https://github.com/tpruvot/yiimp/blob/next/stratum/client.cpp#L418
A new one:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff66477e3 in malloc_consolidate (av=av@entry=0x7ffdb8000020) at malloc.c:4157
4157 malloc.c: No such file or directory.
#0 0x00007ffff66477e3 in malloc_consolidate (av=av@entry=0x7ffdb8000020) at malloc.c:4157
#1 0x00007ffff664845d in _int_free (av=0x7ffdb8000020, p=
#2 0x0000000000404e6e in job_delete (object=0x7ffdb80aec70) at job.h:82
#3 0x0000000000416fbb in object_prune (list=0x83f7e0
#4 0x000000000040416c in main (argc=
Sorry about the issues man, I was infuriated with my 7950 4 card amd setup 2 years ago so I understand the frustration.