Old libstdc++ problem with 'alert.cpp' [Was: [lmi] wx segfault iterating on GetChildren()]

[Greg Chicares]

On 2006-3-16 23:13 UTC, Greg Chicares wrote:
> On 2006-3-16 22:44 UTC, Evgeniy Tarassov wrote:
> 
>>2. fatal_error() function does not seem to work as intended. Any time
>>it is being called it produces exception 'basic_ios::clear(iostate)
>>caused exception' which is shown through wxSafeShowMessage and initial
>>diagnostic message is lost.
> 
> I remember seeing that problem. My recollection is vague, but
> I think it might have been caused by a defect in libstdc++.
> Let me look into it and get back to you.

This change:

  http://cvs.savannah.gnu.org/viewcvs/lmi/lmi/alert.cpp?r2=1.2&r1=1.1

removed this comment:

  // TODO ?? Track down this problem:
  //   Caught exception: basic_ios::clear(iostate) caused exception
  // from test_exception().

and 'ChangeLog' for 2005-01-28 explains:

    alert.cpp
  Remove a defect marker that called for investigation into a problem
  whose cause has been tracked to a libstdc++ defect.

Unit test file 'alert_test.cpp' says:

    // Run this 'fatal_error' test twice in order to ensure that the
    // stream state is cleared after an exception is thrown; if it is
    // not, then getting a reference to the stream again, e.g., by
    // calling fatal_error(), fails with an exception inside the
    // standard library, probably in std::ios_base::clear().
...
#if defined __GLIBCPP__ && __GLIBCPP__==20030426
    std::cout
        << "This test fails with libstdc++-v3 if ostream.tcc is\n"
        << "older than version 1.30.2.14 of 2003-12-01T19:39:49 .\n"
        ;
#endif // Defective version of libstdc++-v3.

and the libstdc++ change log for that date:

  http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/ChangeLog-2003

says:

2003-12-01  Benjamin Kosnik  <address@hidden>

        * include/bits/basic_ios.h (basic_ios::setstate): Revert.
        * include/bits/istream.tcc: Only call setstate if __err != goodbit.
        * include/bits/ostream.tcc: Same.

and the patch is here:

  
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/ostream.tcc?r1=73992&r2=74151

Now, what does this all mean, and what should we do about it?

I'm reluctant to backpatch a three-year-old compiler.

Even trying to upgrade libstdc++ independently for MinGW gcc-3.2.3
doesn't seem attractive: I really doubt that it would be trivial.

I don't think we actually need to do anything. I'd like to use
mpatrol to find out whether we stomp on memory in normal operation.
Fatal errors (and assertion failures that call fatal_error) should
be difficult or impossible to produce if the system is installed
correctly; if they still occur, they almost certainly indicate
logic errors that we need to fix, in order to make them impossible.

And using 3.2.3 is just an intermediate step, not the final goal.
The first step is to rule out wx, liberating me from the need to
keep wx-2.5.1 installed. I'm hoping this will show us that the
mpatrol problems with later versions of gcc indicate problems with
gcc, which I can then explain to the maintainers and persuade them
to fix. Giving them a really good testcase works wonders. Then,
ultimately, we can hope to update both gcc and wx and still have
mpatrol work--so spending a lot of time on this old libstdc++
problem would be wasted work, and we should just ignore it.