Bug 241416 - paw++ crashes on startup
paw++ crashes on startup
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: cernlib (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Patrice Dumas
Fedora Extras Quality Assurance
:
Depends On: 237579
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-25 16:58 EDT by Bill Nottingham
Modified: 2014-03-16 23:07 EDT (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2007-05-25 16:58:22 EDT
Description of problem:

[foo@localhost ~]$ paw++
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
LOCB/LOCF: address 0x7fff2719e35c exceeds the 32 bit address space
or is not in the data segments
This may result in program crash or incorrect results
Therefore we will stop here
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Version-Release number of selected component (if applicable):

paw-2006-11.fc7
Comment 1 Patrice Dumas 2007-05-25 17:13:03 EDT
Could you please verify that paw++ isn't linked dynamically with
any cernlib library? In any case I see 2 potential explanations for
this issue. The use of gfortran or the use of the RPMOPTFLAGS that
g77 doesn't support. Unfortunately the cernlib package compiled 
against g77 hasn't been accepted :-\

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237579

it could have been interesting to test with paw++-g77 from that
package, since it could also be something else.
Comment 2 Bill Nottingham 2007-05-25 17:53:10 EDT
$ ldd $(which paw++)
        libXbae.so.4 => /usr/lib64/libXbae.so.4 (0x0000003c3e600000)
        libXm.so.2 => /usr/lib64/libXm.so.2 (0x0000003c42e00000)
        libXaw.so.7 => /usr/lib64/libXaw.so.7 (0x0000003c41a00000)
        liblapack.so.3 => /usr/lib64/atlas/liblapack.so.3 (0x0000003c43200000)
        libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x0000003c40a00000)
        libm.so.6 => /lib64/libm.so.6 (0x00002aaaaacc6000)
        libXt.so.6 => /usr/lib64/libXt.so.6 (0x0000003c3be00000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003c3e200000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00002aaaaaf4a000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaab163000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaab397000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003c3fe00000)
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaab59c000)
        libXp.so.6 => /usr/lib64/libXp.so.6 (0x0000003c42400000)
        libSM.so.6 => /usr/lib64/libSM.so.6 (0x0000003c40200000)
        libICE.so.6 => /usr/lib64/libICE.so.6 (0x0000003c3fa00000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003c3ea00000)
        libXpm.so.4 => /usr/lib64/libXpm.so.4 (0x0000003c3c200000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003c3f600000)
        libXmu.so.6 => /usr/lib64/libXmu.so.6 (0x0000003c4fe00000)
        libblas.so.3 => /usr/lib64/atlas/libblas.so.3 (0x0000003c40e00000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003c3da00000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003c3de00000)
        /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)

Doesn't appear to be anything cernlib-ish linked dynamically.
Comment 3 Patrice Dumas 2007-05-26 04:47:50 EDT
Looks like to me that the simplest fix would be to use paw from the 
cernlib compiled with g77. This would certainly need adding yet
another conditional to the spec file such that the compiler suffix
may be set differently on utilities and on libraries. That way the
utilities would come from the cernlib-g77 and the libraries installed
with cernlib-devel would be the gfortran compiled libs.
Comment 4 Patrice Dumas 2007-05-26 15:35:50 EDT
Most likely possibility is that this failure is caused by one of these 
flags (maybe only with gfortran, though g77 don't accept all of them):

-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4

Unfortunately I don't have access to a x86_64 box. Could it be possible 
for you to rebuild on x86_64 without those flags and try to find out
which one is causing the issue? The flags used during the compilation
of fortran libs and programs (like paw++) are set line 787 of the spec 
file, by

FC_OPTFLAGS="%{optflags}"

Comment 5 Patrice Dumas 2007-05-27 18:37:04 EDT
I make the cernlib-g77 submission block this bug, since using the
utilities from the cernlib-g77 could solve this issue temporarily.

But it won't solve it for real.
Comment 6 Bill Nottingham 2007-05-28 01:43:48 EDT
Building with FC_OPTFLAGS="-g" gives the same (well, similar) error:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
LOCB/LOCF: address 0x7fffc3593a7c exceeds the 32 bit address space
or is not in the data segments
This may result in program crash or incorrect results
Therefore we will stop here
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Not sure why flags would make a difference, as:

LOCB/LOCF: address 0x7fff2719e35c exceeds the 32 bit address space

seems like an obviously bogus warning on x86_64; the address space *should* be >
32 bits.

Comment 7 Patrice Dumas 2007-05-28 03:35:56 EDT
That's strange because it used to work with g77, and Harald
Vogt had a look at the gfortran x86_64 combination for paw. 

For information, you could have a look at:

http://people.debian.org/~kmccarty/cernlib/faq.html#41
Comment 8 Patrice Dumas 2007-08-08 09:25:51 EDT
cernlib-g77 is now in devel; could you please try paw++-g77?
And also please retry paw++, since it was rebuilt, maybe there 
is a compiler issue.
Comment 9 Patrice Dumas 2007-09-17 17:21:18 EDT
I would like to fix that for F8 test 3, could you please
try paw++-g77, if it works I'll swap what provides paw.
Comment 10 Bill Nottingham 2007-09-17 23:04:04 EDT
paw++-g77 appears to work.
Comment 11 Patrice Dumas 2007-12-12 18:12:28 EST
The main paw package is now built against g77, I will push
through bodhi now.
Comment 12 Fedora Update System 2007-12-13 17:16:56 EST
cernlib-2006-20.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update cernlib'
Comment 13 Fedora Update System 2007-12-13 17:17:49 EST
cernlib-g77-2006-20.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update cernlib-g77'
Comment 14 Patrice Dumas 2007-12-20 18:52:15 EST
Could you please retest paw++ now?
Comment 15 Bill Nottingham 2007-12-20 19:09:04 EST
Works on rawhide with 2006-20.fc9 (sorry, all I have on this box at the moment.)
Comment 16 Patrice Dumas 2007-12-20 19:15:26 EST
Would have been better on F8, but it is enough.
Comment 17 Fedora Update System 2007-12-21 16:09:37 EST
cernlib-g77-2006-20.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Fedora Update System 2007-12-21 16:12:49 EST
cernlib-2006-20.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 19 Patrice Dumas 2008-01-16 07:43:48 EST
There has been some improvements in 64 bit handling with
gfortran in 2006-23 (in rawhide). Could you please install/update 
paw-gfortran and try paw++-gfortran or paw-gfortran?
Comment 20 Patrice Dumas 2008-01-16 07:44:33 EST
As a side note, it seems that the failure came from a missing
-fno-automatic in the gfortran build.
Comment 21 Bill Nottingham 2008-01-16 14:47:32 EST
Both paw++-gfortran and paw-gfortran start OK in rawhide for me.
Comment 22 Martin Donald 2009-01-19 23:47:54 EST
I had the same problem (same error message) when compiling and testing a tweaked version of the CERN code MAD. I included -fno-automatic in the gfortran build and the problem disappeared.

Linux localhost.localdomain 2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52 EST 2008 x86_64 x86_64 x86_64 GNU/Linux.

Thanks for the suggestion Patrice !

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