Re: incompatible GCC 4.4.5 and 4.5.1 libstdc++ ?

[Ian Lance Taylor <iant at google dot com>]

Christophe Lyon <christophe.lyon@st.com> writes:

> On 17.11.2010 17:00, Ian Lance Taylor wrote:
>> Christophe Lyon <christophe.lyon@st.com> writes:
>> 
>>> I have just faced a problem where a C++ program (which I get in binary
>>> form - I can't recompile) crashes when it uses libstdc++.so.6 from
>>> GCC-4.5.1, while it works when using libstdc++.so.6 from GCC-4.4.5.
>>>
>>> I am using an x86 machine.
>>>
>>> Are there any known incompatibilities between these two libraries?
>>> As the major revision hasn't changed I didn't expect any behaviour change.
>> 
>> 
>> There are no intentional incompatibilities between these libraries.  If
>> you build a program with gcc 4.4.5, it should run correctly when using
>> the libstdc++ from gcc 4.5.1.  Of course there may be a bug.  It's hard
>> to say anything else without more information.
>> 
>
> Thanks for your answer, at least I have the confirmation that, as I
> thought, it should work.
>
> I have tried using strace to figure out what is going on, but it was of
> little help. Both traces are identical until one decides to segfault.
>
> As I don't have access to the source code of the failing program, does
> anyone have a suggestion on how to narrow down the problem?


Well, there are things you can do, but they are fairly desperate.

Without more information my experience is that there's at least a 50%
chance that it's a bug in the program you are running which is being
exposed by a change in the library.  However, there is definitely the
other 50% chance that there is a bug in the library.

Before discussing what you can do to isolate the problem, you should
consider the question of what your options are once the problem is
isolated.  And you should consider going back to whoever gave you the
program and asking them.


Anyhow, the first step is to run the failing program in the debugger.
That will give you the exact point of the crash.  With only a modicum of
luck you will be able to get a backtrace.  With a lot of luck you will
be able to use the backtrace and your knowledge of how the program works
in order to get the working program running under a debugger into the
same state.  Then if you reverse debugging working you are golden.
Since you almost certainly do not, you then have a series of steps of
backing up the program to the same point in the working and non-working
versions, and then moving forward until they deviate.  This is
time-consuming and error-prone.  It also involves starting at a lot of
assembler code.

If you persevere you will be able to identify the point where the
working and non-working execution paths differ.  You will most likely be
looking at assembler code, so you will have to figure out what it means.
What to do at that point depends on what you discover.

It's hard to recommend this procedure.  As I said, it's fairly
desperate.

Ian