The failure is a bad alloc, so I do not think that the problem is CPU related. Just for fun, I compiled it once on a Pentium 3 laptop, unfortunately it has this issue. But I encountered it in some recent computers as well. I suspect that for some reason, rieMiner needs much more memory to start, than it actually uses/needs. I will investigate this later in September. I likely just removed one line too much or so.
This exception is throw when "new" in C++ cant allocate memory. In fact calling new not guarantee it will allocate the needed memory. So it throw that exception and you have to handle it in your code, or you can stop throwing the exception and you should check if returned pointer is not null. Second method is slower, so first one is better practice. On P3 machine it is obvious that there is not enough memory, but if you doubt about memory leaks valgrind and gdb are your best friends. They will show you where you allocating memory and not freeing it.
In DGA's fastrie miner there is some points where memory leaks are possible. but they are not a problem. It is always good practice to call "delete" in C++ when you don't need any more allocated memory from heap with "new" and to call mpz_clear for mpz structures, even when there is no obvious point to do it.
Ok, so you are right, I did some quick debugging, and the problem occurs when I use new for an array called segment_hits. It is allocating almost 30 GB... For some reason, the miner is much more sensitive to this problem on Windows than Linux, so I thought at first that it was a Windows specific problem.
Unfortunately, as I did not study the miner optimizations, I do not have any idea of what are the "segment hits" :| ... The huge memory allocation problem seems to be fixable by reducing the max_increments value (with for example 1 << 25 instead of 1 << 29), but this seems to decrease noticeably the performance (by about 40%). But by doing that, I was able to get the Pentium 3 laptop mining properly! It is about 100 x slower than one 2700X unthrottled thread, but would still find a Testnet block each hour. This variable might simply be an user configurable variable, like the sieve size.
I will commit in minutes to reflect these observations (essentially updating the Readme and restore the allocation checks that I stupidly removed). Thank you for pointing out the bad alloc origin.