[Oorexx-bugs] [ oorexx-Bugs-1847959 ] S390 segmentation fault executing: ./rexx -i

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1847959, was opened at 2007-12-10 07:59
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1847959&group_id=119701

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: 3.2.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: David Ashley (wdashley)
Summary: S390 segmentation fault executing: ./rexx -i

Initial Comment:
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).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-05-21 12:44

Message:
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). 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-05-21 12:44

Message:
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). 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-20 09:37

Message:
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). 

----------------------------------------------------------------------

Comment By: David Ashley (wdashley)
Date: 2008-02-19 09:07

Message:
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.

----------------------------------------------------------------------

Comment By: David Ashley (wdashley)
Date: 2008-02-19 08:56

Message:
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.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-19 08:31

Message:
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.

----------------------------------------------------------------------

Comment By: Rick McGuire (bigrixx)
Date: 2008-02-19 07:50

Message:
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. 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-19 07:40

Message:
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)
--------------------------------------------------------------------------------------

----------------------------------------------------------------------

Comment By: Rick McGuire (bigrixx)
Date: 2008-02-11 13:57

Message:
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

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-11 13:39

Message:
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). 

----------------------------------------------------------------------

Comment By: Rick McGuire (bigrixx)
Date: 2008-02-11 09:37

Message:
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. 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-11 09:32

Message:
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

----------------------------------------------------------------------

Comment By: Rick McGuire (bigrixx)
Date: 2008-02-11 09:28

Message:
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. 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-11 09:22

Message:
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). 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-11 09:21

Message:
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). 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-11 09:21

Message:
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). 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-12-10 13:10

Message:
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.

----------------------------------------------------------------------

Comment By: Rick McGuire (bigrixx)
Date: 2007-12-10 08:35

Message:
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. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1847959&group_id=119701

[Oorexx-bugs] [ oorexx-Bugs-1847959 ] S390 segmentation fault executing: ./rexx -i

REXX interpreter

[Oorexx-bugs] [ oorexx-Bugs-1847959 ] S390 segmentation fault executing: ./rexx -i