Bug 30297

Summary: Segfaults if compiled under current environment
Product: [Retired] Red Hat Linux Reporter: Enrico Scholz <rh-bugzilla>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: nalin, pbrown, teg
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-03-15 19:37:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Enrico Scholz 2001-03-02 13:15:46 UTC
When recompiling the aspell-package under the current environment
(gcc-2.96-76, glibc-2.2.2-3), aspell coredumps (the binary package
delivered with Wolverine seems to work fine; only the recompiled one dies):

$ aspell -c /usr/share/doc/rpm-4.0.2/buildroot
soon). By using *Buildroot*: in your spec file you are indicating
Segmentation fault

$ rpm -qa | grep aspell
aspell-0.32.6-2


I could track it down to utils/emulation.hh:123:

|      Value temp = parms_.deref(i_);
|      ++i_;
|      return temp;

(the segfault happens in ++i_).

Comment 1 Trond Eivind Glomsrxd 2001-03-02 17:14:53 UTC
Can't reproduce this on my system with all the latest packages.

Comment 2 Glen Foster 2001-03-02 17:37:44 UTC
This defect considered MUST-FIX for Florence Gold release

Comment 3 Trond Eivind Glomsrxd 2001-03-02 19:24:28 UTC
I can reproduce it on yesterdays tree... I'll try upgrading it.

Comment 4 Trond Eivind Glomsrxd 2001-03-02 22:03:45 UTC
I think this is a problem with gcc - if you build it with -O0 or -O2, it works
fine. If you add our standard "-march=i386 -mcpu=i686" flags as well, it
segfaults when run.

Comment 5 Jakub Jelinek 2001-03-07 18:17:49 UTC
Ouch, this won't be easy to find out.
I've tracked it down to the gcc-c++-addressof.patch, but unfortunately
that patch changes the assembly output considerably, so I haven't located
which routine gets miscompiled yet.

Comment 6 Trond Eivind Glomsrxd 2001-03-08 00:01:20 UTC
Preston, Glen... I think you might want to look at this: These are our default
compiler options.

Comment 7 Jakub Jelinek 2001-03-08 12:10:40 UTC
Localized to aspell_default_writable_repl::WritableReplS::soundslike_elements(void) const
being miscompiled, more to follow (hopefully).

Comment 8 Jakub Jelinek 2001-03-09 12:49:03 UTC
Minimalized into:
class G {};

struct N {
  N *a;
};

struct V {
  typedef N *W;
  W *m, *n;
  int s() const { return int(n - m); }
  const W &operator[](int x) const { return *(m + x); }
};

struct H;

struct J {
  N *c;
  H *d;
  J(N *x, H *y) : c(x), d(y) {}
};

struct K {
  const N *c;
  const H *d;
  K(const N *x, const H *y) : c(x), d(y) {}
  K(const J &x) : c(x.c), d(x.d) {}
};

struct H {
  V e;
  int f;

  J u()
  {
    for (int x = 0; x < e.s(); ++x)
      if (e[x])
        return J(e[x], this);
    return v();
  }
  J v() { return J((N*)64, this); }
};

struct I {
  H d;
  J u() { return d.u(); }
  J v() { return d.v(); }
};

struct bar {
  virtual ~bar() {}
};

struct E {
  K g;
  E(K x) : g(x) {}
};

struct foo : public bar {
  K h;
  E i;
  foo(const K x, const E &y) : h(x), i(y) {}
};

struct A {
  I *l;
  foo *baz() const;
};

foo *A::baz() const
{
  return new foo(l->u(), E(l->v()));
}

A x;
I i;
foo *f;

int main ()
{
  x.l = &i;
  f = x.baz();
  if (f->h.c != f->i.g.c || f->h.d != f->i.g.d)
    return 1;
  return 0;
}

which fails with -O2 -mcpu=i686 and does not fail with -O2 (or -O0).
The issue is that scheduling reorders load with store to the same location,
but the load is marked as mem/u (constant), so I need to find out what
is supposed to prevent this reordering.

Comment 9 Trond Eivind Glomsrxd 2001-03-09 16:05:57 UTC
When you've found at more about it, please tell us which packages may be
miscompiled by this (how long has this patch been there).

Comment 10 Jakub Jelinek 2001-03-12 12:23:47 UTC
Trond, I'm afraid this would be pretty hard to tell, hacking the backend
so that it would go and discover these cases would be non-trivial.
Anyway, I've just created a patch which seems to make this go away
with -O2 -mcpu=i686 -fPIC (what aspell is actually using), unfortunately
the testcase I've created from it is still miscompiled at -O2 -mcpu=i686
(without -fpic). I've called for help to gcc-local for the second time
(and will at least try to sufficiently test the patch I've made later today).

Comment 11 Preston Brown 2001-03-12 15:19:00 UTC
the only real C++ packages that matter in the distribution are kde and aspell. 
 If KDE isn't segafaulting, then this problem I doubt this problem is being 
encountered there.


Comment 12 Jakub Jelinek 2001-03-13 16:00:04 UTC
BTW: Anybody see any reason why:
    MakeVirEmulation(const Iterator i, const Parms & p = Parms())
      : i_(i), parms_(p) {}
uses const Iterator instead of either Iterator or const Iterator & ?
(I'm discussing the fix on gcc-patches now, so don't take this as an attempt
not to fix gcc, but the above thing which is what causes the miscompilation
does not make sense to me).

Comment 13 Trond Eivind Glomsrxd 2001-03-13 16:43:51 UTC
Not really - ask kevina.net.

Comment 14 Jakub Jelinek 2001-03-14 10:35:15 UTC
I've added debugging into the place and potentially many C++ programs could
be miscompiled (I'm not saying they are, it just has to have bad luck and be
scheduled "right" so that loads precede stores to it.
aspell is affected, doxygen freetype htdig ImageMagick kdeadmin kdegames kdegraphics kdelibs kdemultimedia kdenetwork kdenetwork kdepim kdesdk kdeutils koffice kpppload lam mozilla qt tripwire might be,
plus maybe some of the C++ stuff which failed during last mass rebuild.

Comment 15 Preston Brown 2001-03-15 19:37:07 UTC
ETA on the compiler fix?


Comment 16 Preston Brown 2001-03-19 21:57:28 UTC
fixed compiler is in the tree.