Bug 3777 - Segmentation fault in simple program
Segmentation fault in simple program
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: egcs (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-06-28 09:51 EDT by robert
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-08-20 08:46:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description robert 1999-06-28 09:51:17 EDT
The following simple program when executed  gives a
segmentation violation. This occurs if the -O2 option is
used. The problem also occurs in RedHat 5.2 with g++ -O

#include <stdio.h>
#include <math.h>
int main ()
{
  double etam, etapm, v1[2], v2[2], norm;
  double B = 158.024;
  double a = 1.0076;
  double z = 1.47107;
  double smass = 1.445;

  double factor = 4.0 / 3.0 * pow (4.0 * M_PI, 0.25) * B;
  etam = factor;
  printf ("%g", etam);
  etam = factor * pow (etam, 0.75);
  etapm = factor * pow (etapm, 0.75);
  return (0);
}
Comment 1 Derek Tattersall 1999-06-28 10:02:59 EDT
verified - 28 JUN 1999 DLT

------- Additional Comments From   07/09/99 17:56 -------
I tried the same example with gcc-2.96 19990708 (experimental)
which is the development version from egcs.cygnus.com.  The bug did
not occur.  Ordinarily I would probably still want to know whether
the bug was really fixed or whether it just stopped showing up on
this particular example, but since the IA32 egcs backend has been rewritten I don't know.  I can work on trying to find a patch to egcs 1.1.2 if desired (I already spent time in this direction, although I didn't get very far).
Comment 2 Cristian Gafton 1999-07-09 18:23:59 EDT
Assigned to kingdon. Thsi should be fixed for egcs 1.1.2
Comment 3 Jeff Johnson 1999-07-16 14:46:59 EDT
*** Bug 4074 has been marked as a duplicate of this bug. ***


This bug was reported by Andrew V. Nikulin
<andrew@elkatel.ru>

I have the patch file saved in my home directory. The
tarball is called pam_patch.tgz --MJG

Andrew writes:

"I discovered a serious enough bug in pwdb and pam packages.

So, yesterday I've killed the entire day trying to
understand why sshd2 doesn't work correctly on my Ultra
SPARC box, but it works fine on Intel (both under RedHat
Linux 6.0). After a few sessions with ltrace, gdb and other
tools I've finally understood that a problem appears only
when MD5 hashes are enabled in pam_pwdb module.

Digging sources of pam_pwdb, pwdb and sshd2 I've got next
thing: pwdb and pam use their own routine crypt_md5() for
MD5 calculation, but sshd2 uses standart crypt() from GLIBC
for such purpose.

I wrote a short test program, which simply encrypts the
phrase "magic_word" with salt "$1$xx", calling GLIBC crypt()
and pam_pwdb crypt_md5(). After running this program on SUN
and Intel I've got the following results:

Intel:

pam_pwdb crypt_md5():   $1$xx$ipOG9IJsAo23Ba44.YOUd1
GLIBC crypt():          $1$xx$ipOG9IJsAo23Ba44.YOUd1

SPARC:

pam_pwdb crypt_md5():   $1$xx$tcVZsr28tzKG890dmISsL/
GLIBC crypt():          $1$xx$ipOG9IJsAo23Ba44.YOUd1

My God! - pam_pwdb crypt_md5() makes different hashes
depending on hardware platform.

Finally, I've got that the problem lies in an incorrect
detection of a byte order for the
architecture. Please, look at
pam-0.66/modules/pam_pwdb/md5.c:22, here is an
attempt to understand the byte order by checking the
presence of HIGHFIRST definition.  I had simply replaced
that string with

#if __BYTE_ORDER != __BIG_ENDIAN

and included an appropriate file endiand.h. Such changes I
had applied to pam-0.66/modules/pam_radius/md5.c and
pwdb-0.58/libpwdb/radius/md5.c too.  After rebuilding and
reinstalling packages everything works fine on both
Ultra SPARC and Intel."



------- Additional Comments From jbj@redhat.com  07/16/99 11:49 -------
Matt, can you reply to this message with tar ball attached? TIA
Comment 4 Cristian Gafton 1999-07-28 02:27:59 EDT
*** Bug 3261 has been marked as a duplicate of this bug. ***

The -malign-double switch no longer functions correctly with
egcs-c++-1.1.2. C++ code compiled with this switch, then
linked, SEGVs; dying somewhere in the streams library.  This
is demonstrated with a trivial test program:

        #include <cassert>
        #include <fstream>
        #include <iostream>
        #include <string>

        int main()
        {
          using namespace std;
          string name, value;
          ifstream ifs( "input.dat" );
          assert( ifs.good() );
          while( ifs >> value >> name )
            cout << name << "\t" << value << endl;
          return( 0 );
        }

If -O0 is specified, the SEGV generally occurs in the
istream constructor; on the manipulators flush, width or
precision;  or operator<<(). Specifying -Ox, x > 0, usually
causes SEGV from ifstream::~ifstream(). Linking -static may
prevent the SEGV in some instances with optimization, but I
have not tested this extensively. Since the failure is a
SEGV, there is little guarantee that the location of the
signal will provide useful information

The platforms tested were:

  1.  i686 tweaked RH5.2 (to run egcs/pgcc*-1.1.1) upgraded
to RH6.0
  2.  i486 stock RH5.2 upgraded to RH6.0
  3.  i486 clean install of RH6.0
  4.  i586 clean install of RH6.0

The -malign-double option worked with egcs*-1.1.1.

There is no apparent negative effect on plain C code
compiled with the -malign-double switch.

The test program and input data file, a makefile, verbose
assembler with diffs, egcs-c++-1.1.2 -v -a output(make.out),
and this description are available from:

  http://chico.hm.uc.edu/~jmitchel/linux/malign-double/

-jason


------- Additional Comments From   06/04/99 16:39 -------
I failed to specify that -malign-double option worked with egcs*-1.1.1
on RedHat 5.2 with glibc-2.1-0.990222, binutils-2.9.1.0.23-1, and
libstdc++-2.9.0-7.

------- Additional Comments From jturner@redhat.com  06/29/99 07:55 -------
This issue has been forwarded to a developer for further action.
Comment 5 Jim Kingdon 1999-07-30 09:17:59 EDT
This is fixed in egcs-1.1.2-16.
Comment 6 Jim Kingdon 1999-07-30 17:26:59 EDT
Oops, egcs-1.1.2-16 doesn't have the fix (my fumblefingers in
writing the spec file).  However egcs-1.1.2-17 does.
Comment 7 Jim Kingdon 1999-08-20 08:45:59 EDT
The fix in 1.1.2-17 is wrong, per conversation with Richard Henderson
(it does fix this particular test case but in the wrong way).
Comment 8 Jim Kingdon 1999-08-20 08:46:59 EDT
There is a new fix in egcs-1.1.2-19.
Comment 9 Jim Kingdon 1999-08-25 23:05:59 EDT
See http://egcs.cygnus.com/ml/gcc-patches/1999-08/msg00685.html
for a slightly expanded earlyclobber patch (with discussion).
Comment 10 Jim Kingdon 1999-09-03 22:32:59 EDT
The saga continues at
http://egcs.cygnus.com/ml/gcc-patches/1999-09/msg00156.html
(this message has to do with gcc 2.96*, not egcs 1.1.2).
Comment 11 Jim Kingdon 1999-09-23 17:51:59 EDT
The mystery is solved:
  http://egcs.cygnus.com/ml/gcc-patches/1999-09/msg01126.html
Not completely sure about the situation for EGCS 1.1.2.
Comment 12 Jim Kingdon 2000-01-30 09:56:59 EST
See
  http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00228.html
for another update with yet another revised patch/diagnosis.

Note You need to log in before you can comment on or make changes to this bug.