Since new version: plotting randomly crashes

[Aminacatim]

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, uint64t) const: Assertion `bitfield.get(pos) && bitfield_.get(pos + offset)' failed.

[freediy888666]

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?

[Chiqui1234ok]

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...

[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...

[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...

[madMAx43v3r]

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

[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...

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

[Geosurvival]

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

[pedrosvk]

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