19:29 < cult-> hi. i don't get it. i can't run multiple classes together. i can only run one class that's using mlpack, otherwise its segfault or

19:29 < cult-> error: Mat::init(): requested size is too large

19:29 < cult-> terminate called after throwing an instance of 'std::logic_error'

20:12 < rcurtin> it sounds like you probably have some uninitialized variable that is causing Armadillo to try to allocate a matrix that's too large

20:12 < rcurtin> you might consider using valgrind to try and find invalid accesses or anything like this

20:49 < cult-> thanks, i will look for uninitialized variable. anyway what i am doing is running two mlpack algorithms in different threads and in different classes. if i run only one of them, everything is fine! is your suggestion still stands in that case?

20:49 < rcurtin> now my guess is that there is a race condition :)

20:50 < rcurtin> I don't know if valgrind will show that to you

20:50 < rcurtin> I hate debugging parallel programs :(

20:51 < rcurtin> I believe that mlpack should be threadsafe, unless you are using the CLI object

20:51 < rcurtin> but if you're writing C++ then it seems unlikely that you would be using the CLI object

20:52 < cult-> i did put mutexes in the constructors

20:52 < cult-> didnt help

20:52 < rcurtin> can you show me what you are doing?

20:52 < rcurtin> I can take a quick glance and see if I can see what the error is

20:52 < rcurtin> (no guarantees that I will be helpful...)

20:52 < cult-> if you will be around a little bit later i will try to make a reproducable example

20:53 < cult-> but my main problem is, the two classes are not sharing any variables

20:54 < cult-> so the race condition would be in armadillo internals

20:54 < rcurtin> yes, maybe there is some underlying armadillo bug, but that seems strange

20:54 < rcurtin> a reproducible example would definitely be helpful in figuring out what is going on

20:56 < cult-> i am however using armadillo matrixes as memory pointers

20:57 < cult-> but they are unique in each class, so not shared.

20:57 < rcurtin> yes, the situation certainly seems strange

20:57 < rcurtin> I'm leaning towards invalid memory access or race condition or both, but based on what you described it sounds like it might be hard to find!

20:59 < cult-> :(

21:00 < cult-> if thats the case, assume armadillo internal race condition, what would be an ideal work-around?

21:12 < rcurtin> I have no idea, I'd need to see what the actual issue is first

21:12 < rcurtin> I think Armadillo is thread-safe, so I am doubtful that the issue lies within Armadillo, but it's definitely a possibility to be investigated

23:13 < cult-> in addition to the former error message i also can produce: "error: arma::memory::acquire(): out of memory"

23:14 < cult-> (dataset isn't large)

23:19 < cult-> i was also able to schedule the two threads so they do their job at different times, didn't help

23:21 < cult-> i know i should provide an example but it will be rather sophisticated to get there, so i try everything beforehand.

23:36 < cult-> debugging the code it is absolutely some kind of weird behaviour of armadillo

23:42 < zoq> Difficult for us to help you without any code to reproduce the error, maybe/hopefully you can find a solution