rivetTDA / rivet

RIVET is a tool for Topological Data Analysis, in particular two-parameter persistent homology.
GNU General Public License v3.0
73 stars 24 forks source link

mlesnick's fork crashes with an "INPUT ERROR: std::bad_alloc :END" message #116

Closed delooper closed 6 years ago

delooper commented 6 years ago

I'm using Mike's fork of RIVET: https://github.com/mlesnick/rivet, at commit ae6b6f2f3e411b25c474f2a79f3cfeab744d08a6 and rivet_console is crashing on a metric space with approximately 760 points. RIVET master (on github) does not crash on this file, but it does send my system into swap so it does not complete.

Strangely, it only chokes on the H1 computation. If I use the same rivet input file, Mike's fork will have no problem computing H0 or H2. Here is the rivet_console output:

../../rivet.mike/rivet_console rivet.LookingGlass-AliceWonderland.txt rivet.LookingGlass-AliceWonderland.txt.H1.3x50.rivet -H 1 -x 3 -y 50 -V 10 X bins: 3 Y bins: 50 Verbosity: 10 READING FILE: rivet.LookingGlass-AliceWonderland.txt InputManager: Found a discrete metric space file. InputManager: Discrete metric space file has function values. Creating Vietoris-Rips complex. Maximum distance of edges in Rips complex: 2078209/1000000 Finished reading data. STAGE PROGRESS 30 Building Vietoris-Rips bifiltration. x-grades: 3 y-grades: 50 Created BifiltrationData( 1 , 10 ) INPUT ERROR: std::bad_alloc :END Exiting

It's about a 2.7Mb input text file. Let me try zipping it up and attaching. rivet.LookingGlass-AliceWonderland.txt.gz

edit: this appears to be a non-deterministic crash. I asked rivet_console to do the same computation approximately 14 times, and one of those times it completed the computation. Most times it fails with the ave bad_alloc error message. I am also getting this error message from a few other input files, and rivet_console sometimes completes these computations, as well.

mlesnick commented 6 years ago

So far, I am unable to replicate the crash. I ran this computation four times (Ubuntu 18.04, 64 GB RAM) with -V 6 and had no problems--it finished each time in ~30 minutes. This was with Bryn's recent merge, which replaces the Boost serialization with msgpack serialization, but based on where the crash occurs, I doubt that the change of serialization method has anything to do with what is causing the crash for Ryan.

I also ran this on my laptop (16GB RAM, OS X, with the earlier commit ae6b6f2) and did not see a crash, but my laptop ran out of memory and started using a lot of swap, so I stopped the computation.

FWIW, Ryan is running on a Linux laptop with 32GB RAM.

delooper commented 6 years ago

I recently switched to "master" of Mike's fork (after Bryn's commit), compiled and re-tried the above example that had the bad_alloc error.

I no longer appear to be getting the bad_alloc errors.

Currently have rivet_console running through a long list of input files that used to give me problems. Will update in a day or two if any troubles appear.

mlesnick commented 6 years ago

Ryan no longer sees this issue. I am going to assume that whatever it was, it was resolved by the recent changes to RIVET.