chia-plotter icon indicating copy to clipboard operation
chia-plotter copied to clipboard

Since new version: plotting randomly crashes

Open Aminacatim opened this issue 3 years ago • 8 comments

Since Update on new version i get After 1-12 Plots a error. Problem on 3 different plotting systems. Plotting randomly stops. I have also one system with old madamax, and its working fine.

System 1: i9 10900F 64gb DDR4 3600mhz System 2: 2x XEON 2698v4 64gb DDR4 2333mhz System 3: Ryzen 5950x 64gb DDR4 3200mhz

Old madmax, without problems: System 4: i9 10900F 64gb DDR4 3600mhz

Before update, I plotted about 5000 plots without any problems or crash.

Nvme ssd No OC, RAM in BIOS Set to 3200 or 3600mhz.

LOG:

chia_plot: /home/aminakoyim/chia-plotter/include/chia/bitfield_index.hpp:45: std::pair<long unsigned int, long unsigned int> bitfield_index::lookup(uint64_t, uint64_t) const: Assertion `bitfield_.get(pos) && bitfield_.get(pos + offset)' failed.

Aminacatim avatar Sep 11 '21 07:09 Aminacatim

I met the same issue, the platform is AMD 5900X , 128GB ddr4 3400 memory and ASUS x570 system board is running at Ubuntu 20.04. @Aminacatim, can you share me the old plot version?

freediy888666 avatar Sep 16 '21 03:09 freediy888666

Hi! I have this error with madmax (plotting K29 for Chives):

terminate called after throwing an instance of 'std::runtime_error' what(): thread failed with: thread failed with: bucket index out of range ./plot-madmax: line 7: 439947 Aborted (core dumped) chia_plot -k 29 -r 2 -t $1 -d $2 -n $3 -f <miFarmerKey> -p <miPublicPoolKey> -x 9699

Ryzen 5 1600 AF, 2x8GB GeIL 3200MHz + 4GB of SWAP, Ubuntu Server 20.04. No overclock

I have 2 other instances of madmax working well, but one in same nvme (temp) + hdd (final dir) is crashing like above...

Chiqui1234ok avatar Sep 22 '21 15:09 Chiqui1234ok

I don't know if this is related, but I've noticed that in DiskTable.h, there is a possible overflow while doing fseek in read_block. The offset can go over 2Gb, while fseek accepts only signed 32-bits. On Windows, I believe _fseeki64 should be used instead; I don't know about Linux...

gmit3 avatar Sep 27 '21 11:09 gmit3

I don't know if this is related, but I've noticed that in DiskTable.h, there is a possible overflow while doing fseek in read_block. The offset can go over 2Gb, while fseek accepts only signed 32-bits. On Windows, I believe _fseeki64 should be used instead; I don't know about Linux...

If that was the case, all plots would be invalid...

madMAx43v3r avatar Sep 29 '21 09:09 madMAx43v3r

Newer versions use more threads in certain phases, which could cause more hardware issues.

madMAx43v3r avatar Sep 29 '21 10:09 madMAx43v3r

I don't know if this is related, but I've noticed that in DiskTable.h, there is a possible overflow while doing fseek in read_block. The offset can go over 2Gb, while fseek accepts only signed 32-bits. On Windows, I believe _fseeki64 should be used instead; I don't know about Linux...

If that was the case, all plots would be invalid...

I could be wrong, of course, but I can consistently reproduce this...

gmit3 avatar Sep 29 '21 10:09 gmit3

I already managed to solve the problem activate virtualization and the ram memory was at 3200 xmp change it to 2400 by default and the madmax plots without interruptions do not overclock ram memories

Geosurvival avatar Nov 14 '21 02:11 Geosurvival

Hello. I also had thread failed error when plotting chives purely in RAM. Adding -w (wait for copy) parameter solved the issue.

pedrosvk avatar Nov 18 '21 11:11 pedrosvk