On Mon, Sep 02, 2019 at 09:21:32AM -0700, Joe Dinius wrote: > Sure, no problem. Attached is a compressed minimal example that only has > armadillo (9.599) and ensmallen (1.15.1) as dependencies; openmp is > optional.
Hey Joe, Thanks for the code---I was able to unpack and build it really easily. I found the issue and it is actually caused by a somehow-invalid use of 'auto'. Here was my debugging route: First I compiled the program and ran to verify that it gave the same output as you saw. Indeed it did... so I then used gdb to see how large of a matrix it tried to allocate. I discovered that size_Y at line 115 of ensmallen-sdp.cpp had a value of 93824992850192. That seemed... invalid. Then, I also found that constr_map.A_[0] had reasonable size (less than 300 rows and columns). I noticed that 'size_Y' was being set like this: auto const & size_Y = constr_map.getConstraintMapA()[0].n_rows; In the past, I've learned to avoid using 'auto' because sometimes it can infer the wrong types. Generally I will see this happen with longer Armadillo expressions. For instance, the following code scares me: using namespace arma; mat x, y; auto z = x.t() * y + (x.t() * x - 3); The reason that scares me is because we are hoping that the compiler will infer 'mat' as the type of z, but we don't have a guarantee. In fact, more often than not, it will infer some internal Armadillo type that represents the expression (due to Armadillo's delayed evaluation framework), and this will result in code that doesn't behave as expected. I'm quite surprised, though, that 'auto' failed to infer the correct type of n_rows, which is arma::uword. When I changed it to the following (I prefer size_t to uword), the test ran without error: size_t const & size_Y = constr_map.getConstraintMapA()[0].n_rows; I'm unsure of why the compiler had an issue with this, since there's no delayed expression. Perhaps it has to do with dereferencing the std::vector getConstraintMapA()---I am not sure. In any case, I hope this is helpful! If you dig in further and figure out why the type is being inferred wrong, I'd be interested to find out. But for now I will just continue to avoid 'auto' unless there is no possibility the compiler can get it wrong. :) (And even then I might avoid it too, just for paranoia's sake!) -- Ryan Curtin | "Because for the people who knew what it was, it [email protected] | would be attacking their brain." _______________________________________________ mlpack mailing list [email protected] http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
