IIRC this used to be caught by an "out of memory" popup instead of crashing, but the current installer crashes for me when loading a large .sr file (e.g. dcf77_1800s.sr) or importing a large .csv file, for example.
Can you check if the kernel OOM killer killed PV when you encounter this? The thing is that PV can now allocate as much memory as it wants because of the linux kernel's overcommit strategy. Only when PV actually fills it with sample data is when the OOM killer is triggered and shoots PV down for using memory it was told was available. This isn't really PV's fault imo, so until we have a memory limit internal to PV, we unfortunately can't avoid this.
My initial test was on Windows actually, but I'll also check on Linux and Mac OS X for some more data.
Still reproducible on Windows (32bit build, so RAM is pretty limited), PV will just crash. On Linux the following appears in the console when RAM + swap are full: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc The PV window stays around apparently, though, CPU load is pretty high etc. There's no "out of memory" popup from PV itself. To reproduce you can load any huuuge .sr file and if that's not enough open another additional session window and load it again, etc., until you're out of memory.
Fixed in 2c39cfe261f46ba4dd97a403a51e6c11893b6b0a, thanks!