KEEP_STATE/Tuxedo buildserver issue

Hello, I became familiar with KEEP_STATE a few months ago. It seems to work great... however, the Tuxedo buildserver utility seems to be tripping it up. I must be doing something obviously wrong here, because I can seem to find any other's sharing this experience anywhere here or elsewhere on the web.. and I assume there plenty of other folks out there who are running buildserver from a makefile.
The problem seems to be... the temporary stub main module (BS-*.c) that buildserver generates. Each one of these is getting added to the .make.state file, and seems to trigger a re-build of the target executable. So, it just keeps re-running buildserver over and over again, as each new BS-*.c file is generated.
I think a simple fix... would be a buildserver command line option to enable one to explicitly specify the name of the stub module, but I can find no such option.
Before I begin sharing makefile content, etc... I'll just throw this out there, see if there are any immediate answers.
Is there anything I can do to prevent KEEP_STATE from picking up each of these new BS-*.c files as they're created?
Thanks in advance for any insights,
Jeff

Hi Jeff,
Thank you very much for your report. I'm RE for dmake, and I'll be happy to help you in this investigation.
Can you file a bug against dmake for this issue?
Here is an example of a bug report:
https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=17990242&rptno_count=1&pos=1&report_title=&query_id=-1
It would be great to have a small test case, but if it is difficult to create, we can use your real build process to investigate the problem.
Thanks.
Nik

Similar Messages

Tuxedo buildserver : use SQL in cobol applics

Hi,
I'm trying to use SQL through COBOL applications in a Tuxedo (8.0) environment.
I've added the ODBC libpath to the buildserver command. The execution/compilation of the buildserver seems to be ok, but upon execution of the cobol program the SQL CONNECT fails with SQL-error err 10000.
I have no idea how to make SQL work ? Can anyone help ?
I read about RM (resources manager), is this required to make it work ?
thanks !
Hugo
Our platform is HP/UX and we use SQL/COBOL outside tuxedo without problems.
This is the make file :
# Fc 970618: incremental compilation for Cobol added
TUXINC=$(TUXDIR)/include
BTNINC=$(BTNDIR)/incl
INCLUDES=-I $(TUXINC) -I $(BTNINC) -I /jates/progs/srcs
ODBCLIBS="-L /usr/local/unixODBC/lib -lodbc"
COBOPT="-t"
COBCPY="/jates/tuxedo80/cobinclude:/jates/btn/btndevl/incl:/jates/cobol/cobol4000sp2/cpylib"
#avoid unwanted C-compiler warnings
NLSPATH=$NLSPATH:/opt/ansic/lib/nls/msg/C/%N.cat
# btnrouter
btnrouter: /jates/progs/tps/btnrouter.cbl /jates/progs/tps/btn400.cbl /jates/progs/tps/mod461.cbl /jates/progs/tps/mod470.cbl
     buildserver -C -v -o $@ \
-f /jates/progs/tps/btnrouter.cbl \
-f /jates/progs/tps/btn400.cbl \
-f /jates/progs/tps/mod461.cbl \
-f /jates/progs/tps/mod470.cbl \
-f /jates/progs/tps/res400.cbl \
-f ${ODBCLIBS} \
-s SJETAIR
     -tmshutdown -s $@
     cp -p $@ ..
     -tmboot -s $@
# general instructions
.SUFFIXES: .cbl .c .o
.c.o: $(BTNINC)/fml_flds.h
     cc -c $(INCLUDES) $<
.cbl.o: $(BTNINC)/fml_flds.h
     cob -xc $<
#******************************************************

The normal way to use Tuxedo with an XA-compliant resource manager is to
1. Have the Tuxedo administrator add a line for the resource manager to the
$TUXDIR/udataobj/RM file including the resource manager name, XA switch
name, and libraries required for linking.
2. Build servers using the resource manager with the "-r rmname" line.
This will include the resource manager lines specified in
$TUXDIR/udataobj/RM in the buildserver line, and the application will not
need to manually provide the libraries to buildserver.
3. If using transactions, have the Tuxedo administrator build a TMS process
for the RM using the buildtms command, or do this yourself. If not using
transactions, this step can be omitted.
When a server is built with the "-r rmname" option, Tuxedo will
automatically call TPOPEN to connect to the resource manager within
TPSVRINIT.
(The only exception to this is if the application programmer replaces the
default verion of TPSVRINIT with their own version and does not include a
call to TPOPEN, so it is good to verify that this is not the case.) Since
Tuxedo opens the resource manager when the server is started, there is no
need to include SQL CONNECT statements within the application logic in such
a server.
If your resource manager is not XA compliant then you will need to manage
connection to the database yourself, but most databases are XA compliant
nowadays.
<Paul Debleecker> wrote in message news:[email protected]...
Hi,
I'm trying to use SQL through COBOL applications in a Tuxedo (8.0)
environment.
I've added the ODBC libpath to the buildserver command. The
execution/compilation of the buildserver seems to be ok, but upon
execution of the cobol program the SQL CONNECT fails with SQL-error err
10000.
I have no idea how to make SQL work ? Can anyone help ?
I read about RM (resources manager), is this required to make it work ?
thanks !
Hugo
Our platform is HP/UX and we use SQL/COBOL outside tuxedo without
problems.
This is the make file :
# Fc 970618: incremental compilation for Cobol added
TUXINC=$(TUXDIR)/include
BTNINC=$(BTNDIR)/incl
INCLUDES=-I $(TUXINC) -I $(BTNINC) -I /jates/progs/srcs
ODBCLIBS="-L /usr/local/unixODBC/lib -lodbc"
COBOPT="-t"
COBCPY="/jates/tuxedo80/cobinclude:/jates/btn/btndevl/incl:/jates/cobol/cobol4000sp2/cpylib"
#avoid unwanted C-compiler warnings
NLSPATH=$NLSPATH:/opt/ansic/lib/nls/msg/C/%N.cat
# btnrouter
btnrouter: /jates/progs/tps/btnrouter.cbl /jates/progs/tps/btn400.cbl
/jates/progs/tps/mod461.cbl /jates/progs/tps/mod470.cbl
buildserver -C -v -o $@ \
-f /jates/progs/tps/btnrouter.cbl \
-f /jates/progs/tps/btn400.cbl \
-f /jates/progs/tps/mod461.cbl \
-f /jates/progs/tps/mod470.cbl \
-f /jates/progs/tps/res400.cbl \
-f ${ODBCLIBS} \
-s SJETAIR
-tmshutdown -s $@
cp -p $@ ..
-tmboot -s $@
# general instructions
.SUFFIXES: .cbl .c .o
.c.o: $(BTNINC)/fml_flds.h
cc -c $(INCLUDES) $<
.cbl.o: $(BTNINC)/fml_flds.h
cob -xc $<

Tuxedo Production Issue:LIBTUX_CAT:5005

