[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#246319: libcln3: Segfaults in cln::I_to_digits when converting numbers to binary

On Fri, 30 Apr 2004, Matthias Klose wrote:
> > Right now, I see four alternative solutions:
> > 1) Upload a new Debian package where -fno-exceptions is not turned on.
> If you change interfaces, you'll have at least change the package name
> and/or soname and recompile dependent packages.

I am not aware of a change in interface when turning off -fno-exception!
Is there one?

> > 2) Fix CLN by playing dirty tricks.  For instance, printing the variable
> >    erg's address in src/integer/output/cl_I_print.cc:30 seems to fix the
> >    problem.  It should be possible to somehow read that address without
> >    any side-effect.
> preferred solution, unless

Seems feasible.  Introducing the section

+#if (defined(__GNUC__) && (__GNUC__ == 3) && (__GNUC_MINOR__ < 4))
+      // workaround GCC 3.0.0-3.3.3 compiler bug (cf. Debian bug#246319)
+      static char dummy[40];
+      snprintf(dummy,40,"%d%x%x",need,&erg,erg.LSBptr);

at line 30 of cl_I_print.cc seems to fix the problem.  Yes, I have to
print all three variables.  Any smaller subset doesn't seem to do the
trick.  Scary, I would say.

> > 3) Fix GCC on the 3.3 branch.  It would probably take me at least a full
> >    day to distill a useful testcase, however.  Likely more, if it turns
> >    out to be a Heisenbug.  And if this leads to a fix in the GCC 3.3
> >    branch is more then doubtful, I guess.
> you are able to extract a reduced testcase. yes.
> > 4) Use Debian's gcc-3.4 [0], making that a requirment for depending
> >    packages, too.
> Not really an option because of changes in the C++ ABI and libstdc++.
> > Soooo, what are the chances for gcc-3.4 hitting sarge as the default
> > compiler?  In my experience, this is a much better compiler than 3.3.3, in
> > all respects, including reliability.  The whole 3.3 series seems to be
> > having some problems.  In another context, it has already been suggested
> > by GCC developers that the 3.3 branch may have taken place too early,
> > causing patches not beeing applied properly and so on [1].
> IMO no chance as the default compiler. Remember the time needed for
> the last C++ transition. Maybe as an option, if the runtime libraries
> built by 3.3 and 3.4 are compatible.

Okay, thanks for this assessment.  The runtime libraries aren't
compatible, as far as I know.  This is even manifest from the bump in the
library's soname: It's libstdc++.so.6 in GCC 3.4 vs. libstdc++.so.5 in
GCC 3.[23].

Richard B. Kreckel

Reply to: