Is this a known bug in lexical_cast<double> ?
We're using boost 1.51. Management is reluctant to upgrade because the software is for manned space flight and our current boost version has been stable. Wanted to see if there was a known bug with boost::lexical_cast<double>. We're seeing failures on what appear to be valid float strings. When we catch the exception, and simply do a second cast on the same string, the cast succeeds. The Code fragment: try { dVal = boost::lexical_cast<double>(theValue); } catch(boost::bad_lexical_cast &eX) { ... more code ... firstAttemptFailed = true; } // If the first cast succeeded, don't bother to attempt it again. if(firstAttemptFailed == true) { // Let the API throw the actual exception if the second attempt also fails. dVal = boost::lexical_cast<double>(theValue); } The string sequence this fails on is: ... ... "7104", "0.416666699999999999983", "0.22222224", "4.08233160000000000001", "1.81436960000000000002", ... ... It fails on the last string, "1.81.....", in the actual program, but when compiled into a simple test program, it succeeds. If there is a known bug, we may be able to get a Boost upgrade installed. Thanks, Mike
On 7/13/15 1:26 PM, TILLMAN, MICHAEL D9 wrote:
We're using boost 1.51. Management is reluctant to upgrade because the software is for manned space flight and our current boost version has been stable.
Wanted to see if there was a known bug with boost::lexical_cast<double>. We're seeing failures on what appear to be valid float strings. When we catch the exception, and simply do a second cast on the same string, the cast succeeds. The Code fragment:
try { dVal = boost::lexical_cast<double>(theValue); }
catch(boost::bad_lexical_cast &eX)
{
... more code ...
firstAttemptFailed = true;
}
// If the first cast succeeded, don't bother to attempt it again.
if(firstAttemptFailed == true)
{
// Let the API throw the actual exception if the second attempt also fails.
dVal = boost::lexical_cast<double>(theValue);
}
The string sequence this fails on is:
...
...
"7104",
"0.416666699999999999983",
"0.22222224",
"4.08233160000000000001",
"1.81436960000000000002",
...
It fails on the last string, "1.81.....", in the actual program, but when compiled into a simple test program, it succeeds.
If there is a known bug, we may be able to get a Boost upgrade installed.
I don't know whether there are known bugs in lexical_cast, but I'd be more suspicious of theValue's actual value. What is it's type, lifetime, etc. Jeff
On 7/15/15 3:35 PM, Jeff Flinn wrote:
On 7/13/15 1:26 PM, TILLMAN, MICHAEL D9 wrote:
We're using boost 1.51. Management is reluctant to upgrade because the software is for manned space flight and our current boost version has been stable.
I have an absolutely HUGE problem with this quote. C/C++ is not an inherently safe language. It has lots of undefined behavior and differences between implementations. If you're making a critical project you CANNOT just take a library off the shelf and start using it. Actually I cannot even regulations internal and external even permit this this. Your "Management" is shirking it's responsibility to protect human life. Here's what you SHOULD be doing a) update your boost installation from time to time. b) Build your own libraries from the boost distribution c) Run the whole test suite with your compile/build settings. d) Review your application requirements. Verify that each requirement (which is usually explicit) is covered by at least one test program in the test suite for that library. If there isn't such test, write your own and add it to your local boost installation. If you want to be social, you might consider submitting to the library author through a git pull request. As far as I'm concerned, the policy you're not using - just not change anything because things are working amounts to using human cargo as human guinea pigs. BTW - other shops - not just those carrying human cargo should be doing this. It would make their life easier. Robert Ramey
You're preaching to the choir, man! But I just work here and unless I kidnap a manager's sibling or something, I have absolutely no control over their behavior. We're just trying to make this SW work within the highly constrained limitations of this working environment. But I do appreciate your comments, and agree wholeheartedly. Mike The Peon PS: Btw, you wouldn't happen to know of anyone I could contact that works directly with boost on bug fixes would you? Or would be familiar with the boost bug fix history? Having a bug in hand would help us in our efforts to "justify" an upgrade. Baring an answer from this group, when time permits, I'll be slogging through boost bug histories as time permits. -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Wednesday, July 15, 2015 6:17 PM To: boost-users@lists.boost.org Subject: EXTERNAL: Re: [Boost-users] Is this a known bug in lexical_cast<double> ? On 7/15/15 3:35 PM, Jeff Flinn wrote:
On 7/13/15 1:26 PM, TILLMAN, MICHAEL D9 wrote:
We're using boost 1.51. Management is reluctant to upgrade because the software is for manned space flight and our current boost version has been stable.
I have an absolutely HUGE problem with this quote. C/C++ is not an inherently safe language. It has lots of undefined behavior and differences between implementations. If you're making a critical project you CANNOT just take a library off the shelf and start using it. Actually I cannot even regulations internal and external even permit this this. Your "Management" is shirking it's responsibility to protect human life. Here's what you SHOULD be doing a) update your boost installation from time to time. b) Build your own libraries from the boost distribution c) Run the whole test suite with your compile/build settings. d) Review your application requirements. Verify that each requirement (which is usually explicit) is covered by at least one test program in the test suite for that library. If there isn't such test, write your own and add it to your local boost installation. If you want to be social, you might consider submitting to the library author through a git pull request. As far as I'm concerned, the policy you're not using - just not change anything because things are working amounts to using human cargo as human guinea pigs. BTW - other shops - not just those carrying human cargo should be doing this. It would make their life easier. Robert Ramey _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 7/15/2015 7:29 PM, TILLMAN, MICHAEL D9 wrote:
You're preaching to the choir, man!
But I just work here and unless I kidnap a manager's sibling or something, I have absolutely no control over their behavior.
We're just trying to make this SW work within the highly constrained limitations of this working environment.
But I do appreciate your comments, and agree wholeheartedly.
Mike The Peon
PS: Btw, you wouldn't happen to know of anyone I could contact that works directly with boost on bug fixes would you? Or would be familiar with the boost bug fix history? Having a bug in hand would help us in our efforts to "justify" an upgrade. Baring an answer from this group, when time permits, I'll be slogging through boost bug histories as time permits.
The current lexical_cast maintainer is Antony Polukhin, but he is not the original author. Since Boost 1.51 was released Aug. 20, 2012 and he has been the maintainer of lexical_cast since 2011 he might be able to help you. His e-mail is antoshkka -at- gmail.com according to the Boost maintainers list.
-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Wednesday, July 15, 2015 6:17 PM To: boost-users@lists.boost.org Subject: EXTERNAL: Re: [Boost-users] Is this a known bug in lexical_cast<double> ?
On 7/15/15 3:35 PM, Jeff Flinn wrote:
On 7/13/15 1:26 PM, TILLMAN, MICHAEL D9 wrote:
We're using boost 1.51. Management is reluctant to upgrade because the software is for manned space flight and our current boost version has been stable.
I have an absolutely HUGE problem with this quote. C/C++ is not an inherently safe language. It has lots of undefined behavior and differences between implementations. If you're making a critical project you CANNOT just take a library off the shelf and start using it. Actually I cannot even regulations internal and external even permit this this. Your "Management" is shirking it's responsibility to protect human life.
Here's what you SHOULD be doing
a) update your boost installation from time to time.
b) Build your own libraries from the boost distribution
c) Run the whole test suite with your compile/build settings.
d) Review your application requirements. Verify that each requirement (which is usually explicit) is covered by at least one test program in the test suite for that library. If there isn't such test, write your own and add it to your local boost installation. If you want to be social, you might consider submitting to the library author through a git pull request.
As far as I'm concerned, the policy you're not using - just not change anything because things are working amounts to using human cargo as human guinea pigs.
BTW - other shops - not just those carrying human cargo should be doing this. It would make their life easier.
The variable is just an argument to an API with a single argument: Bool CommandParser::processTelemetryDbl(string &theValue) And we're pretty sure the string is not the issue, simply because when we cast it twice, it succeeds the second time on the same string. In addition, I compiled with boost 1.58, and the same code succeeded without having to do the additional cast. This is what has lead us to believe that there is some variable in boost 1.51 that gets set to an invalid value at some point, and the exception resets it to a good value, enabling the second attempt on the same string to succeed. We're hoping someone will recognize the flaw and save us the trouble of having to slog through three years of bug logs to find a reference to the bug so management will consider allowing us to upgrade to a current boost version before the millennium comes to a close. Thanks for the query! You wouldn't happen to know of anyone I could contact that works directly with boost on bug fixes would you? Or would be familiar with the boost bug fix history? Thanks again for expressing an interest, Mike -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jeff Flinn Sent: Wednesday, July 15, 2015 5:36 PM To: boost-users@lists.boost.org Subject: EXTERNAL: Re: [Boost-users] Is this a known bug in lexical_cast<double> ? On 7/13/15 1:26 PM, TILLMAN, MICHAEL D9 wrote:
We're using boost 1.51. Management is reluctant to upgrade because the software is for manned space flight and our current boost version has been stable.
Wanted to see if there was a known bug with boost::lexical_cast<double>. We're seeing failures on what appear to be valid float strings. When we catch the exception, and simply do a second cast on the same string, the cast succeeds. The Code fragment:
try { dVal = boost::lexical_cast<double>(theValue); }
catch(boost::bad_lexical_cast &eX)
{
... more code ...
firstAttemptFailed = true;
}
// If the first cast succeeded, don't bother to attempt it again.
if(firstAttemptFailed == true)
{
// Let the API throw the actual exception if the second attempt also fails.
dVal = boost::lexical_cast<double>(theValue);
}
The string sequence this fails on is:
...
...
"7104",
"0.416666699999999999983",
"0.22222224",
"4.08233160000000000001",
"1.81436960000000000002",
...
It fails on the last string, "1.81.....", in the actual program, but when compiled into a simple test program, it succeeds.
If there is a known bug, we may be able to get a Boost upgrade installed.
I don't know whether there are known bugs in lexical_cast, but I'd be more suspicious of theValue's actual value. What is it's type, lifetime, etc. Jeff _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jeff Flinn Sent: Wednesday, July 15, 2015 5:36 PM To: boost-users@lists.boost.org Subject: EXTERNAL: Re: [Boost-users] Is this a known bug in lexical_cast<double> ?
On 7/13/15 1:26 PM, TILLMAN, MICHAEL D9 wrote:
...
"7104",
"0.416666699999999999983",
"0.22222224",
"4.08233160000000000001",
"1.81436960000000000002", ... It fails on the last string, "1.81.....", in the actual program, but when compiled into a simple test program, it succeeds.
You say yourself that a simple test program succeeds. The bug materializes only in your production code. This scenario begs for the steps for reproduce the bug. If you cannot reproduce it then you shouldn't suggest
Hi, On 16 July 2015 at 04:17, TILLMAN, MICHAEL D9 <michael.d9.tillman@lmco.com> wrote: that it's a bug in boost. If the same code succeeds in a simple test program then it cannot be a bug in boost IMHO. Best regards, -Asif
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Best regards, -Asif
Hi,
You say yourself that a simple test program succeeds. The bug materializes only in your production code. This scenario begs for the steps for reproduce the bug. If you cannot reproduce it then you shouldn't suggest that it's a bug in boost. If the same code succeeds in a simple test program then it cannot be a bug in boost IMHO.
Unfortunately, we had this exact case 2 days ago with a spirit::qi bug, induced by an uninitalised variable and a weird edge case. But i would agree that confirmation of this can only be given by a proper valgrind run( or a similar tool) to record any weird memory issues. If the testprogram succeeds without valgrind finding anything, do the same with your full program. compile in debug and run valgrind. Best, Oswin
We ran our application against both valgrind and insure, and saw no issues. As for the previous post, I may have not been clear as to exactly what I was asking. Emails are a horribly frustrating media for exchanging ideas any more complicated than "Have a nice day." Lol.... We are not trying to write or justify writing a bug on boost, and would certainly not think of doing so on boost version 1.51 for an issue that has been apparently fixed in 1.58, whether intentionally, or by happenstance in the process of fixing some other issue in the three years or so between the two releases. The sole intent of my query was to see if anyone knew of a boost bug fix for the particular issue. And the reason I asked for an incident report number is that my section manager wants the report number to use when we go to upper management to request a boost upgrade. All that being said, I did get a reply from Edward Diener giving me the name of the lexical cast maintainer, Antony Polukhin, and I'll be sending him a query concerning the issue. So, unless I fail to hear back from Antony, or if any of you know, offhand, the incident report number for this bug, if it exists, I don't think anybody else needs to spend any more time on this for me. I DO however, Greatly appreciate the consideration all of you have given to my question. Mike -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Oswin Krause Sent: Thursday, July 16, 2015 7:34 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] EXTERNAL: Re: Is this a known bug in lexical_cast<double> ? Hi,
You say yourself that a simple test program succeeds. The bug materializes only in your production code. This scenario begs for the steps for reproduce the bug. If you cannot reproduce it then you shouldn't suggest that it's a bug in boost. If the same code succeeds in a simple test program then it cannot be a bug in boost IMHO.
Unfortunately, we had this exact case 2 days ago with a spirit::qi bug, induced by an uninitalised variable and a weird edge case. But i would agree that confirmation of this can only be given by a proper valgrind run( or a similar tool) to record any weird memory issues. If the testprogram succeeds without valgrind finding anything, do the same with your full program. compile in debug and run valgrind. Best, Oswin _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
You could try diffing the code from the various versions. It sounds like a classic race condition though, the inputs obviously aren't the same. Maybe the act of throwing the exception causes some writes to happen that should have already been there, and so the second time round it succeeds. On Thu, Jul 16, 2015 at 9:52 PM, TILLMAN, MICHAEL D9 < michael.d9.tillman@lmco.com> wrote:
We ran our application against both valgrind and insure, and saw no issues.
As for the previous post, I may have not been clear as to exactly what I was asking. Emails are a horribly frustrating media for exchanging ideas any more complicated than "Have a nice day." Lol....
We are not trying to write or justify writing a bug on boost, and would certainly not think of doing so on boost version 1.51 for an issue that has been apparently fixed in 1.58, whether intentionally, or by happenstance in the process of fixing some other issue in the three years or so between the two releases.
The sole intent of my query was to see if anyone knew of a boost bug fix for the particular issue.
And the reason I asked for an incident report number is that my section manager wants the report number to use when we go to upper management to request a boost upgrade.
All that being said, I did get a reply from Edward Diener giving me the name of the lexical cast maintainer, Antony Polukhin, and I'll be sending him a query concerning the issue.
So, unless I fail to hear back from Antony, or if any of you know, offhand, the incident report number for this bug, if it exists, I don't think anybody else needs to spend any more time on this for me.
I DO however, Greatly appreciate the consideration all of you have given to my question.
Mike
-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Oswin Krause Sent: Thursday, July 16, 2015 7:34 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] EXTERNAL: Re: Is this a known bug in lexical_cast<double> ?
Hi,
You say yourself that a simple test program succeeds. The bug materializes only in your production code. This scenario begs for the steps for reproduce the bug. If you cannot reproduce it then you shouldn't suggest that it's a bug in boost. If the same code succeeds in a simple test program then it cannot be a bug in boost IMHO.
Unfortunately, we had this exact case 2 days ago with a spirit::qi bug, induced by an uninitalised variable and a weird edge case. But i would agree that confirmation of this can only be given by a proper valgrind run( or a similar tool) to record any weird memory issues.
If the testprogram succeeds without valgrind finding anything, do the same with your full program. compile in debug and run valgrind.
Best, Oswin _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
That’s more or less what we suspect happens. And we did try a diff. The lexical cast hpp file in 1.51 was over two thousand lines. The same file in 1.58 was a hundred. Lol…. So apparently a major refactoring effort took place, and I didn’t have the time, and truth be told, didn’t want to spend the time, to track down the new files and attempt a comparison. Not really sure if, in two thousand plus lines of boost code, I would have been able to identify a bug before it was time for me to retire anyway. I would have enjoyed trying, but chances are I would have just wasted a huge chunk of taxpayer money slogging through boost code. But thanks for the suggestion. From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of james Sent: Thursday, July 16, 2015 4:53 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] EXTERNAL: Re: Is this a known bug in lexical_cast<double> ? You could try diffing the code from the various versions. It sounds like a classic race condition though, the inputs obviously aren't the same. Maybe the act of throwing the exception causes some writes to happen that should have already been there, and so the second time round it succeeds. On Thu, Jul 16, 2015 at 9:52 PM, TILLMAN, MICHAEL D9 <michael.d9.tillman@lmco.com<mailto:michael.d9.tillman@lmco.com>> wrote: We ran our application against both valgrind and insure, and saw no issues. As for the previous post, I may have not been clear as to exactly what I was asking. Emails are a horribly frustrating media for exchanging ideas any more complicated than "Have a nice day." Lol.... We are not trying to write or justify writing a bug on boost, and would certainly not think of doing so on boost version 1.51 for an issue that has been apparently fixed in 1.58, whether intentionally, or by happenstance in the process of fixing some other issue in the three years or so between the two releases. The sole intent of my query was to see if anyone knew of a boost bug fix for the particular issue. And the reason I asked for an incident report number is that my section manager wants the report number to use when we go to upper management to request a boost upgrade. All that being said, I did get a reply from Edward Diener giving me the name of the lexical cast maintainer, Antony Polukhin, and I'll be sending him a query concerning the issue. So, unless I fail to hear back from Antony, or if any of you know, offhand, the incident report number for this bug, if it exists, I don't think anybody else needs to spend any more time on this for me. I DO however, Greatly appreciate the consideration all of you have given to my question. Mike -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org<mailto:boost-users-bounces@lists.boost.org>] On Behalf Of Oswin Krause Sent: Thursday, July 16, 2015 7:34 AM To: boost-users@lists.boost.org<mailto:boost-users@lists.boost.org> Subject: Re: [Boost-users] EXTERNAL: Re: Is this a known bug in lexical_cast<double> ? Hi,
You say yourself that a simple test program succeeds. The bug materializes only in your production code. This scenario begs for the steps for reproduce the bug. If you cannot reproduce it then you shouldn't suggest that it's a bug in boost. If the same code succeeds in a simple test program then it cannot be a bug in boost IMHO.
Unfortunately, we had this exact case 2 days ago with a spirit::qi bug, induced by an uninitalised variable and a weird edge case. But i would agree that confirmation of this can only be given by a proper valgrind run( or a similar tool) to record any weird memory issues. If the testprogram succeeds without valgrind finding anything, do the same with your full program. compile in debug and run valgrind. Best, Oswin _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org<mailto:Boost-users@lists.boost.org> http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org<mailto:Boost-users@lists.boost.org> http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 16.07.2015 14:27, Asif Lodhi wrote:
Hi,
On 16 July 2015 at 04:17, TILLMAN, MICHAEL D9 <michael.d9.tillman@lmco.com <mailto:michael.d9.tillman@lmco.com>> wrote:
-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org <mailto:boost-users-bounces@lists.boost.org>] On Behalf Of Jeff Flinn Sent: Wednesday, July 15, 2015 5:36 PM To: boost-users@lists.boost.org <mailto:boost-users@lists.boost.org> Subject: EXTERNAL: Re: [Boost-users] Is this a known bug in lexical_cast<double> ?
On 7/13/15 1:26 PM, TILLMAN, MICHAEL D9 wrote:
> ... > > "7104", > > "0.416666699999999999983", > > "0.22222224", > > "4.08233160000000000001", > > "1.81436960000000000002", > ... > It fails on the last string, "1.81.....", in the actual program, but > when compiled into a simple test program, it succeeds.
You say yourself that a simple test program succeeds. The bug materializes only in your production code. This scenario begs for the steps for reproduce the bug. If you cannot reproduce it then you shouldn't suggest that it's a bug in boost. If the same code succeeds in a simple test program then it cannot be a bug in boost IMHO.
Well, it still could be, but cannot be proven. I agree with the rest however, without a proof, or at least strong indication, such suggestion is useless and shouldn't be made. And reading the original post, it really wasn't made .... OP was asking the question if anything similar was known to happen, rather than suggesting that the bug is actually in boost. Best regards, Leon
On 07/13/2015 07:26 PM, TILLMAN, MICHAEL D9 wrote:
Wanted to see if there was a known bug with boost::lexical_cast<double>. We're seeing failures on what appear to be valid float strings. When we catch the exception, and simply do a second cast on the same string, the cast succeeds. The Code fragment:
That sounds very odd. lexical_cast uses string streams (either from <sstream> or <strstream> depending on what it detects) so you could try to reproduce the problem by using those directly. You may also try to compile with the BOOST_LEXICAL_CAST_ASSUME_C_LOCALE macro set.
It fails on the last string, "1.81.....", in the actual program, but when compiled into a simple test program, it succeeds.
This often indicates that the exception is just a symptom of another problem.
participants (1)
-
Asif Lodhi -
Bjorn Reese -
Edward Diener -
james -
Jeff Flinn -
Leon Mlakar -
Oswin Krause -
Robert Ramey -
TILLMAN, MICHAEL D9