Dear friends,
Problem : We getting the Tuxedo Error LIBTUX_CAT:5005 , in our Production Environment , frequently .
The Impact : Tuxedo Is not at all responding , even tmadmin/tmipcrm/tmshutdown commands are not responding .
Please help us to identify the root cause for this issue.
Here is the Details of our Tuxedo Production environment
TUXEDO MACHINE DETAILS
Tuxedo Version : TUXEDO 8.0
Patch : No Patch Applied
Operating System : AIX Version 5.3 level 04
oslevel -r : 5300-04
Oracle client : SQL*Plus: Release 9.2.0.3.0 - Production on Sat May 12 19:25:18 2007
System Model: IBM,9119-590
Processor Type: PowerPC_POWER5
Processor Clock Speed: 1654 MHz
CPU Type: 64-bit
Kernel Type: 64-bit
Firmware Version: IBM,SF235_206
Paging Space Information
Total Paging Space: 4096MB
DATABASE MACHINE DETAILS .
Oracle Version : 10.2.0.3 (10g release2 patch 2 )
Operating System : AIX Version 5.3 level 04
oslevel -r -> 5300-04
System Model: IBM,9119-590
Processor Type: PowerPC_POWER5
Processor Clock Speed: 1654 MHz
CPU Type: 64-bit
Kernel Type: 64-bit
Firmware Version: IBM,SF235_206
Paging Space Information
Total Paging Space: 10240MB
Entry details from ULOG .
63924.mware02!bnatrx.11628728.1.0: Starting service BNATRX [Key = 0220B472201108A1A00000000000040000805402000000000180000000000000000.000000003241163925051268200000000588845     7132160032410376    BNAQTF4803550376            ]
163924.mware02!bnatrx.11628728.1.0: NAZIM - Before calling stored procedure --- INPUT-FIELDS = [0220B472201108A1A00000000000040000805402000000000180000000000000000.000000003241163925051268200000000588845 7132160032410376 BNAQTF4803550376 QATIF 0151003|5001|10001SARSAR1040248100 1040248100 0001175.75 002008010810000000000000000000]
163924.mware02!bnatrx.11628728.1.0: DEBUG: Just before bna_caller [Key = 0220B472201108A1A000000000000400008]
163924.mware02!bnatrx.11628728.1.0: JUN B - Reply of bna_caller OUTPUT-FIELDS = [ATMFINUPD0320070512163925B003241             000000001001001000000000000000000000000000000025   BNA0376                         555500000000000000NOR66660000864UBCH2007051220070512SAR0000000000180.000000000000180.00BNA SEC Bill # 1040248100              48              /025                    00000000000000000000SAR0000000000000.0001.00000020070512N      00000000000000000000SAR0000000000000.0001.00000020070512N      SAR0000000000000.0000000000000000000000SAR0000000000000.0000000000000000000000                    163925         000000         000000NNNNNNNNNN      085000000000000000                          NN1040248100     04        00C0001            0000000000000000000000000180.000020080108]
163924.mware02!op2trx.14397630.1.0: DEBUG: About to call service 'GFCUPD'
163937.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
163944.mware02!sddtrx.12288238.1.0: Entering service SDDTRX: [Key = BDSFININQ1120070512163944878800    ]
163944.mware02!sddtrx.12288238.1.0: SDDTRX: TranCode/Numentries is SDDTRX01 0
163944.mware02!sddtrx.12288238.1.0: DEBUG: Forward to GFCINQ: [BDSFININQ1120070512163944878800              000000001001001000000000000000000000000000000067   02BSF7690                       555500000000000000NOR6666000002901        26577893       03 ]
163944.mware02!sddtrx.12288238.1.0: Entering service SDDTRX: [Key = BDSFININQ1120070512163944878805    ]
163944.mware02!sddtrx.12288238.1.0: SDDTRX: TranCode/Numentries is SDDTRX01 0
163944.mware02!sddtrx.12288238.1.0: DEBUG: Forward to GFCINQ: [BDSFININQ1120070512163944878805              000000001001001000000000000000000000000000000067   02BSF7690                       555500000000000000NOR6666000002901        26577893       03 ]
163947.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
163948.mware02!sddtrx.12288238.1.0: Entering service SDDTRX: [Key = BDSFINUPD0320070512163947878810    ]
163948.mware02!sddtrx.12288238.1.0: SDDTRX: TranCode/Numentries is SDDTRX01 0
163948.mware02!sddtrx.12288238.1.0: DEBUG: Forward to GFCUPD: [BDSFINUPD0320070512163947878810              000000001001001000000000000000000000000000000067   02BSF7690                       555500000000000000NOR66660000864UBCH2007051220070512SAR0000000000703.450000000000703.45STC Bill Bill # 265778933                                                       00000000000000000000SAR0000000000000.0001.00000020070512N      00000000000000000000SAR0000000000000.0001.00000020070512N      SAR0000000000000.00                    SAR0000000000000.00                                        163947         000000         000000NNNNNNNNNN      022000000000000000                          NN265778933      01        00C03            0000000000000000000000000703.450020070415                 000000002007041520000000000000.0000   00000000000            00                                                                                                                        ]
163957.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164007.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164017.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164027.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164037.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164047.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164057.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164107.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164117.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
Thanks In Advance for your help and support
Nadeer
Edited by nadeer78 at 05/13/2007 2:49 AM

Hi Lin,
I do know there was a problem with the Tuxedo 8.1 restart server under certain conditions (mostly related to having to restart large numbers of servers in a short period of time) that might have caused a problem like you are seeing.
I suggest you contact BEA support and open a case with them. They'll have access to the best information regarding this type of a problem and will be able to help you get this resolved.
Regards,
Todd Little
BEA Tuxedo Chief Architect

Tuxedo domain issue

There is a very strange case here in my application. The GWTDOMAIN always terminated
abnormally and restarted again. I checked the core dump file it generated and
it showed me that it happened in '_tmrunserver()'. I do not know why.

Folks,
Hello. I am confusing !
There are 3 options ( sysdba, sysoper and sysasm ) for the command SQLPLUS.
Let me explain the commands one by one as below:
First, the command $./sqlplus AccessId/myPwd cannot connect with SQL> and then we cannot start up Database Instance HRCS90 !
Second, I run sysdba option in the following order:
$./sqlplus AccessId/myPwd as sysdba
SQL>startup
SQL>@/opt/PT8.53/scripts/rel853.sql
SQL> select OPERPSDWSALT from AccessId.PSOPRDEFN;
Its output: OPERPSWDSALT: invalid identifier. I have checked the field is not created into table PSOPRDEFN.
Third, I run sysoper option in the following order:
SQL>shutdown immediate;
SQL>exit
$./sqlplus AccessId/myPwd as sysoper
SQL>startup
SQL>@/opt/PT8.53/scripts/rel853.sql
When run rel853.sql, I saw many insufficient priviledges regarding Create Tables.
SQL> select OPERPSWDSALT from AccessId.PSOPRDEFN;
Its output: OPERPSWDSALT : invalid identifier. This error is the same with option sysdba.
Fourth, I run sysasm option as below:
SQL>shutdown immediate;
SQL>exit
$./sqlplus AccessId/myPwd as sysasm
It returns: Logon denied.
As we see above, I have tried 3 options(sysdba, sysoper, sysasm) to run the command sqlplus AccessId/myPwd but the result of script rel853.sql is not right.
My question is:
Can any folk tell me the correct order and commands to run the script rel853.sql ?
Thanks.
Folks,
Hello. All of the above 3 options are wrong. I have done below:
$./sqlplus / as sysdba
SQL>show user;
USER is "SYS"
SQL>startup
SQL>connect AccessId/myPwd
SQL>show USER;
USER is "AccessId"
SQL>@/opt/PT8.53/scripts/rel853.sql
Script completed.
Application Designer login into Database HRCS90 successfully now.
Tuxedo Application Server boot domain HRCS90 with 8 processes started.
The issue is solved. Thank you all very much.

Tuxedo Runtime issues.

I am attempting to create a replicated environment of tuxedo on aix. However facing two errors i am not sure if they are different from each other or same:
1) When i attempt buildtms using buildtms -r Oracle_XA -o EPTMS
i get the following errors and create the file:
cc: unrecognized option '-brtl'
cc: unrecognized option '-qstaticinline'
cc: unrecognized option '-brtl'
cc: unrecognized option '-qstaticinline'
2) When i tmboot processes it gives errors on most of the processes as follows:
CMDTUX_CAT:819: INFO: Process id=1400908 Assume started (pipe).
exec TxGetHostData -A -s atux_TxGet:TxGetHostData -- -U :
Could not load program TxGetHostData:
rtld: 0712-001 Symbol strcat was referenced
from module TxGetHostData(), but a runtime definition
of the symbol was not found.
rtld: 0712-001 Symbol strcpy was referenced
from module TxGetHostData(), but a runtime definition
of the symbol was not found.
rtld: 0712-001 Symbol strcmp was referenced
from module TxGetHostData(), but a runtime definition
of the symbol was not found.
rtld: 0712-001 Symbol strncpy was referenced
from module TxGetHostData(), but a runtime definition
of the symbol was not found.
rtld: 0712-001 Symbol log was referenced
from module TxGetHostData(), but a runtime definition
of the symbol was not found.
Any suggestions?
Thanks in advance
Salman

