gcc 4.4.3 + boost optional 1.40 crash
Hi all, after banging my head for an entire day I come out with this test case showing a possible bug in gcc 4.4.3 or in boost optional, the test crashes with a pure virtual method called only if compiled only with -O1, -O2, -O3. The same code in another machine with gcc 4.7.2 and boost 1.49 works fine. Regards Gaetano Mendola #include <boost/optional.hpp> #include <boost/noncopyable.hpp> class B : boost::noncopyable { //if the noncopyable is removed works public: virtual size_t bar() const = 0; }; class D : public B { public: D() :theBar(foo(10)) { } virtual size_t bar() const { return theBar; } private: static size_t foo(const boost::optional<size_t> a) { if (a) { //if this is a.is_initialized() then it works return a.get(); } return 2; } const size_t theBar; }; class Foo { public: Foo(const B& b) :theBar(b.bar() * b.bar()) { } private: const size_t theBar; }; int main() { { //if this section is removed works D d; try { Foo myCompound(d); } catch(...) {} } { D d; try { Foo myCompound(d); } catch(...) {} } }
On Fri, Nov 23, 2012 at 12:28 PM, Gaetano Mendola <mendola@gmail.com> wrote:
Hi all, after banging my head for an entire day I come out with this test case showing a possible bug in gcc 4.4.3 or in boost optional, the test crashes with a pure virtual method called only if compiled only with -O1, -O2, -O3. The same code in another machine with gcc 4.7.2 and boost 1.49 works fine.
The only virtual function I see is B::bar so I assume that's where it breaks. That's only possible if the compiler messed up the second D's construction somehow. IMO, this is a compiler issue since optional is not used with D. Did you try to accept the D::foo argument by const reference instead of by value?
On 11/23/2012 09:46 AM, Andrey Semashev wrote:
On Fri, Nov 23, 2012 at 12:28 PM, Gaetano Mendola <mendola@gmail.com> wrote:
Hi all, after banging my head for an entire day I come out with this test case showing a possible bug in gcc 4.4.3 or in boost optional, the test crashes with a pure virtual method called only if compiled only with -O1, -O2, -O3. The same code in another machine with gcc 4.7.2 and boost 1.49 works fine.
The only virtual function I see is B::bar so I assume that's where it breaks. That's only possible if the compiler messed up the second D's construction somehow. IMO, this is a compiler issue since optional is not used with D. Did you try to accept the D::foo argument by const reference instead of by value?
Same problem, what is puzzling me is that you can make it working doing the following: - Remove the noncopyable from B or - Remove one of the two segments in the extra scope in main or - Remove the try { } catch Regards Gaetano Mendola
On 23.11.2012 12:28, Gaetano Mendola wrote:
after banging my head for an entire day I come out with this test case showing a possible bug in gcc 4.4.3 or in boost optional, the test crashes with a pure virtual method called only if compiled only with -O1, -O2, -O3. The same code in another machine with gcc 4.7.2 and boost 1.49 works fine. So, the bug you are talking about seems to be already fixed. What else do you want from the boost and gcc developers?
-- Sergey Cheban
On Fri, Nov 23, 2012 at 03:25:42PM +0400, Sergey Cheban wrote:
On 23.11.2012 12:28, Gaetano Mendola wrote:
after banging my head for an entire day I come out with this test case showing a possible bug in gcc 4.4.3 or in boost optional, the test crashes with a pure virtual method called only if compiled only with -O1, -O2, -O3. The same code in another machine with gcc 4.7.2 and boost 1.49 works fine. So, the bug you are talking about seems to be already fixed. What else do you want from the boost and gcc developers?
A wild guess would be that he has his set of distributions which ship with a particular Boost and GCC version. A solution could be a standalone hackfix that could be propagated upstream to his distribution, or some evidence that can be used to motivate installing a slightly higher Boost if it shows that it indeed solves the problem. I'd reckon that the question appears out of a belief that it's possible to make point releases for older versions. A common policy in some projects is that bugfixes for older supported versions can be made as point releases, but new features requires a new full release. Boost, sadly, does no such thing. At best you get a point-release inbetween the real releases, but once Boost revs the minor version, all the old releases are forever set in stone. -- Lars Viklund | zao@acc.umu.se
----- Mail original -----
De: "Sergey Cheban" <s.cheban@drweb.com> À: boost@lists.boost.org Envoyé: Vendredi 23 Novembre 2012 12:25:42 Objet: Re: [boost] gcc 4.4.3 + boost optional 1.40 crash
On 23.11.2012 12:28, Gaetano Mendola wrote:
after banging my head for an entire day I come out with this test case showing a possible bug in gcc 4.4.3 or in boost optional, the test crashes with a pure virtual method called only if compiled only with -O1, -O2, -O3. The same code in another machine with gcc 4.7.2 and boost 1.49 works fine. So, the bug you are talking about seems to be already fixed. What else do you want from the boost and gcc developers?
AFAIU, he has not done a test with gcc 4.4.3 and a recent boost, which is the very first thing I would have done in that case, BTW. Regards, Ivan
On 11/23/2012 01:10 PM, Ivan Le Lann wrote:
----- Mail original -----
De: "Sergey Cheban" <s.cheban@drweb.com> À: boost@lists.boost.org Envoyé: Vendredi 23 Novembre 2012 12:25:42 Objet: Re: [boost] gcc 4.4.3 + boost optional 1.40 crash
On 23.11.2012 12:28, Gaetano Mendola wrote:
after banging my head for an entire day I come out with this test case showing a possible bug in gcc 4.4.3 or in boost optional, the test crashes with a pure virtual method called only if compiled only with -O1, -O2, -O3. The same code in another machine with gcc 4.7.2 and boost 1.49 works fine. So, the bug you are talking about seems to be already fixed. What else do you want from the boost and gcc developers?
AFAIU, he has not done a test with gcc 4.4.3 and a recent boost, which is the very first thing I would have done in that case, BTW.
I have tried with 1.50 and 1.52 and it crash. We have now to understand if it's a boost related issue or a build error in gcc. Regards Gaetano Mendola
On 11/23/2012 12:25 PM, Sergey Cheban wrote:
On 23.11.2012 12:28, Gaetano Mendola wrote:
after banging my head for an entire day I come out with this test case showing a possible bug in gcc 4.4.3 or in boost optional, the test crashes with a pure virtual method called only if compiled only with -O1, -O2, -O3. The same code in another machine with gcc 4.7.2 and boost 1.49 works fine. So, the bug you are talking about seems to be already fixed. What else do you want from the boost and gcc developers?
Sorry? Are you suggesting to ditch gcc and/or boost released with the distribution we use, and say to our development department gcc and/or boost fixed it "by accident" on their last releases? I would like you to consider the following, not impossible, scenario: In boost 1.40 boost::optionals is doing something that c++ doesn't allow marked as: "if you do it the result is: 'everyone guess'". That is translated in "pure virtual function call" in gcc 4.4.3 and "no operation" in gcc 4.7.2. I would not sleep well if my own code is crashing (for no apparent reason) on a not 10 year old gcc compiler. Now, let's make this thread a constructive thread instead to "smarty pants" here and there. As suggested by another user I tried with gcc 4.4.3 + boost 1.50 and it crash I have tried with boost 1.52 and it crash as well. At this point or is a boost bug (not yet resolved) or a gcc bug corrected by accident or not in the new release. GCC people do release fixes on old version then it's important to submit the bug as soon we know who is faulty here. Regards Gaetano Mendola
On Fri, Nov 23, 2012 at 3:29 PM, Gaetano Mendola <mendola@gmail.com> wrote:
As suggested by another user I tried with gcc 4.4.3 + boost 1.50 and it crash I have tried with boost 1.52 and it crash as well. At this point or is a boost bug (not yet resolved) or a gcc bug corrected by accident or not in the new release. GCC people do release fixes on old version then it's important to submit the bug as soon we know who is faulty here.
http://gcc.gnu.org/ says "GCC 4.6.3 (changes) (oldest maintained release)" This kinda implies 4.4 is no longer being maintained. -- Olaf
On 11/23/2012 04:46 PM, Olaf van der Spek wrote:
On Fri, Nov 23, 2012 at 3:29 PM, Gaetano Mendola <mendola@gmail.com> wrote:
As suggested by another user I tried with gcc 4.4.3 + boost 1.50 and it crash I have tried with boost 1.52 and it crash as well. At this point or is a boost bug (not yet resolved) or a gcc bug corrected by accident or not in the new release. GCC people do release fixes on old version then it's important to submit the bug as soon we know who is faulty here.
http://gcc.gnu.org/ says "GCC 4.6.3 (changes) (oldest maintained release)" This kinda implies 4.4 is no longer being maintained.
Still the accept reports related to gcc 4.4.3, I guess they will try the reports they get against their oldest. Regards Gaetano Mendola
On 11/23/2012 03:29 PM, Gaetano Mendola wrote:
On 11/23/2012 12:25 PM, Sergey Cheban wrote:
On 23.11.2012 12:28, Gaetano Mendola wrote:
after banging my head for an entire day I come out with this test case showing a possible bug in gcc 4.4.3 or in boost optional, the test crashes with a pure virtual method called only if compiled only with -O1, -O2, -O3. The same code in another machine with gcc 4.7.2 and boost 1.49 works fine. So, the bug you are talking about seems to be already fixed. What else do you want from the boost and gcc developers?
Sorry?
Are you suggesting to ditch gcc and/or boost released with the distribution we use, and say to our development department gcc and/or boost fixed it "by accident" on their last releases?
I would like you to consider the following, not impossible, scenario:
In boost 1.40 boost::optionals is doing something that c++ doesn't allow marked as: "if you do it the result is: 'everyone guess'". That is translated in "pure virtual function call" in gcc 4.4.3 and "no operation" in gcc 4.7.2. I would not sleep well if my own code is crashing (for no apparent reason) on a not 10 year old gcc compiler.
Now, let's make this thread a constructive thread instead to "smarty pants" here and there.
As suggested by another user I tried with gcc 4.4.3 + boost 1.50 and it crash I have tried with boost 1.52 and it crash as well. At this point or is a boost bug (not yet resolved) or a gcc bug corrected by accident or not in the new release. GCC people do release fixes on old version then it's important to submit the bug as soon we know who is faulty here.
I have submitted the bug to gcc, for any reference http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 Regards Gaetano Mendola
On Fri, Nov 23, 2012 at 6:29 PM, Gaetano Mendola <mendola@gmail.com> wrote:
As suggested by another user I tried with gcc 4.4.3 + boost 1.50 and it crash I have tried with boost 1.52 and it crash as well. At this point or is a boost bug (not yet resolved) or a gcc bug corrected by accident or not in the new release. GCC people do release fixes on old version then it's important to submit the bug as soon we know who is faulty here.
In my reply I pointed out that there is no way optional can legitimately cause this crash because it's not used with your class. The problem seems to be due to coincidence of several unknown factors in the code, only one of them being a mere presence and use of optional. Although it's not my position to say so, I do not think the author of Boost.Optional is willing to work around compiler bugs that are not directly caused by it. My advice: use a newer compiler. If that's not an option, try to work it around in your code. You've already presented several workarounds you found.
23.11.2012 18:29, Gaetano Mendola пишет:
Are you suggesting to ditch gcc and/or boost released with the distribution we use, and say to our development department gcc and/or boost fixed it "by accident" on their last releases? If you want to get the bugfix, you have to upgrade.
I would like you to consider the following, not impossible, scenario: Ок, let's suppose that the bug is still here. Let's suppose that boost or gcc developers will find and fix it. But you are still locked in your 3-year-old environment and have no chance to get the fix.
-- Best regards, Sergey Cheban
On 11/24/2012 12:55 AM, Sergey Cheban wrote:
23.11.2012 18:29, Gaetano Mendola пишет:
Are you suggesting to ditch gcc and/or boost released with the distribution we use, and say to our development department gcc and/or boost fixed it "by accident" on their last releases? If you want to get the bugfix, you have to upgrade.
I would like you to consider the following, not impossible, scenario: Ок, let's suppose that the bug is still here. Let's suppose that boost or gcc developers will find and fix it. But you are still locked in your 3-year-old environment and have no chance to get the fix.
I'll be happy to have solved someone else problems to not talk about the fact that an issue solved in an old version of sofwtare can still exist in new version but triggered instead by something else than my own test case. Don't you agree? That's why I'm a bit disappointed about how the gcc bug was closed with the same: "works with new version" but after all 4.4.3 is not maintaned. With boost instead for version 1.52 I can read that GCC 4.4.3 is tested as primary compiler. Regards Gaetano Mendola
On Sat, Nov 24, 2012 at 7:42 AM, Gaetano Mendola <mendola@gmail.com> wrote:
I'll be happy to have solved someone else problems to not talk about the fact that an issue solved in an old version of sofwtare can still exist in new version but triggered instead by something else than my own test case. Don't you agree?
Not really Yes, theoretically it could still exist in the latest version. But chances are is doesn't. Don't you think GCC devs have more important issues to work at? If you think it might still exist in the latest version, it's up to you to reproduce it. -- Olaf
On 11/24/2012 02:10 PM, Olaf van der Spek wrote:
On Sat, Nov 24, 2012 at 7:42 AM, Gaetano Mendola <mendola@gmail.com> wrote:
I'll be happy to have solved someone else problems to not talk about the fact that an issue solved in an old version of sofwtare can still exist in new version but triggered instead by something else than my own test case. Don't you agree?
Not really Yes, theoretically it could still exist in the latest version. But chances are is doesn't.
And this statement is based one what? I have searched on bugzilla for my something similar to my issue and I haven't find anything related to it. Look at this report I did 2 year ago, still related to 4.4.3: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45385 and as you can see the bug was corrected in 4.7. This just prove that your statement is not valid, I guess because most of the gcc users do not fill a bug when they found it, and to be honest I don't know if this is good (imagine how many daily reports) or bad.
Don't you think GCC devs have more important issues to work at?
If you think it might still exist in the latest version, it's up to you to reproduce it.
Be sure if I found one I will submit it. Gaetano
participants (6)
-
Andrey Semashev -
Gaetano Mendola -
Ivan Le Lann -
Lars Viklund -
Olaf van der Spek -
Sergey Cheban