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