Menu
▾
▴
#474 S390 segmentation fault executing: ./rexx -i
Trying to build ooRexx from source on a IBM System
z/Linux and getting segmentation fault whether I use
s390 (31-bit personality) or s390x (64-bit). I have
uploaded a file "ooRexx-3.2.0-1.src.rpm.out" that is
the result of the rpmbuild session.
The segmentation faultcomes after execution of
./rexx -i
System particulars:
uname -r > 2.6.5-7.283-s390x
uname -m > s390
z/Linux > SUSE Enterprise Linux 9
I tried before with "ooRexx-3.1.2-1" with the same
result.
Any pointers anyone?
Thanks.
Paul Dunkley
Email to: pdunkley AT nycers.nyc.gov
(replace " AT " with "@" before sending).
Discussion
Anonymous
Output of rpm build session
Logged In: YES
user_id=1125291
Originator: NO
Based on the link statements, this is getting built as a 64-bit application. This code will not run in 64-bit mode.
Logged In: NO
bigrixx:
Thanks for your update. I guess that my challenge then is to find out how to force
31-bit linker on this 64-bit system that can feign a 31-bit personality.
Oh well, its off to the SUSE 390 forums, if I can find one.
Logged In: NO
bigrixx: et al,
Just an update on this segmentation fault in Suse s/390 z/Linux. I had our IT/SYSTEMS folks
create a 31-bit only system specially for the rmp packgae build. I got the same segmentation
fault at the same place. While the code may not run on 64-bit, the issue that I am having
on the s/390 platform has nothing to do do with that.
A new file "ooRexx-build-tail.txt" has been uploaded with the tail of the build process
on a SLES 9.31 platform (31-bit).
Since I have the platform available, I am willing to do any testing that the development
team may need to get this working. At thsi point it is safe to say that Object Rexx 3.2.0
does not build on a z/Linux S/390 platform!
Paul Dunkley
Email to: pdunkley AT nycers.nyc.gov
(replace " AT " with "@" before sending).
Logged In: NO
bigrixx: et al,
Just an update on this segmentation fault in Suse s/390 z/Linux. I had our IT/SYSTEMS folks
create a 31-bit only system specially for the rmp packgae build. I got the same segmentation
fault at the same place. While the code may not run on 64-bit, the issue that I am having
on the s/390 platform has nothing to do do with that.
A new file "ooRexx-build-tail.txt" has been uploaded with the tail of the build process
on a SLES 9.31 platform (31-bit).
Since I have the platform available, I am willing to do any testing that the development
team may need to get this working. At thsi point it is safe to say that Object Rexx 3.2.0
does not build on a z/Linux S/390 platform!
Paul Dunkley
Email to: pdunkley AT nycers.nyc.gov
(replace " AT " with "@" before sending).
Logged In: NO
bigrixx: et al,
Just an update on this segmentation fault in Suse s/390 z/Linux. I had our IT/SYSTEMS folks
create a 31-bit only system specially for the rmp packgae build. I got the same segmentation
fault at the same place. While the code may not run on 64-bit, the issue that I am having
on the s/390 platform has nothing to do do with that.
A new file "ooRexx-build-tail.txt" has been uploaded with the tail of the build process
on a SLES 9.31 platform (31-bit).
Since I have the platform available, I am willing to do any testing that the development
team may need to get this working. At thsi point it is safe to say that Object Rexx 3.2.0
does not build on a z/Linux S/390 platform!
Paul Dunkley
Email to: pdunkley AT nycers.nyc.gov
(replace " AT " with "@" before sending).
Logged In: YES
user_id=1125291
Originator: NO
The next step would be get a debugger stack trace from the crashing rexx -i program to see where this is failing.
Logged In: NO
Sorry,
I do not see a way to upload the file that I* mentioned in my post.
That was a quick response. Pray, how do I initiate a "debugger stack trace "?
Please clarify.
pdunkley
Logged In: YES
user_id=1125291
Originator: NO
Not much a Linux debugging hand myself, but generally it is done by running "rexx -i" under gdb and displaying the call stack once the exception occurs.
Logged In: NO
The sum-total of the debugging run (pasted between dashed lines):
/home/dashley/ad/svn/3.2.0/trunk/rpm/BUILD/ooRexx-3.2.0 SLES931-1>gdb --args ./rexx -i
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "s390-suse-linux"..."/home/dashley/ad/svn/3.2.0/trunk/rpm/BUILD/ooRexx-3.2.0/rexx": not in executable format: File format not recognized
(gdb) bt
No stack.
(gdb) quit
Look like we need some other methodoloy to trace this guy.
Ideas anyone? Thanks.
Paul Dunkley
Email to: pdunkley AT nycers.nyc.gov
(replace " AT " with "@" before sending).
Logged In: YES
user_id=1125291
Originator: NO
The actual rexx executable is built in the .libs directory. Try the following to capture the stack trace:
ulimit -c 1000000
gdb .libs/rexx
run -i
bt full
Logged In: NO
Hi bigrixx,
Sorry I was out for a few days. Anyway I did a trace file using "strace" and I have the output fileavailable
for emailing or uploading. In the meantime I saw your update on getting the gdb stack trace.
When I entered your commands in sequence, at the execution stage I got the following
(pasted between dashed lines):
/home/dashley/ad/svn/3.2.0/trunk/rpm/BUILD/ooRexx-3.2.0 SLES931>gdb .libs/rexx
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "s390-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) run -i
Starting program: /home/dashley/ad/svn/3.2.0/trunk/rpm/BUILD/ooRexx-3.2.0/.libs/rexx -i
/home/dashley/ad/svn/3.2.0/trunk/rpm/BUILD/ooRexx-3.2.0/.libs/rexx: error while loading shared libraries: librexx.so.3: cannot open shared object file: No such file or directory
Program exited with code 0177.
(gdb) bt full
No stack.
(gdb)
Module librexx.so.3 is listed as follows:
/home/dashley/ad/svn/3.2.0/trunk/rpm/BUILD/ooRexx-3.2.0 SLES931>ls -ahl ./.libs/ | less
total 21M
drwxr-xr-x 2 root root 8.0K Feb 11 16:27 .
drwxr-xr-x 11 root root 12K Feb 11 17:26 ..
-rw-r--r-- 1 root root 7.7M Feb 11 16:27 librexx.a
lrwxrwxrwx 1 root root 13 Feb 11 16:27 librexx.la -> ../librexx.la
-rw-r--r-- 1 root root 832 Feb 11 16:27 librexx.lai
lrwxrwxrwx 1 root root 16 Feb 11 16:27 librexx.so -> librexx.so.3.0.4
lrwxrwxrwx 1 root root 16 Feb 11 16:27 librexx.so.3 -> librexx.so.3.0.4
-rwxr-xr-x 1 root root 3.7M Feb 11 16:27 librexx.so.3.0.4
-rw-r--r-- 1 root root 97K Feb 11 16:22 librexx_la-ASCIIDBCSStrings.o
...
Does this shed any light on the picture? The ending outpout of the strace command ls also
provided below. It was entered with the following parameters:
strace -o rexximg-trace.out rexx -i
Here is the tail of the output file (pasted between dashed lines):
munmap(0x4016c000, 54359) = 0
set_tid_address(0x4040b0c8) = 3008
rt_sigaction(SIGRTMIN, {0x40258030, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0x7ffff158, 34, (nil), 0}) = 0
getcwd("/home/dashley/ad/svn/3.2.0/trunk/rpm/BUILD/ooRexx-3.2.0", 4097) = 56
geteuid() = 0
brk(0) = 0x403000
brk(0x424000) = 0x424000
brk(0) = 0x424000
socket(PF_UNIX, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = 0
writev(3, [{"\0\0\0\2\0\0\0\1\0\0\0\2", 12}, {"0\0", 2}], 2) = 14
read(3, "\0\0\0\2\0\0\0\1\0\0\0\5\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0"..., 36) = 36
read(3, "root\0x\0root\0/root\0/bin/bash\0", 28) = 28
close(3) = 0
open("/root/..OOREXX3.2.0.0_root", O_RDWR|O_CREAT, 0600) = 3
close(3) = 0
mmap(NULL, 4198400, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4040c000
rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {0x40161914, ~[RTMIN], SA_RESTART}, NULL, 8) = 0
gettimeofday({1202768858, 898489}, NULL) = 0
open("/etc/localtime", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4080d000
read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 4096) = 1267
close(3) = 0
munmap(0x4080d000, 4096) = 0
uname({sys="Linux", node="sles931", ...}) = 0
stat64("CoreClasses.orx", {st_mode=S_IFREG|0644, st_size=107591, ...}) = 0
open("/home/dashley/ad/svn/3.2.0/trunk/rpm/BUILD/ooRexx-3.2.0/CoreClasses.orx", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=107591, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4080d000
fstat64(3, {st_mode=S_IFREG|0644, st_size=107591, ...}) = 0
_llseek(3, 106496, [106496], SEEK_SET) = 0
read(3, " raise syntax 88.905 array(nam"..., 1095) = 1095
_llseek(3, 0, [0], SEEK_SET) = 0
read(3, "/*------------------------------"..., 106496) = 106496
read(3, " raise syntax 88.905 array(nam"..., 4096) = 1095
close(3) = 0
munmap(0x4080d000, 4096) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
rexximg-trace.out lines 380-424/424 (END)
--------------------------------------------------------------------------------------
Logged In: YES
user_id=1125291
Originator: NO
Hmmmm, not at all what I was expecting to see. I'm assuming you don't have a userid of "dashley" on your system. For some reason, the build is attempting to load a file from the "/home/dashley/ad/...", and that's what is failing. Are you building from the source rpm or from an svn checkout of the code? I think David Ashley is going to need to chime in on this one.
Logged In: NO
Yes, I had to setup the "/home/dashley/..." directory structure before it would go
anywhere with the build. I also creted the user "dashley" on the system as it would issue
messages about using "root" instead but not doing the build just the same. Seems it was
not updating/overriding the "oorexx.spec" file extracted from the source. I though put
these things down to my knowing the full options of the "rpmbuild" command.
To summarize, the "/home/dashley/ad/svn/3.2.0/trunk/rpm/BUILD/ooRexx-3.2.0" directory does
exist on my system.
Logged In: YES
user_id=931756
Originator: NO
I think this is due to your using the spurce rpm to compile from. If it is and it requires the dashley account then that is my fault. I will look into this.
Logged In: YES
user_id=931756
Originator: NO
I think this problem can be worked around if you specify your own buildroot subdirectory on the rpmbuild command like this
rpmbuild --buildroot ./
That should override and buildroot specification in the source rpm.
Logged In: NO
I am posting the results of removing the "dashley" a/c and directories as follows:(pasted between dashed lines):
/home/db2admin SLES93-1>rpmbuild --rebuild --buildroot ./pkg ooRexx-3.2.0-1.src.rpm > oorexx-redirect.out
warning: user dashley does not exist - using root
warning: user dashley does not exist - using root
error: File /home/dashley/ad/svn/3.2.0/trunk/ooRexx-3.2.0.tar.gz: No such file or directory
/home/db2admin SLES93-1>
Thanks for your continued help in getting to the the bottom of this S/390 z/Linux install
issue for Object REXX.
Paul Dunkley
Email to: pdunkley AT nycers.nyc.gov
(replace " AT " with "@" before sending).
Logged In: NO
Hello,
Just checking back since it has been a while ... was there something
further that was expected of me here?
Please advise.
Paul Dunkley
Email to: pdunkley AT nycers.nyc.gov
(replace " AT " with "@" before sending).
Logged In: NO
Hello,
Just checking back since it has been a while ... was there something
further that was expected of me here?
Please advise.
Paul Dunkley
Email to: pdunkley AT nycers.nyc.gov
(replace " AT " with "@" before sending).
Logged In: YES
user_id=2169908
Originator: NO
I just sent this off to the original poster, and to the developers forum:
I managed to get this to compile using the source tarball by doing the following:
set CFLAGS=-m31 before running configure.
changing the Makefile so that -O2 is replaced by -O0 (zero).
-LK Swift
Logged In: YES
user_id=2169908
Originator: NO
I just sent this off to the original poster, and to the developers forum:
I managed to get this to compile using the source tarball by doing the following:
set CFLAGS=-m31 before running configure.
changing the Makefile so that -O2 is replaced by -O0 (zero).
-LK Swift
Logged In: NO
Thanks to forum poster "LK Swift" I have got a resolution to this issue of building Object
REXX 3.2.0 on SUSE Linux 9 platform on IBM System Z. From "LK Swift"'s post he used a
method to change the Makefile that was created and then use the source ...tar.gz file to
do the build.
I modified his method to use RPM to go the full way and create a RPM Package that could be
installed, and uninstalled at will. This is what I preferred. Here is what I did, building
on his recommendation to turn off optimazation (-O0); (Some of these steps may now be
unnecessary but I give them all)
1) Create a new "/etc/rpmc" file from original "/usr/lib/rpm/rpmrc". Cull the file and keep
only the sections for a "S390" & "S390x" platform. Change the "O2" optflags parameter to
"O0". This overrides the optimizaton parameter for RPM initiated compiles.
2) Submit the command:
export CFLAGS="-g -O0"
This sets the CFLAGS on a 31-bit system. If on a 64-bit system then you will need to
also add the "-m31" parameter to do 31-bit compiles.
3) Run the RPM build command. From the directory where the RPM source is downloaded, do
this:
rpmbuild --rebuild ooRexx-3.2.0-1.src.rpm
4) Here is the kicker; This process will bomb out telling you that directory
/home/dashley/ad/svn/3.2.0/trunk/rpm/...
or some variant of this, does not exist. Painstakingly recreate all the directory paths
that it complains about. You may have to go through 4 to 5 iterations of creating
directory paths and branches.
If you really want a RPM package then that is the price to pay from here on. Even after
the directories are fully in place it will still complain that it could not get a hold
of parent directories somewhere along the line. Ignore these.
You want to see it finally say "exit 0" at the end. When you see that then your RPM
package will be in directory "/home/dashley/ad/svn/3.2.0/trunk/rpm/RPMS/s390/"
as file "ooRexx-3.2.0-xxxx.s390.rpm", where xxxx is a build number it got somewhere.
Mine was 1199.
5) Now install like any other RPM package.
6) Remember that you overrode the "O2" parameter for RPM compiles.You may want to reset
it or delete the file in /etc. Up to you.
Regards.
Paul Dunkley
Email to: pdunkley AT nycers.nyc.gov
(replace " AT " with "@" before sending).
With ooRexx 4.0.0 David has got the rpm build to work on s390x, making this bug out of date at this time.