Proth Sieve Segfault...

[royanee]

Program received signal SIGSEGV, Segmentation fault.
0x0805dbb2 in std::_Rb_tree_rebalance ()
(gdb) bt
#0 0x0805dbb2 in std::_Rb_tree_rebalance ()
#1 0x40eacea8 in ?? ()
#2 0x080645ac in asievewindowprimebits ()
#3 0xbfffece0 in ?? ()
#4 0x0805d9bd in std::_Rb_tree<unsigned int, std::pair<unsigned int const, std::vector<unsigned int, std::allocator<unsigned int> > >, std::_Select1st<std::pair<unsigned int const, std::vector<unsigned int, std::allocator<unsigned int> > > >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, std::vector<unsigned int, std::allocator<unsigned int> > > > >::_M_insert ()
#5 0x0805d37a in std::_Rb_tree<unsigned int, std::pair<unsigned int const, std::vector<unsigned int, std::allocator<unsigned int> > >, std::_Select1st<std::pair<unsigned int const, std::vector<unsigned int, std::allocator<unsigned int> > > >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, std::vector<unsigned int, std::allocator<unsigned int> > > > >::insert_unique ()
#6 0x0804b5e7 in eratosthenes_window ()
#7 0x08051b98 in next_sieved_p ()
#8 0x08055e19 in main ()

[mklasson]

Looks odd... acute lack of memory or extreme overclocking or something?

[vjs]

royanee,

What was the range your were sieving when it happened?
Is it a happen stance or does it constantly occur at one spot or upon restart?

I'd suggest you re-download, re-install proth to be on the safe side. If you can determine the point at which is crashed I'd resieve it, (i.e. somewhere around 382990-382991G), you may also wish to check sobstatus and see if you have a speed decrease around/before the crash.

[royanee]

256 MB of DDR RAM, so that should be enough, since I wasn't even running much else on the computer (or even sitting at it). It crashed twice, so I restarted (which is a mini-resieve) the client and no problems. The first time I started it, I used gdb (the debugger on my system to get that backtrace when it crashed again). I'm not overclocking at all, so unless the system is running hot, I can't tell. It seems to be stable otherwise. It works just fine. No real logic errors. That is the first time I've seen proth_sieve crash on this computer though. Maybe memory is going bad (like what was happening with the Win compy I was using over the summer...). We'll have to see...

For vjs: It was during the resieve of Mystwalker's "sieved, but too large a gap between factors" range. So, ~338.4T, and the sieve speed was pretty stable before the crash and after the restart.

[vjs]

Humm, I may just resieve that range as well next week.

[royanee]

Hmm, this error seems similar...

Program received signal SIGSEGV, Segmentation fault.
0x0805d2d0 in std::_Rb_tree<unsigned int, std::pair<unsigned int const, std::vector<unsigned int, std::allocator<unsigned int> > >, std::_Select1st<std::pair<unsigned int const, std::vector<unsigned int, std::allocator<unsigned int> > > >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, std::vector<unsigned int, std::allocator<unsigned int> > > > >::lower_bound ()
(gdb) bt
#0 0x0805d2d0 in std::_Rb_tree<unsigned int, std::pair<unsigned int const, std::vector<unsigned int, std::allocator<unsigned int> > >, std::_Select1st<std::pair<unsigned int const, std::vector<unsigned int, std::allocator<unsigned int> > > >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, std::vector<unsigned int, std::allocator<unsigned int> > > > >::lower_bound ()
#1 0x0804b529 in eratosthenes_window ()
#2 0x08051b98 in next_sieved_p ()
#3 0x08055e19 in main ()

[Mystwalker]

At least the smileys get one happy.

Is this error reproducable? Or does it happen apparently at random?

[royanee]

At random... I did a memory test, and no errors... and it's not overclocked. Oh, and here's a new one...

Program received signal SIGSEGV, Segmentation fault.
0x400a2632 in std::__default_alloc_template<true, 0>::allocate () from /usr/lib/libstdc++.so.5
(gdb) bt
#0 0x400a2632 in std::__default_alloc_template<true, 0>::allocate () from /usr/lib/libstdc++.so.5
#1 0x0805cf35 in std::vector<unsigned int, std::allocator<unsigned int> >::reserve ()
#2 0x0804b620 in eratosthenes_window ()
#3 0x08051b98 in next_sieved_p ()
#4 0x08055e19 in main ()

[Mystwalker]

Can you try a prime95 stress test for 24 hours?

A lot of faulty memory only clearly shows in this extreme situation.

btw.:
Is this all one PC? Or does it happen on multiple ones?

[royanee]

One pc... by the way, do you mean mprime? I'm on Linux. I'll run a 24 hour test of that if I can figure out the command.

[Mystwalker]

Yepp, meant mprime.

[royanee]

meh..

Test 1, 400 Lucas-Lehmer iterations of M19922945 using 1024K FFT length.
Test 2, 400 Lucas-Lehmer iterations of M19922943 using 1024K FFT length.
Test 3, 400 Lucas-Lehmer iterations of M18874369 using 1024K FFT length.
Test 4, 400 Lucas-Lehmer iterations of M18874367 using 1024K FFT length.
FATAL ERROR: Rounding was 0.4998147488, expected less than 0.4

[Mystwalker]

I guess it's the memory. Maybe the timings are not correctly read by the BIOS. I think you should try to set them manually.

HTH

[royanee]

Yay! Something helpful! Which settings should I change, and in which direction? Thanks!!!

[Mystwalker]

Things you could try:

1. Lower the memory frequency - check if maybe it's already higher than supported by the memory module.

2. Set the CAS latency (aka CL'x') to a higher value - unless it is at 3, which should be high enough.

3. Increase the voltage a bit - here, serious stress testing has to be done (I'd suggest 2 days 24/7 mprime torture test) as it could be the case that the system only seems stable, but isn't in reality...

[royanee]

I was poking around in the BIOS, and noticed that the Memory was set manually. I set it to: BY SPD, and it's gone through the stress test almost three cycles now. Thanks! I'll leave it running for another day, but it's looking fairly stable.