Bug 241416 - paw++ crashes on startup
Summary: paw++ crashes on startup
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: cernlib   
(Show other bugs)
Version: rawhide
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Patrice Dumas
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On: 237579
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-05-25 20:58 UTC by Bill Nottingham
Modified: 2014-03-17 03:07 UTC (History)
2 users (show)

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


Attachments (Terms of Use)

Description Bill Nottingham 2007-05-25 20:58:22 UTC
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 21:13:03 UTC
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 21:53:10 UTC
$ 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 08:47:50 UTC
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 19:35:50 UTC
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 22:37:04 UTC
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 05:43:48 UTC
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 07:35:56 UTC
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 13:25:51 UTC
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 21:21:18 UTC
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-18 03:04:04 UTC
paw++-g77 appears to work.

Comment 11 Patrice Dumas 2007-12-12 23:12:28 UTC
The main paw package is now built against g77, I will push
through bodhi now.

Comment 12 Fedora Update System 2007-12-13 22:16:56 UTC
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 22:17:49 UTC
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 23:52:15 UTC
Could you please retest paw++ now?

Comment 15 Bill Nottingham 2007-12-21 00:09:04 UTC
Works on rawhide with 2006-20.fc9 (sorry, all I have on this box at the moment.)

Comment 16 Patrice Dumas 2007-12-21 00:15:26 UTC
Would have been better on F8, but it is enough.

Comment 17 Fedora Update System 2007-12-21 21:09:37 UTC
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 21:12:49 UTC
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 12:43:48 UTC
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 12:44:33 UTC
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 19:47:32 UTC
Both paw++-gfortran and paw-gfortran start OK in rawhide for me.

Comment 22 Martin Donald 2009-01-20 04:47:54 UTC
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.