Hello,

yug k wrote:
Hi Rainer,

Please find the required information in blue below . Apologies for a bit delayed response .

oslevel -s
/home/FFAdev> oslevel -s
5300-00-00


This output looks very strange. According to this output it's AIX 5.3 without any Technology Levels / Service packs.
A possible explanation for this might be that the system is not updated completely to a TL/SP. The system should be
at least at TL7 SP8 or SP9; the latest TL is TL10 SP1. Currently IBM only supports TL7 and up.
lslpp -L xlC.rte

/home/FFAdev> lslpp -L xlC.rte
  Fileset                      Level  State  Type  Description (Uninstaller)
  ----------------------------------------------------------------------------
  xlC.rte                    9.0.0.9    C     F    XL C/C++ Runtime

Thats OK.

lslpp -L bos.rte.libc

/home/FFAdev> lslpp -L bos.rte.libc
  Fileset                      Level  State  Type  Description (Uninstaller)
  ----------------------------------------------------------------------------
  bos.rte.libc              5.3.0.30    C     F    libc Library



This indicates that the system is not at TL0. The version of 5.3.0.30 and the output of oslevel
suggests that your system is at an inconsistent patch level.

You can list all service levels known to the system:

# oslevel -q -s

sample output:

Known Service Packs
-------------------
5300-07-08-0918
5300-07-07-0846
5300-07-06-0844
5300-07-05-0831
5300-07-04-0818
5300-07-03-0811
5300-07-02-0806
5300-07-01-0748
5300-07-00-0000
5300-06-11-0918
5300-06-10-0846
5300-06-09-0844
5300-06-08-0831
5300-06-07-0818
5300-06-06-0811
5300-06-05-0806
5300-06-04-0748
5300-06-03-0732
5300-06-02-0727
5300-06-01-0722
5300-05-CSP-0000
5300-05-06-0000
5300-05-05-0000
5300-05-04-0000
5300-05-03-0000
5300-05-02-0000
5300-05-01-0000
5300-04-CSP-0000
5300-04-03-0000
5300-04-02-0000
5300-04-01-0000
5300-03-CSP-0000

With the following command you can check if some filesets are not at the required level.
If you think that your system should be at AIX 5.3 TL7

# oslevel -r -l 5300-07


ulimit -a
/home/FFAdev> ulimit -a
core file size        (blocks, -c) 2048575
data seg size         (kbytes, -d) 131072
file size             (blocks, -f) 2048575
max memory size       (kbytes, -m) 32768
open files                    (-n) 2000
pipe size          (512 bytes, -p) 64
stack size            (kbytes, -s) 32768
cpu time             (seconds, -t) unlimited
max user processes            (-u) 200
virtual memory        (kbytes, -v) unlimited


This is my setting:

/etc/security/limits

default:
        fsize = -1
        core = 2097151
        cpu = -1
        data = -1
        rss = 65536
        stack = 131072
        nofiles = 2000

With your setting you limit the file size to 1GB and the data seg to 128MB.
Your stack size is also very small.

dbx output :

[root]/opt/ooRexx/bin> dbx rxapi
Type 'help' for help.
[using memory image in core]
reading symbolic information ...

Segmentation fault in _Incsize(unsigned long) at line 421 in file "/usr/vacpp/include/list" ($t917)
  421           bool operator>(const list<_Ty, _A>& _X,
(dbx)

(dbx) where
_Incsize(unsigned long)(this = 0x0000005c, _N = 1), line 421 in "list"
_Insert(std::list<APIServerThread*,std::allocator<APIServerThread*> >::iterator,APIServerThread* const&)(this = 0x0000005c, _P = (...), _X = 0x30049d88), line 38 in "list.t"
push_back(APIServerThread* const&)(this = 0x0000005c, _X = 0x30049d88), line 343 in "list"
sessionTerminated(APIServerThread*)(this = (nil), thread = 0x30049d88), line 113 in "APIServer.cpp"
dispatch()(0x30049d88), line 57 in "APIServerThread.cpp"
call_thread_function(void*)(0x30049d88), line 124 in "SysThread.cpp"
_pthread_body(??) at 0xd0111440
(dbx)


My pthread library is :

[root]/opt/ooRexx/bin> lslpp -l | grep pthread
  bos.rte.libpthreads       5.3.0.30  COMMITTED  libpthreads Library



As pointed by you I still have /usr/lpp/orexx/bin/rexx in my path .. I've just removed it and started testing again ..


* Please ensure that the system is at least at TL7 SP8 or SP9
* Please extend the settings in /etc/security/limits

If the daemon still crashes I can provide a rxapi with some debugging code added.


regards,

Yugandhar


Bye
  Rainer
On Wed, Aug 26, 2009 at 2:04 PM, Rainer Tammer <tammer@tammer.net> wrote:
Hello,
please could you also post the output from:

dbx rxapi
(dbx) where
...

 


The core should be in the same directory as rxapi.

Bye
 Rainer

yug k wrote:
> Hi All,
>
> I've had a core dump with rxapi while testing ooRexx 4.0.0 on AIX
> 5.3.0.0 . I've raise a bug for the same couple of days ago bearing Bug
> ID 2844093 on SF . Please find the core dump attached in this mail .
>
> I'm sending the core file by email because it exceeded the limit on
> Source Forge .
>
> For more details about the Bug, please refer the Bug ID 2844093 at :
>
> https://sourceforge.net/tracker/?func=detail&aid=2844093&group_id=119701&atid=684730
> <https://sourceforge.net/tracker/?func=detail&aid=2844093&group_id=119701&atid=684730>
>
> Name : Yug
> Email : yk.forums@gmail.com <mailto:yk.forums@gmail.com>
> SF User : ykforums
>
> regards,
>
> Yug
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>