[Oorexx-bugs] [ oorexx-Bugs-3102440 ] RexxStart hits segmentation fault on SUSE 10.1

[SourceForge.net <no...@so...>]

Bugs item #3102440, was opened at 2010-11-03 16:01
Message generated for change (Comment added) made by davidliebtag
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3102440&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: APIs
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Liebtag (davidliebtag)
Assigned to: Nobody/Anonymous (nobody)
Summary: RexxStart hits segmentation fault on SUSE 10.1

Initial Comment:
When I dynamically load the Rexx shared object libraries and try to call RexxStart, it hits a segmentation fault.

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

>Comment By: David Liebtag (davidliebtag)
Date: 2010-11-04 11:08

Message:
Thank you David.  Those changes do fix our problem.

Can you tell me if the relationship between the Rexx shared libraries is
constant across UNIX systems?  In particular, should we use the same
technique on AIX and Solaris?

The changes are going to require a little bit more thought for us because
we use a subroutine for loading the libraries and some time ago we changed
that subroutine to use RTLD_LOCAL rather than RTLD_GLOBAL for reasons I do
not now recall.  I'll have to look into it.

Thanks again.

David Liebtag

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

Comment By: David Ashley (wdashley)
Date: 2010-11-04 10:39

Message:
Here are the changes to your code I made to get it to work on my system.

   RexxapiDLL = dlopen("librexxapi.so",RTLD_LAZY | RTLD_GLOBAL) ;
   RexxDLL    = dlopen("librexx.so",RTLD_LAZY | RTLD_GLOBAL) ;
   RexxutilDLL    = dlopen("librexxutil.so",RTLD_LAZY | RTLD_GLOBAL) ;

Note that there is a problem in your Rexx source code that causes some
ooRexx error messages to appear on stderr but at lease we can tell the
ooRexx was actually called :-)

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

Comment By: David Ashley (wdashley)
Date: 2010-11-04 10:13

Message:
I think I have a handle on this problem. There are actually 3 problems.

1. The order you load the libraries is wrong. You MUST load rexxapi first,
and then rexx.
2. You MUST use the flag RTLD_GLOBAL when calling dlopen(). Otherwise
neither library will be able to discover the symbols in the other library.
3. You MUST also call dlopen() to load the rexxutil library. Do this as
the last library loaded. There are now dependencies on this library from
the rexx shared library.

I think making the above changes will fix your problem. Please let us know
either way.

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

Comment By: David Liebtag (davidliebtag)
Date: 2010-11-03 23:30

Message:
I installed ooRexx-4.0.1.i586.suse10.rpm on a 32 bit Intel box running Suse
10.1.

We need to load the library dynamically because our code is itself in a
shared library which other parts of our product may use even when the Rexx
interface is not used.

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

Comment By: David Ashley (wdashley)
Date: 2010-11-03 20:54

Message:
One other comment. I am not sure that your methodology is sound for
dynamically loading the Rexx shared libraries. Both of those libraries have
dependencies on the other library. We know that this is really bad design
but it is left over from the original design of the OS/2 and Windows DLLs.
On some Unix systems this means that trying to load any of the two
libraries dynamically will cause the load to fail since there are
unresolved references. Linux does not care about this but it is a
portability issue as some systems do care.

It is MUCH BETTER AND EASIER to link with the libraries when the main
application is linked. Yes, this does cause the libraries to be loaded at
application startup but we find this is a very small price to pay in
initial startup and the memory requirements are very small on even a
minimal sized system. For instance, I typically run large application
programs that interface to ooRexx on virtual machines (i386) with as little
as 400MB of memory with no problems.

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

Comment By: David Ashley (wdashley)
Date: 2010-11-03 20:38

Message:
I need a little more information to debug this.

What version of ooRexx?
32 or 64 bit?
What architecture, i386, s390x, etc?

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

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