Bug 3777
Summary: | Segmentation fault in simple program | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | robert |
Component: | egcs | Assignee: | Nalin Dahyabhai <nalin> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.0 | CC: | jason.wm.mitchell, mgalgoci |
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: | 1999-08-20 12:46:39 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
robert
1999-06-28 13:51:17 UTC
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). Assigned to kingdon. Thsi should be fixed for egcs 1.1.2 *** Bug 4074 has been marked as a duplicate of this bug. *** This bug was reported by Andrew V. Nikulin <andrew> 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 07/16/99 11:49 ------- Matt, can you reply to this message with tar ball attached? TIA *** 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 06/29/99 07:55 ------- This issue has been forwarded to a developer for further action. This is fixed in egcs-1.1.2-16. 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. 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). There is a new fix in egcs-1.1.2-19. See http://egcs.cygnus.com/ml/gcc-patches/1999-08/msg00685.html for a slightly expanded earlyclobber patch (with discussion). 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). 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. See http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00228.html for another update with yet another revised patch/diagnosis. |