Hi Salman,
What version of Tuxedo are you using? What version of AIX are you using? What compiler are you using? I'm guessing from the errors that you are likely using an unsupported compiler, either the wrong version of the IBM AIX compiler or perhaps the GNU compiler which isn't supported on AIX.
Oh, one other question: Have you been able to build and run any Tuxedo application with the environment that you've set up such as the Tuxedo simpapp sample application?
Regards,
Todd Little
Oracle Tuxedo Chief Architect

Timeout: Tuxedo kills the service but not the database connection

Hi all,
I am experiencing some performance problems on my system due an efficient SQL and a Tuxedo improper timeout handling.
A service is using a "problematic" SQL (we will tune it but it's not the main problem). After 60 seconds from the execution, Tuxido kills the services for a timeout.
At this point I would like Tuxedo to notify DB2 database as well in order to stop processing the SQL. Instead the SQL continues running on the database (also if the service is killed) and this produce a gradual slow down of the performances.
In the UBBCONFIG, we are using a service configuration like the following timeout configuration:
.RESOURCES
SCANUINIT 5
SANITYSCAN 6
BLOCKTIME 12
.SERVICES
DEFAULT: SVCTIMEOUT=45
service1 SVCTIMEOUT=60 TRANTIME=60
service2 SVCTIMEOUT=60 TRANTIME=60
Note: not all the services are listed in the .SERVICES section and we are using the default NOTIFY as well as an OPENINFO.
Can you please help me in finding a configuration to kill both the services and the database?
Thanks in advance,
Benedetto

Hi Benedetto.
First of all, Tuxedo doesn't kill services, it kills servers. Your UBBCONFIG file specifies three timeouts, BLOCKTIME, SVCTIMEOUT, and TRANTIME.
BLOCKTIME specifies how long a Tuxedo API that needs a response will wait for that response. If the response isn't received in that period of time, Tuxedo will return TPETIME to the caller. As with any failure, if the request was part of a transaction, the transaction is marked rollback only. Note, this timeout does not affect the request, whether sitting in a server's IPC queue or currently executing in a server.
SVCTIMEOUT is a much more severe timeout and determines how long Tuxedo will allow a service implementation to execute. If a service implementation doesn't reply within the SVCTIMEOUT period, Tuxedo will issue an OS level KILL request to kill the process. If the server is marked restartable, Tuxedo will then try to restart the server assuming none of the restart limits have been reached. Killing the server causes the request to be lost within the server so the caller will stay blocked until BLOCKTIME is reached at which point the above actions will take place.
TRANTIME is the amount of time Tuxedo allows a transaction to remain active and viable. When this period expires, Tuxedo will mark the transaction as timed out with the only option being rollback. As well, Tuxedo aborts any API requests that would normally cause messaging to occur, i.e., making a tpcall() within a timed out transaction will fail without any attempt to call the service.
So in your case, the issue is partially that you have the values of your timeouts in somewhat reverse order. Typically we see BLOCKTIME being the smallest value, with TRANTIME typically larger than BLOCKTIME, and SVCTIMEOUT larger even still, although there are good reasons for exceptions to this guideline. Part of the reasoning behind this is that killing a server is a significant thing and its usually best to try and let the server complete whatever its doing, if if the work has been timed out either due to BLOCKTIME or TRANTIME, since the cost of killing and restarting a server is significant.
Tuxedo will notify the database of the transaction status when the application finally issues a tpcommit() or a tpabort() request, but not until then. Although, if SVCTIMEOUT is hit, then killing the server should cause the database connection to be lot.
If you could describe the behavior you are seeing and the relevant portions of your ULOG we can try to make some sense of what is happening.
Regards,
Todd Little
Oracle Tuxedo Chief Architect

Core file generating in tuxedo8.1

Hi,
we are using tuxedo8.1 and we are seeing core file getting generated and not able to identify the reason for the same.
below are the details
using debugger below is the output we got
file core
core: ELF-64 core file - IA64 from 'ck_CustomerUdt' - received SIGSEGV
Core was generated by `ck_CustomerUdt'.
warning: ck_CustomerUdt is 14 characters in length. Due to a limitation
in the HP-UX kernel, core files contain only the first 14 characters
of an executable's name. Check if ck_CustomerUdt is a truncated name.
If it is so, core-file, packcore and other commands dealing with
core files will exhibit incorrect behavior. To avoid this, issue
exec-file and symbol-file commands with the full name of the executable
that produced the core; then issue the core-file, packcore or other
core file command of interest.
Program terminated with signal 11, Segmentation fault.
SEGV_MAPERR - Address not mapped to object
warning: Load module /oraclehometux/oracle/product/10.2.0/db_1/lib/libclntsh.so.10.1 has been stripped.
Debugging information is not available.
warning: Load module /oraclehometux/oracle/product/10.2.0/db_1/lib/libnnz10.so has been stripped.
Debugging information is not available.
#0 0xc00000000866d1f0:0 in UDTProcess () at udt_Process.c:89
89 udt_Process.c: No such file or directory.
in udt_Process.c
(gdb) bt
#0 0xc00000000866d1f0:0 in UDTProcess () at udt_Process.c:89
#1 0xc0000000214e33c0:0 in ck_CustomerUdtRequest () at udt.c:616
#2 0x400000000000b800:0 in commonServiceWrapper () at ck_CustomerUdt.c:866
#3 0x40000000000101e0:0 in I_CustomerUdtRequest () at ck_CustomerUdt.c:1285
#4 0xc000000003c15020:0 in _tmsvcdsp () at tmsvcdsp.c:545
#5 0xc000000003c66bb0:0 in _tmrunserver () at tmrunsvr.c:2015
#6 0xc000000003c12a90:0 in _tmstartserver () at tmstrtsrvr.c:141
#7 0x4000000000005240:0 in main () at BS-109a.c:76
Current language: auto; currently c
showing as udt_Process.c no such file.
please help as we are facing this eery day. and every time core generating with same error

Hi,
Well from the call stack it looks like your server made a bad pointer reference on line 89 in file udt_Process.c. This really is unlikely to be a Tuxedo related issue. More likely just a coding error in the service.
Regards,
Todd Little
Oracle Tuxedo Chief Architect

Performance issues with the Tuxedo MQ Adapter

We are experimenting some performance issues with the MQ Adapter. For example, we are seeing that the MQ Adapter takes from 10 to 100 ms in reading a single message from the queue and sending to the Tuxedo service. The Tuxedo service takes 80 ms in its execution so there is a considerable waste of time in the MQ adapter that we cannot explain.
Also, we have looked a lot of rollback transactions on the MQ adapter, for example we got 980 rollback transactions for 15736 transactions sent and only the MQ adapter is involved in the rollback. However, the operations are executed properly. The error we got is
135027.122.hqtux101!MQI_QMTESX01.7636.1.0: gtrid x0 x4ec1491f x25b59: LIBTUX_CAT:376: ERROR: tpabort: xa_rollback returned XA_RBROLLBACK.
I am looking for information at Oracle site, but I have not found nothing. Could you or someone from your team help me?

Hi Todd,
We have 6 MQI adapters reading from 5 different queues, but in this case we are writing in only one queue.
Someone from Oracle told us that the XA_RBROLLBACK occurs because we have 6 MQ adapters that are reading from the same queues and when one adapter finds a message and try to get that message, it can occurs that other MQ Adapter gets it before. In this case, the MQ adapter rollbacks the transaction. Even when we got some XA_RBROLLBACK errors, we don´t lose message. Also, I read something about that when XA sends a xa_end call to MQ adapter, it actually does the rollback, so when the MQ adapter receives the xa_rollback call, it answers with XA_RBROLLBACK. Is that true?
However, I am more worried about the performance. We are putting a request message in a MQ queue and waiting for the reply. In some cases, it takes 150ms and in other cases it takes much more longer (more than 400ms). The average is 300ms. MQ adapter calls a service (txgralms0) which lasts 110ms in average.
This is our configuration:
"MQI_QMTESX01" SRVGRP="g03000" SRVID=3000
CLOPT="-- -C /tuxedo/qt/txqgral00/control/src/MQI_QMTESX01.cfg"
RQPERM=0600 REPLYQ=N RPPERM=0600 MIN=6 MAX=6 CONV=N
SYSTEM_ACCESS=FASTPATH
MAXGEN=1 GRACE=86400 RESTART=N
MINDISPATCHTHREADS=0 MAXDISPATCHTHREADS=1 THREADSTACKSIZE=0
SICACHEENTRIESMAX="500"
/tuxedo/qt/txqgral00/control/src/MQI_QMTESX01.cfg:
*SERVER
MINMSGLEVEL=0
MAXMSGLEVEL=0
DEFMAXMSGLEN=4096
TPESVCFAILDATA=Y
*QUEUE_MANAGER
LQMID=QMTESX01
NAME=QMTESX01
*SERVICE
NAME=txgralms0
FORMAT=MQSTR
TRAN=N
*QUEUE
LQMID=QMTESX01
MQNAME=QAT.Q.NACAR.TO.TUX.KGCRQ01
*QUEUE
LQMID=QMTESX01
MQNAME=QAT.Q.NACAR.TO.TUX.KGCPQ01
*QUEUE
LQMID=QMTESX01
MQNAME=QAT.Q.NACAR.TO.TUX.KPSAQ01
*QUEUE
LQMID=QMTESX01
MQNAME=QAT.Q.NACAR.TO.TUX.KPINQ01
*QUEUE
LQMID=QMTESX01
MQNAME=QAT.Q.NACAR.TO.TUX.KDECQ01
Thanks in advance,
Marling

Tuxedo 10gR3 installation issue on Windows XP

Hi,
Am trying to install tuxedo 10gR3(server) on Windows XP Professional. When I try to select C:\Oracle as ORACLE_HOME, it gives an error "Path should be absolute and have write Permissions!" and wont proceed further. I had to cancel the installation. I can confirm that C:\Oracle exist and is not read only. We have oracle database installed at C:\Oracle\<sub-folders>. The installation log was not of much help. These are contents of install log: -
======================
Thu May 28 02:22:14 PDT 2009
Free Memory: 6301 kB
Total Memory: 16320 kB
java.class.path:
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\InstallerData\IAClasses.zip
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\resource\jdglue.zip
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\InstallerData\Execute.zip
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\InstallerData\Execute.zip
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\InstallerData\Resource1.zip
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\InstallerData\Resource1.zip
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\InstallerData
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\InstallerData
ZGUtil.CLASS_PATH:
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\InstallerData\IAClasses.zip
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\resource\jdglue.zip
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\InstallerData\Execute.zip
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\InstallerData
sun.boot.class.path:
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\resource\jre\lib\rt.jar
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\resource\jre\lib\i18n.jar
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\resource\jre\lib\sunrsasign.jar
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\resource\jre\lib\jsse.jar
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\resource\jre\lib\jce.jar
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\resource\jre\lib\charsets.jar
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\resource\jre\classes
java.ext.dirs:
C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\resource\jre\lib\ext
java.version == 1.5.0_08 (Java 2+)
java.vm.name == Java HotSpot(TM) Client VM
java.vm.vendor == Sun Microsystems Inc.
java.vm.version == 1.5.0_08-b03
java.vm.specification.name == Java Virtual Machine Specification
java.vm.specification.vendor == Sun Microsystems Inc.
java.vm.specification.version == 1.0
java.specification.name == Java Platform API Specification
java.specification.vendor == Sun Microsystems Inc.
java.specification.version == 1.5
java.vendor == Sun Microsystems Inc.
java.vendor.url == http://java.sun.com/
java.class.version == 49.0
java.compiler == null
java.home == C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows\resource\jre
java.io.tmpdir == C:\DOCUME~1\pkarthic\LOCALS~1\Temp\
os.name == Windows XP
os.arch == x86
os.version == 5.1
path.separator == ;
file.separator == \
file.encoding == Cp1252
user.name == pkarthic
user.home == C:\Documents and Settings\pkarthic
user.dir == C:\Documents and Settings\pkarthic\Local Settings\Temp\I1243502280\Windows
user.language == en
user.region == null
Install Begin: Thu May 28 02:18:49 PDT 2009
Install End: Thu May 28 02:18:53 PDT 2009
Installed by InstallAnywhere 8.0 Enterprise Build 3063, by Macrovision
INSTALLATION WAS CANCELLED BY USER DURING PRE-INSTALLATION
User Interactions
Summary
Installation: Cancelledduring pre-install.
31 Successes
0 Warnings
0 NonFatalErrors
0 FatalErrors
Action Notes:
None
Install Log Detail:
Custom Action: com.bea.installer.InstallerInit
Status: SUCCESSFUL
Install Action: InstallAnywhere Variable
Status: SUCCESSFUL
Install Action: InstallAnywhere Variable
Status: SUCCESSFUL
Install Action: InstallAnywhere Variable
Status: SUCCESSFUL
Install Action: InstallAnywhere Variable
Status: SUCCESSFUL
Install Action: InstallAnywhere Variable
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\Oracle
Value Name: BEAHOMELIST
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\TUXEDO\Release 6.1
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\TUXEDO\Release 6.2
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\TUXEDO\6.3
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\TUXEDO\6.4
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\TUXEDO\6.5
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\TUXEDO\7.1
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\TUXEDO\8
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\TUXEDO\8.1
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\TUXEDO\9.0
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\TUXEDO\
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\TUXEDO\10.0
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\M3\2.1
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\M3\2.2
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\WebLogic Enterprise (C++)\4.2
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\WebLogic Enterprise\5.0
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\WebLogic Enterprise\5.0.1
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\BEA Systems\WebLogic Enterprise\5.1
Value Name: Company_Name
Status: SUCCESSFUL
Custom Action: com.bea.installer.CheckPrevVersions
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\TUXEDO\10.3.0.0_VS2005
Value Name: Company_Name
Status: SUCCESSFUL
Get Registry Entry: Key: HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\TUXEDO\10.3.0.0_VS2005\Environment
Value Name: TUXDIR
Status: SUCCESSFUL
Install Action: InstallAnywhere Variable
Status: SUCCESSFUL
Custom Action: com.bea.installer.CheckContinue
Status: SUCCESSFUL
Install Action: InstallAnywhere Variable
Status: SUCCESSFUL
Custom Action: com.bea.installer.CheckInstallMode
Status: SUCCESSFUL
INSTALLATION WAS CANCELLED BY USER DURING PRE-INSTALLATION
======================
Can you help me with debug switches(or command line options) that can be used with the installer.
Thanks,
Prem

Prem,
In addition to the C:\Oracle directory, the C:\Oracle\tuxedo10gR3_VS2005 directory also must either not exist or be a writable directory. If C:\Oracle\tuxedo10gR3_VS2005 previously exists as an ordinary file or as a read-only directory then you will get the "Path should be absolute and have write Permissions!" erorr.
If you type "C:\Oracle" manually into the installer you must be sure not to enter any leading spaces. (This will not be an issue if you use the "browse" functionality to select this directory.
You may also want to investigate if you get the same error if you try to install in Tuxedo in a directory that has not previously been used as an ORACLE_HOME and you should ensure that there is sufficent disk space on the C: drive. (These problems shouldn't cause the error your seeing, but it is worthwhile eliminating these as possible causes.)
If these suggestions don't resolve the problem, then you'll probably need to enter a support case to determine what is different between your environment and the environment of other customers whose intallations have been successful.
Regards,
Ed

Registry Key Issue of Installing Tuxedo 10gR3

Folks,
Hello. I am installing Tuxedo 10gR3 for PeopleTools 8.50 and the following message comes up:
"Warning! Detected installation of Oracle Software, tuxedo 9.1 on this machine. It is recomended that you exit installation and remove tuxedo 9.1".
I ignore the "Warning" and continue to install Tuxedo 10gR3 in the Wizard, the following message comes up:
"The value of -TUXDIR- is not set. Registry key -\10.3.0.0_VS2005\Enviroment\TUXDIR- is empty. You must cancel this installation. If you do not, the installer will continue to run but tuxeo 10gr3 with vs2005 will not be installed"
I click "CANCEL" button to exit install.
I have found "Registry Key - \10.3.0.0_VS2005\Enviroment" by running Start>Run>regedit>RegistryEditor>HKEY_LOCAL_MACHINE>Software>Oracle>Tuxedo>10.3.0.0_VS2005>Environment
There is no "TUXDIR" under "Environmnet". There are 2 fields inside it - Value Name and Value Data. The 2 files have no value. I think the issue is caused at this point.
How to solve the issue ?

This sounds similar to another issue raised on OTN. Have you uninstalled Tuxedo 9.1 completely?
You may need to delete the entire registry key for to tuxedo 10gR3 (from the top) through regedit and try again.

Memory leak issue in tuxedo server

Hi,
I am facing memory issues in our tuxedo application.One of the server memory utilization is gradually increasing after reboot. As a temporary solution , we are making restart of that particular server every week.
I have installed Valgrind tool.i am trying to call the service ( Around 800 services are part of application ) which i suspect causing memory leak through ud script. like below.
valgrind ud32 < servicename.ud
but it is not giving memory leak details in actual service instead it is giving details about ud.
Could you guys suggest how can we find memory leak in tuxedo services.
Thanks
Ramana

HI Sir,
Thanks a lot for your response.
I ran the comand as mentioned by you in your post. but i haven't shutdown the server bcoz it is prod environment.
It logged huge output to the log file.
Below is the summary of the logfile.
==00:00:00:05.383 23666== LEAK SUMMARY:
==00:00:00:05.383 23666== definitely lost: 7,105 bytes in 7 blocks
==00:00:00:05.383 23666== indirectly lost: 3,383 bytes in 18 blocks
==00:00:00:05.383 23666== possibly lost: 28,653 bytes in 9 blocks
==00:00:00:05.383 23666== still reachable: 529,286 bytes in 288 blocks
==00:00:00:05.383 23666== suppressed: 0 bytes in 0 blocks
==00:00:00:05.383 23666==
==00:00:00:05.383 23666== For counts of detected and suppressed errors, rerun with: -v
==00:00:00:05.383 23666== Use --track-origins=yes to see where uninitialised values come from
==00:00:00:05.383 23666== ERROR SUMMARY: 107 errors from 72 contexts (suppressed: 10 from 10)
But I am not able to understand the output logfile. Could you please let me know how can we analyze the logfile.
Thanks in advance.

Tuxedo Memory Leak Issue (Tuxedo 8.1 - Windows Server 2003)

Hi
We are running tuxedo 8.1, 32 bit with patch level 258 in our windows server 2003 based production environment. We are currently facing an issue where the memory usage of machine slowly keeps on going higher and higher eventually resulting in “Memory Allocation Failure” to tuxedo servers. We then have to do a complete restart of tuxedo which stabilizes the system for other few days.
We have been analyzing the our source code in development/test environment using different tools like a customized Alzheimer tool and IBM purify but both tools reported no memory leaks. We then developed a test tuxedo server exposing a tuxedo service which simply allocates a memory to a response buffer and then returns the response buffer. I then configured tuxedo queue with same name “MEMTEST3” and configured a TMQForward server to call this “MEMTEST3” service every time a message is en-queued to the MEMTEST3 queue.
unsigned long _LIBENTRY ulTPAlloc(FBFR32 **ppc, long size)
unsigned long ulRes = MSG_SUCCESS_c;
ppc = (FBFR32 ) tpalloc("FML32", (char *) 0, size);
if (*ppc == (FBFR32 *) 0) {
vLogMessage(hGetLogHandle(), MSG_MEM_ALLOC_ERR_c, (char *) 0, (Event_t *) 0,
BM_NOSUPPRESS_c, size);
ulRes = MSG_MEM_ALLOC_ERR_c;
return (ulRes);
/*==============================================================================
Service MEMTEST2
==============================================================================*/
void MEMTEST3(TPSVCINFO *pRequest)
FBFR32 *pFmlResponse = NULL;
FBFR32 *pFml = NULL;
unsigned long ulRes = MSG_SUCCESS_c;
unsigned long ulActionCode = 0;
int iExitValue = 0;
long lTpurcode = 0;
FBFR32 *pFmlNULL = NULL;
userlog("Starting MEMTEST3 service.");
if (pRequest == NULL || pRequest->data == NULL)
vLogMessage(hGetLogHandle(), MSG_API_ARGS_ERR_c, NULL, NULL, BM_NOSUPPRESS_c);
ulRes = MSG_API_ARGS_ERR_c;
else
pFml = (FBFR32 *) pRequest->data;
userlog("MEMTEST3: GET THE MEM");
ulRes = ulTPAlloc(&pFmlResponse, 1024);
userlog("Ending MEMTEST3 service.");
tpreturn( iExitValue, lTpurcode, ( char * ) pFmlResponse , 0L, 0L );
While I was en-queuing the messages to the queue, I kept on monitoring the memory usage of the server hosting the service. What I observed was that I saw an initial hike in the usage of memory of the server followed by small jumps in memory increase. I kept on monitoring the server for a long time and the memory was never returned. What I suspect is that there is memory leak in tuxedo TMQforward process as it never released the memory allocated in the service.
Can anyone help how this situation can be avoided ?
Kind Regards,
Asim

Hi Todd,
Also as well as my previous question, I also found your reply to another user posting something similar at Re: Memory leaks in Tuxedo libraries
You mention that:
In general Tuxedo will free anything it allocates, although there are cases where memory is allocated and not freed because:
+1) it is one time or a fixed number of times allocations that will not continue to grow, and freeing up the memory just before exiting isn't of any benefit.+
+2) the memory is under Tuxedo's memory management functions where we manage our own look aside lists to provide better buffer allocation performance and again freeing these before process termination is of little benefit.+
Our code does only issue TPALLOC once and then a TPRETURN - could point (1) of your comment above also be something of concern to us, where we would observe a continuous growth of memory usage?
I know it may sound like a stupid question but do we need to run our code 20,000 times before memory gets freed?
Kind Regards,
Asim

Unable to buildclient and to buildserver on windows 2000 and Tuxedo 8

Hi,
I am still trying to make the simpapp sample run on my laptop (windows 2000) and
I still don't manage to do so.
Currently, I am trying to compile with the tuxedo tools (buildclient and buildserver)
and this doesn't work at all.
It seems that a library is missing.
buildserver -o simpserv -f simpserv.c -s TOUPPER
cl /MD -I"%TUXDIR%"\include -Fesimpserv BS-388.c simpserv.c
"%TUXDIR%"\lib\libtux.lib "%TUXDIR%"\lib\libbuft.lib
"%TUXDIR%"\lib\libfml.lib "%TUXDIR%"\lib\libfml32.lib
"%TUXDIR%"\lib\libengine.lib wsock32.lib kernel32.lib advapi32.lib
user32.lib gdi32.lib comdlg32.lib winspool.lib -link -implib:BS-388.lib
CMDTUX_CAT:4180: ERROR: can't execute cl /MD
-I"%TUXDIR%"\include -Fesimpserv
BS-388.c simpserv.c
"%TUXDIR%"\lib\libtux.lib
"%TUXDIR%"\lib\libbuft.lib
"%TUXDIR%"\lib\libfml.lib
"%TUXDIR%"\lib\libfml32.lib
"%TUXDIR%"\lib\libengine.lib
wsock32.lib kernel32.lib advapi32.lib user32.lib gdi32.lib comdlg32.lib
winspool.lib
-link -implib:BS-388.lib
What is this 'cl' command which is alwasys called in the buildserver and buildclient
Thanx in advance for your help.
Best Regards
Jean-Guillaume LALANNE

never mind...
Posts from other threads in this group suggested using VC++'s vcvars.bat for setup.
That solves the stdio problem, buildclient now works for me.
"Rod" <[email protected]> wrote:
>
Same platform, also unable to buildclient. I put VC++ bin and Common/MSDev98/Bin
(to eliminate a complaint about MSPDB60.dll)in my path, but buildclient
replies with:
simpcl.c(13) : fatal error C1083: Cannot open include file: 'stdio.h': No
such file
or directory
I tried setting CFLAGS="-Ic:\Program Files\Microsoft Visual Studio\...",
and discovered
that buildclient apparently can't handle directory names with spaces. Different
variations of quoting, with single and double quotes in various positions,
evenutally
got rid of the
Command line warning D4024 : unrecognized source file type 'Files\Microsoft',
object
file assumed
warnings, but it still can't find stdio.h:
TUXNT_CAT:77: ERROR: Can't execute cl /MD -I"c:\Program Files\Microsoft
Visual Studio\VC89\Include"
-I"%TUXDIR%"\include -Fesimpcl simpcl.c "%TUXDIR%"\lib\libtux.lib "%TUXDIR%"\lib\libbuft.lib
"%TUXDIR%"\lib\libfml.lib "%TUXDIR%"\lib\libfml32.lib "%TUXDIR%"\lib\libengine.lib
wsock32.lib kernel32.lib advapi32.lib
user32.lib gdi32.lib comdlg32.lib winspool.lib -link -implib:BC-75c.lib
I was able to compile the client from inside VC++ and make an executable,
but the
server executable needs an atmi main.
So, I'm still stuck without an stdio.h....
Scott Orshan <[email protected]> wrote:
That's the C compiler (Microsoft Visual C++). To develop applications,
you need a compiler. Make sure that it is in your PATH.
jeangui wrote:
Hi,
I am still trying to make the simpapp sample run on my laptop (windows2000) and
I still don't manage to do so.
Currently, I am trying to compile with the tuxedo tools (buildclient
and
buildserver)
and this doesn't work at all.
It seems that a library is missing.
buildserver -o simpserv -f simpserv.c -s TOUPPER
cl /MD -I"%TUXDIR%"\include -Fesimpserv BS-388.c simpserv.c
"%TUXDIR%"\lib\libtux.lib "%TUXDIR%"\lib\libbuft.lib
"%TUXDIR%"\lib\libfml.lib "%TUXDIR%"\lib\libfml32.lib
"%TUXDIR%"\lib\libengine.lib wsock32.lib kernel32.lib advapi32.lib
user32.lib gdi32.lib comdlg32.lib winspool.lib -link -implib:BS-388.lib
CMDTUX_CAT:4180: ERROR: can't execute cl /MD
-I"%TUXDIR%"\include -Fesimpserv
BS-388.c simpserv.c
"%TUXDIR%"\lib\libtux.lib
"%TUXDIR%"\lib\libbuft.lib
"%TUXDIR%"\lib\libfml.lib
"%TUXDIR%"\lib\libfml32.lib
"%TUXDIR%"\lib\libengine.lib
wsock32.lib kernel32.lib advapi32.lib user32.lib gdi32.lib comdlg32.lib
winspool.lib
-link -implib:BS-388.lib
What is this 'cl' command which is alwasys called in the buildserver
and
buildclient
Thanx in advance for your help.
Best Regards
Jean-Guillaume LALANNE

Tuxedo 10gR3 installation issue

hello
I'm trying to build my own demo database, but I'm stuck at the Tuxedo installation.
The file I download says that it is 64bit and x86
filename: tuxedo10gR3_64_Linux_01_x86.bin (downloaded from HR9.1 media pack)
It extracts fine to /tmp, but the it won't install. When I run:
file ./Linux/resource/jre/bin/java the output shows that is an ELF 64-bit LSB
I've been trying to find 10gR3_32 but I was not able to find this.
I did find version 11 for 32, and this one installs fine, but apparently is not supported with 8.50.
Anyone an idea how to proceed. Second question is, are these rolling patches required for a Demo install? I don't have access to oracle support, so I'm unable to down the files needed.
Many thanks for your help

hi, many thanks for your quick responds.
That is the file I did download. I wonder I need to specify that my system runs 32bit and not 64bit. I've capture the output of the install (see below). Do you know if the patch is required to be installed to run tuxedo for my personal installation?
+[pdaalder@pt850 bin]$ sudo -i+
+[sudo] password for pdaalder:+
+[root@pt850 ~]# su - tuxedo+
+[tuxedo@pt850 ~]$ pwd+
+/opt/tuxedo+
+[tuxedo@pt850 ~]$ ls+
bea tuxedo10gR3_64_Linux_01_x86.bin
+[tuxedo@pt850 ~]$ sh tuxedo10gR3_64_Linux_01_x86.bin+
Preparing to install...
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
Launching installer...
tuxedo10gR3_64_Linux_01_x86.bin: line 2479: /tmp/install.dir.3062/Linux/resource/jre/bin/java: cannot execute binary file
tuxedo10gR3_64_Linux_01_x86.bin: line 2479: /tmp/install.dir.3062/Linux/resource/jre/bin/java: Success
+[tuxedo@pt850 ~]$ cd /tmp+
+[tuxedo@pt850 tmp]$ ls -lrt+
+...+
drwxrwxr-x 4 tuxedo tuxedo 4096 Nov 22 17:55 install.dir.3062
-rw-rw-r-- 1 tuxedo tuxedo 4003 Nov 22 17:55 env.properties.3062
+[tuxedo@pt850 tmp]$ more env.properties.3062+
lax.nl.env.exact_case.AWKPATH=.:/usr/share/awk
lax.nl.env.awkpath=.:/usr/share/awk
lax.nl.env.AWKPATH=.:/usr/share/awk
lax.nl.env.exact_case.OLDPWD=/tmp/install.dir.3062/Linux/resource
lax.nl.env.oldpwd=/tmp/install.dir.3062/Linux/resource
lax.nl.env.OLDPWD=/tmp/install.dir.3062/Linux/resource
lax.nl.env.exact_case.SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
lax.nl.env.ssh_askpass=/usr/libexec/openssh/gnome-ssh-askpass
lax.nl.env.SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
lax.nl.env.exact_case.LANG=C
lax.nl.env.lang=C
lax.nl.env.LANG=C
lax.nl.env.exact_case.HISTSIZE=1000
lax.nl.env.histsize=1000
lax.nl.env.HISTSIZE=1000
lax.nl.env.exact_case.USER=tuxedo
lax.nl.env.user=tuxedo
lax.nl.env.USER=tuxedo
lax.nl.env.exact_case._=/bin/awk
lax.nl.env._=/bin/awk
lax.nl.env._=/bin/awk
lax.nl.env.exact_case.TERM=xterm
lax.nl.env.term=xterm
lax.nl.env.TERM=xterm
lax.nl.env.exact_case.SHELL=/bin/bash
lax.nl.env.shell=/bin/bash
lax.nl.env.SHELL=/bin/bash
lax.nl.env.exact_case.G_BROKEN_FILENAMES=1
lax.nl.env.g_broken_filenames=1
lax.nl.env.G_BROKEN_FILENAMES=1
lax.nl.env.exact_case.DISPLAY=:0.0
lax.nl.env.display=:0.0
lax.nl.env.DISPLAY=:0.0
lax.nl.env.exact_case.INPUTRC=/etc/inputrc
lax.nl.env.inputrc=/etc/inputrc
lax.nl.env.INPUTRC=/etc/inputrc
lax.nl.env.exact_case.LESSOPEN=|/usr/bin/lesspipe.sh %s
lax.nl.env.lessopen=|/usr/bin/lesspipe.sh %s
lax.nl.env.LESSOPEN=|/usr/bin/lesspipe.sh %s
lax.nl.env.exact_case.MAIL=/var/spool/mail/tuxedo
lax.nl.env.mail=/var/spool/mail/tuxedo
lax.nl.env.MAIL=/var/spool/mail/tuxedo
lax.nl.env.exact_case.PATH=/usr/xpg4/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/
usr/bin:/opt/tuxedo/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin
lax.nl.env.path=/usr/xpg4/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/op
t/tuxedo/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin
lax.nl.env.exact_case.HOSTNAME=pt850
lax.nl.env.hostname=pt850
lax.nl.env.HOSTNAME=pt850
lax.nl.env.exact_case.HOME=/opt/tuxedo
lax.nl.env.home=/opt/tuxedo
lax.nl.env.HOME=/opt/tuxedo
lax.nl.env.exact_case.PWD=/opt/tuxedo
lax.nl.env.pwd=/opt/tuxedo
lax.nl.env.PWD=/opt/tuxedo
lax.nl.env.exact_case.LOGNAME=tuxedo
lax.nl.env.logname=tuxedo
lax.nl.env.LOGNAME=tuxedo
lax.nl.env.exact_case.SHLVL=2
lax.nl.env.shlvl=2
lax.nl.env.SHLVL=2
lax.nl.env.exact_case.LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:
bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe
+=00;32:*.com=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.+
tgz=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.
gz=00;31:*.bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:
*.gif=00;35:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:
lax.nl.env.ls_colors=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01
+:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.co+
m=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*
+.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.+
bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35
+:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:+
lax.nl.env.LS_COLORS=no=00:fi=00:di=00;34:ln=00;36:pi=40;33:so=00;35:bd=40;33;01
+:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=00;32:*.cmd=00;32:*.exe=00;32:*.co+
m=00;32:*.btm=00;32:*.bat=00;32:*.sh=00;32:*.csh=00;32:*.tar=00;31:*.tgz=00;31:*
+.arj=00;31:*.taz=00;31:*.lzh=00;31:*.zip=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.+
bz2=00;31:*.bz=00;31:*.tz=00;31:*.rpm=00;31:*.cpio=00;31:*.jpg=00;35:*.gif=00;35
+:*.bmp=00;35:*.xbm=00;35:*.xpm=00;35:*.png=00;35:*.tif=00;35:+
lax.nl.env.exact_case.POSIXLY_CORRECT=1
lax.nl.env.posixly_correct=1
lax.nl.env.POSIXLY_CORRECT=1
lax.stderr.redirect=
lax.stdout.redirect=
lax.nl.current.vm=/tmp/install.dir.3062/Linux/resource/jre/bin/java
+[tuxedo@pt850 tmp]$ cd install.dir.3062/Linux/resource/jre/bin+
+[tuxedo@pt850 bin]$ file java+
java: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), for GNU/Linux 2.4.0, stripped
+[tuxedo@pt850 bin]$ uname -a+
Linux pt850 2.6.18-194.el5 #1 SMP Mon Mar 29 20:06:41 EDT 2010 i686 i686 i386 GNU/Linux

Tuxedo Migration - Memory issues

Dear All,
We recently migrated our application as below
Old Environment:
32 bit Tuxedo 8.1 on HPUX, Patch Level 371
New Environment:
64 bit Tuxedo 11.1.1.3.0 on Linux, Patch Level 006
After this migration our C++ Corba servers are leaking memory at a high rate. Please see below the Valgrind report for one Corba server. I have taken only the "definitely lost" cases which were reported by Valgrind. Please suggest some solution to resolve these errors from Valgrind
==16216== Memcheck, a memory error detector
==16216== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==16216== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==16216== Command: User -C dom=BET1 -g 100 -i 80 -u ebkg-t -U /app/ebkg/log/ulogs/ebkgt1_ULOG -m 0 -A -P -e ./../log/trc/UserServer.trc -o ../../log/trc/SYS_ERROR_LOG
==16216==
--16216-- WARNING: Serious error when reading debug info
--16216-- When reading debug info from /app/ebkg/BE/lib/libicudata.so.44:
--16216-- Can't make sense of .data section mapping
==16216== 32 bytes in 1 blocks are definitely lost in loss record 256 of 563
==16216== at 0x4A0679C: operator new(unsigned long, std::nothrow_t const&) (vg_replace_malloc.c:329)
==16216== by 0x66ED951: DListPtr::GetNode() (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66ED9DA: DListPtr::InsertBefore(void*, DListPtrNode*) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66EDABA: DListPtr::InsertTail(void*) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x670B09B: ORBImpl::RegisterThreadExit(ThreadExitInterest*) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x6385FBD: Current_Impl::Current_Impl(ORBImpl*) (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x639570E: Tobj_BootstrapImpl::Tobj_BootstrapImpl(CORBA::ORB*, char const*) (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x63958AD: BEA_create_Tobj_Bootstrap (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x5EACB68: Tobj_Bootstrap::Tobj_Bootstrap(CORBA::ORB*, char const*) (in /app/mw/tuxedo11gR1.06/lib/libenv.so)
==16216== by 0x639232D: OrbMain::startup(int, char**) (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x6392E72: server_init(int, char**) (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x797989: tpsvrinit (in /app/ebkg/BE/bin/User)
==16216==
==16216== 119 (96 direct, 23 indirect) bytes in 1 blocks are definitely lost in loss record 331 of 563
==16216== at 0x4A0679C: operator new(unsigned long, std::nothrow_t const&) (vg_replace_malloc.c:329)
==16216== by 0x66D05CB: CORBA::ORB_init(int&, char**, char const*) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x639223A: OrbMain::startup(int, char**) (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x6392E72: server_init(int, char**) (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x797989: tpsvrinit (in /app/ebkg/BE/bin/User)
==16216== by 0x7452D99: _tmmain (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x743AF35: _tmstartserver (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x4098BE: main (in /app/ebkg/BE/bin/User)
==16216==
==16216== 161 (160 direct, 1 indirect) bytes in 1 blocks are definitely lost in loss record 352 of 563
==16216== at 0x4A0568B: calloc (vg_replace_malloc.c:593)
==16216== by 0x74BE9C3: atnlcl_gss_acquire_cred (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0xA83AB8A: esec_gss_acquire_cred_ex (in /app/mw/tuxedo11gR1.06/lib/libengine.so)
==16216== by 0x74250E1: tmself_authenticate_ex (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x74B71EF: tmenrollpki (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x744E620: _tmenrollsvr (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x7452265: _tmstdinit (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x74528B1: _tmmain (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x743AF35: _tmstartserver (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x4098BE: main (in /app/ebkg/BE/bin/User)
==16216==
==16216== 280 (152 direct, 128 indirect) bytes in 1 blocks are definitely lost in loss record 417 of 563
==16216== at 0x4A0679C: operator new(unsigned long, std::nothrow_t const&) (vg_replace_malloc.c:329)
==16216== by 0x66EC507: IOPInstrumentHolder::IOPInstrumentHolder() (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66E8767: IOPRoot::GetIOPInstrumentHolder() (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66E88C8: IOPRoot::GetIOPTraceStream() (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x6713DE3: ORBImpl::ORBImpl(unsigned int, int, char**, ErrorInfo&) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66D0396: CORBA::ORB_init(int&, char**, char const*) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x639223A: OrbMain::startup(int, char**) (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x6392E72: server_init(int, char**) (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x797989: tpsvrinit (in /app/ebkg/BE/bin/User)
==16216== by 0x7452D99: _tmmain (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x743AF35: _tmstartserver (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x4098BE: main (in /app/ebkg/BE/bin/User)
==16216==
==16216== 1,836 (160 direct, 1,676 indirect) bytes in 1 blocks are definitely lost in loss record 489 of 563
==16216== at 0x4A0679C: operator new(unsigned long, std::nothrow_t const&) (vg_replace_malloc.c:329)
==16216== by 0x6ACF318: POAImpl::GetRootPOA(ORBImpl*, OAManager**, ErrorInfo&, char) (in /app/mw/tuxedo11gR1.06/lib/liborbpoa.so)
==16216== by 0x6AC2CBD: OBB__CreateRootPOA (in /app/mw/tuxedo11gR1.06/lib/liborbpoa.so)
==16216== by 0x670CA5D: ORBImpl::GetRootPOA(ErrorInfo&) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x670DBF7: ORBImpl::resolve_initial_references(char const*) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x639245F: OrbMain::startup(int, char**) (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x6392E72: server_init(int, char**) (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x797989: tpsvrinit (in /app/ebkg/BE/bin/User)
==16216== by 0x7452D99: _tmmain (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x743AF35: _tmstartserver (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x4098BE: main (in /app/ebkg/BE/bin/User)
==16216==
==16216== 3,876 (412 direct, 3,464 indirect) bytes in 1 blocks are definitely lost in loss record 502 of 563
==16216== at 0x4A0568B: calloc (vg_replace_malloc.c:593)
==16216== by 0xA7F2149: emem_balloc (in /app/mw/tuxedo11gR1.06/lib/libengine.so)
==16216== by 0x746E59A: tmfmsgaddtcm (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x7402935: tpallocinternal (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x741942A: _tmmsgrcv (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x745F567: _tmrcvrq (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x746453D: _tmrunserver (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x743AFFB: _tmstartserver (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x4098BE: main (in /app/ebkg/BE/bin/User)
==16216==
==16216== 3,876 (412 direct, 3,464 indirect) bytes in 1 blocks are definitely lost in loss record 503 of 563
==16216== at 0x4A0568B: calloc (vg_replace_malloc.c:593)
==16216== by 0xA7F2149: emem_balloc (in /app/mw/tuxedo11gR1.06/lib/libengine.so)
==16216== by 0x746E59A: tmfmsgaddtcm (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x7402935: tpallocinternal (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x7402BFB: tpalloc (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x7468719: tpenqueueinternal (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x7468E34: tpenqueue (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x4BC2EF: Login_i::login(char const*, double, char const*, char, DataStructures::Customer_out) (User_inew.cpp:1697)
==16216== by 0x4C4DE0: POA_User::Login::invoke(CORBA::ServerRequest*) (User_snew.cpp:1014)
==16216== by 0x638C20E: ObjectStateManager::invoke(TPContext*) (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x63916AE: ObjectManager::invoke(CORBA::ServerRequest*) (in /app/mw/tuxedo11gR1.06/lib/libnative.so)
==16216== by 0x6ACB2B4: POAImpl::ProcessRequest(ServerRequestImpl*, ErrorInfo&) (in /app/mw/tuxedo11gR1.06/lib/liborbpoa.so)
==16216==
==16216== 34,594 (34,204 direct, 390 indirect) bytes in 1 blocks are definitely lost in loss record 549 of 563
==16216== at 0x4A06AF0: realloc (vg_replace_malloc.c:662)
==16216== by 0xA7F20F8: emem_balloc (in /app/mw/tuxedo11gR1.06/lib/libengine.so)
==16216== by 0x746D427: tmfmsgresizeutcm (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x74023F0: tprealloc (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0xCC2A028: TGIOPBuffer::Extend(unsigned int, ErrorInfo&) (in /app/mw/tuxedo11gR1.06/lib/liborbtgiop.so)
==16216== by 0x66BFD98: Coder::CheckBufferNoneLeft(unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66C180B: Encoder::AlignCheckChunk(unsigned int, unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66C1907: Encoder::EncodeOctetArray(unsigned int, unsigned char const*) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66C2F74: Encoder::EncodeString(char const*) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66DAA41: OBB::MarshalBuf::operator<<(char const*) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x43414F: operator<<(OBB::MarshalBuf&, DataStructures::StringList&) (DataStructures_cnew.cpp:161412)
==16216== by 0x45F3BC: operator<<(OBB::MarshalBuf&, DataStructures::User&) (DataStructures_cnew.cpp:171370)
==16216==
==16216== 94,384 (12,352 direct, 82,032 indirect) bytes in 44 blocks are definitely lost in loss record 553 of 563
==16216== at 0x4A0568B: calloc (vg_replace_malloc.c:593)
==16216== by 0xA7F2149: emem_balloc (in /app/mw/tuxedo11gR1.06/lib/libengine.so)
==16216== by 0x747BFBB: tmfmsgpostrecv (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x750C6A4: _tmmbrecvm2 (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x750BD7E: _tmmbrecvm (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x7419622: _tmmsgrcv (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x745F567: _tmrcvrq (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x746453D: _tmrunserver (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x743AFFB: _tmstartserver (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x4098BE: main (in /app/ebkg/BE/bin/User)
==16216==
==16216== 201,620 (25,132 direct, 176,488 indirect) bytes in 61 blocks are definitely lost in loss record 558 of 563
==16216== at 0x4A0568B: calloc (vg_replace_malloc.c:593)
==16216== by 0xA7F2149: emem_balloc (in /app/mw/tuxedo11gR1.06/lib/libengine.so)
==16216== by 0x746E59A: tmfmsgaddtcm (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x7402935: tpallocinternal (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x745EA4A: _tmrcvrq (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x746453D: _tmrunserver (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x743AFFB: _tmstartserver (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x4098BE: main (in /app/ebkg/BE/bin/User)
==16216==
==16216== 11,118,988 (10,727,184 direct, 391,804 indirect) bytes in 313 blocks are definitely lost in loss record 563 of 563
==16216== at 0x4A06AF0: realloc (vg_replace_malloc.c:662)
==16216== by 0xA7F20F8: emem_balloc (in /app/mw/tuxedo11gR1.06/lib/libengine.so)
==16216== by 0x746D427: tmfmsgresizeutcm (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0x74023F0: tprealloc (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==16216== by 0xCC2A028: TGIOPBuffer::Extend(unsigned int, ErrorInfo&) (in /app/mw/tuxedo11gR1.06/lib/liborbtgiop.so)
==16216== by 0x66BFD98: Coder::CheckBufferNoneLeft(unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66C0BF6: Coder::CheckBuffer(unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66C01EF: Coder::AlignAdvance(unsigned int, unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66C0C73: Coder::AlignInternal(unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66C0C94: Coder::Align(unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66C17EC: Encoder::AlignCheckChunk(unsigned int, unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216== by 0x66C0E0D: Encoder::EncodeLong(int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==16216==
==16216== LEAK SUMMARY:
==16216== definitely lost: 10,800,296 bytes in 426 blocks
==16216== indirectly lost: 659,470 bytes in 1,074 blocks
==16216== possibly lost: 906,419 bytes in 110 blocks
==16216== still reachable: 1,267,586 bytes in 689 blocks
==16216== suppressed: 0 bytes in 0 blocks
==16216==
==16216== For counts of detected and suppressed errors, rerun with: -v
==16216== ERROR SUMMARY: 3135 errors from 338 contexts (suppressed: 14 from 9)
Best Regards
Sunil

Hi Todd,
My last post was not correct.
The size of the leaks reported is increasing after running the process for multiple times (~30 times)
==2707== LEAK SUMMARY:
==2707== definitely lost: 56,466,057 bytes in 2,078 blocks
==2707== indirectly lost: 2,731,420 bytes in 4,570 blocks
==2707== possibly lost: 1,366,271 bytes in 163 blocks
==2707== still reachable: 1,267,586 bytes in 689 blocks
==2707== suppressed: 0 bytes in 0 blocks
The most leak is reported in the liborb.so.
Are we passing an int to some library where it is expecting long ? Or does the EncodeLong method have some bug ?
==2707== 58,451,496 (56,377,440 direct, 2,074,056 indirect) bytes in 1,645 blocks are definitely lost in loss record 561 of 561
==2707== at 0x4A06AF0: realloc (vg_replace_malloc.c:662)
==2707== by 0xA7F20F8: emem_balloc (in /app/mw/tuxedo11gR1.06/lib/libengine.so)
==2707== by 0x746D427: tmfmsgresizeutcm (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==2707== by 0x74023F0: tprealloc (in /app/mw/tuxedo11gR1.06/lib/libtux.so)
==2707== by 0xCC2A028: TGIOPBuffer::Extend(unsigned int, ErrorInfo&) (in /app/mw/tuxedo11gR1.06/lib/liborbtgiop.so)
==2707== by 0x66BFD98: Coder::CheckBufferNoneLeft(unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==2707== by 0x66C0BF6: Coder::CheckBuffer(unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==2707== by 0x66C01EF: Coder::AlignAdvance(unsigned int, unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==2707== by 0x66C0C73: Coder::AlignInternal(unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==2707== by 0x66C0C94: Coder::Align(unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==2707== by 0x66C17EC: Encoder::AlignCheckChunk(unsigned int, unsigned int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
==2707== by 0x66C0E0D: Encoder::EncodeLong(int) (in /app/mw/tuxedo11gR1.06/lib/liborb.so)
Best Regards
Sunil

KEEP_STATE/Tuxedo buildserver issue

Similar Messages

Maybe you are looking for