[phoenix] segmentation fault with valarray
Hi all! I have worked with phoenix together with valarray and am currently stumbling over a case of segmentation fault. I construct the following phoenix expression boost::phoenix::at_c<0>(arg1) += boost::phoenix::at_c<1>(arg1) / val(mass) * arg2 I then feed a std::tuple<std::valarray<double>, std::valarray<double>> to it. It compiles nicely with gcc (4.6 & 4.7) using boost 1.52 as well as trunk. The resulting executable then proceeds to segfault, however. I have put together a small example (c++11) demonstrating my problem. The valarray's memory should already be reserved from original initialization. Performing the same operations manually with just the valarray not in phoenix seems to work fine. Am I missing something or doing something stupid here? thanks for any help! cheers Philipp
On Tue, Jan 29, 2013 at 5:35 AM, Philipp Schwaha <philipp@schwaha.net>wrote:
Hi all!
I have worked with phoenix together with valarray and am currently stumbling over a case of segmentation fault.
I construct the following phoenix expression
boost::phoenix::at_c<0>(arg1) += boost::phoenix::at_c<1>(arg1) / val(mass) * arg2
I then feed a std::tuple<std::valarray<double>, std::valarray<double>> to it. It compiles nicely with gcc (4.6 & 4.7) using boost 1.52 as well as trunk. The resulting executable then proceeds to segfault, however. I have put together a small example (c++11) demonstrating my problem.
The valarray's memory should already be reserved from original initialization. Performing the same operations manually with just the valarray not in phoenix seems to work fine. Am I missing something or doing something stupid here?
thanks for any help!
cheers Philipp
I don't know the internals of Phoenix intimately, but it *might* hold subexpressions by reference rather than by value, implying that you'd have dangling references when grabbing "mass" upon applying your Phoenix function object. Just a guess if you wanted something to look into until someone more knowledgeable replies. - Jeff
On 01/29/2013 09:31 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Jan 29, 2013 at 5:35 AM, Philipp Schwaha wrote:
Hi all!
I have worked with phoenix together with valarray and am currently stumbling over a case of segmentation fault.
I construct the following phoenix expression
boost::phoenix::at_c<0>(arg1) += boost::phoenix::at_c<1>(arg1) / val(mass) * arg2
I then feed a std::tuple<std::valarray<double>, std::valarray<double>> to it. It compiles nicely with gcc (4.6 & 4.7) using boost 1.52 as well as trunk. The resulting executable then proceeds to segfault, however. I have put together a small example (c++11) demonstrating my problem.
The valarray's memory should already be reserved from original initialization. Performing the same operations manually with just the valarray not in phoenix seems to work fine. Am I missing something or doing something stupid here?
thanks for any help!
cheers Philipp
I don't know the internals of Phoenix intimately, but it *might* hold subexpressions by reference rather than by value, implying that you'd have dangling references when grabbing "mass" upon applying your Phoenix function object. Just a guess if you wanted something to look into until someone more knowledgeable replies.
I don't believe that's the case, Jeff, but I'm not the Phoenix implementor. Philipp, I'd suggest you file a bug. Eric
On 01/29/2013 10:36 PM, Eric Niebler wrote:
On 01/29/2013 09:31 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Jan 29, 2013 at 5:35 AM, Philipp Schwaha wrote:
Hi all!
I have worked with phoenix together with valarray and am currently stumbling over a case of segmentation fault.
I construct the following phoenix expression
boost::phoenix::at_c<0>(arg1) += boost::phoenix::at_c<1>(arg1) / val(mass) * arg2
I then feed a std::tuple<std::valarray<double>, std::valarray<double>> to it. It compiles nicely with gcc (4.6 & 4.7) using boost 1.52 as well as trunk. The resulting executable then proceeds to segfault, however. I have put together a small example (c++11) demonstrating my problem.
The valarray's memory should already be reserved from original initialization. Performing the same operations manually with just the valarray not in phoenix seems to work fine. Am I missing something or doing something stupid here?
thanks for any help!
cheers Philipp
I don't know the internals of Phoenix intimately, but it *might* hold subexpressions by reference rather than by value, implying that you'd have dangling references when grabbing "mass" upon applying your Phoenix function object. Just a guess if you wanted something to look into until someone more knowledgeable replies.
I don't believe that's the case, Jeff, but I'm not the Phoenix implementor. Philipp, I'd suggest you file a bug. Done. https://svn.boost.org/trac/boost/ticket/7953
cheers Philipp
Eric
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Tue, Jan 29, 2013 at 5:35 AM, Philipp Schwaha <philipp@schwaha.net <mailto:philipp@schwaha.net>> wrote:
Hi all!
I have worked with phoenix together with valarray and am currently stumbling over a case of segmentation fault.
I construct the following phoenix expression
boost::phoenix::at_c<0>(arg1) += boost::phoenix::at_c<1>(arg1) / val(mass) * arg2
I then feed a std::tuple<std::valarray<double>, std::valarray<double>> to it. It compiles nicely with gcc (4.6 & 4.7) using boost 1.52 as well as trunk. The resulting executable then proceeds to segfault, however. I have put together a small example (c++11) demonstrating my problem.
The valarray's memory should already be reserved from original initialization. Performing the same operations manually with just the valarray not in phoenix seems to work fine. Am I missing something or doing something stupid here?
thanks for any help!
cheers Philipp
I don't know the internals of Phoenix intimately, but it *might* hold subexpressions by reference rather than by value, implying that you'd have dangling references when grabbing "mass" upon applying your Phoenix function object. Just a guess if you wanted something to look into until someone more knowledgeable replies. I have also tried inserting a number instead of the val(mass), it still results in a segfault.
hi Jeff! On 01/29/2013 06:31 PM, Jeffrey Lee Hellrung, Jr. wrote: thanks for taking the time to have a look! cheers Philipp
- Jeff
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
Eric Niebler
-
Jeffrey Lee Hellrung, Jr.
-
Philipp Schwaha