#474 S390 segmentation fault executing: ./rexx -i

3.2.0
closed
5
2012-08-14
2007-12-10
Anonymous
No

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

  • Nobody/Anonymous

    Output of rpm build session

     
  • Rick McGuire

    Rick McGuire - 2007-12-10

    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.

     
  • Nobody/Anonymous

    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.

     
  • Nobody/Anonymous

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

     
  • Nobody/Anonymous

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

     
  • Nobody/Anonymous

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

     
  • Rick McGuire

    Rick McGuire - 2008-02-11

    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.

     
  • Nobody/Anonymous

    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

     
  • Rick McGuire

    Rick McGuire - 2008-02-11

    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.

     
  • Nobody/Anonymous

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

     
  • Rick McGuire

    Rick McGuire - 2008-02-11

    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

     
  • Nobody/Anonymous

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

     
  • Rick McGuire

    Rick McGuire - 2008-02-19

    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.

     
  • Nobody/Anonymous

    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.

     
  • David Ashley

    David Ashley - 2008-02-19

    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.

     
  • David Ashley

    David Ashley - 2008-02-19

    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.

     
  • Nobody/Anonymous

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

     
  • Nobody/Anonymous

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

     
  • Nobody/Anonymous

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

     
  • LK Swift

    LK Swift - 2008-08-05

    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

     
  • LK Swift

    LK Swift - 2008-08-06

    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

     
  • Nobody/Anonymous

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

     
  • Mark Miesfeld

    Mark Miesfeld - 2009-07-08

    With ooRexx 4.0.0 David has got the rpm build to work on s390x, making this bug out of date at this time.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks