Tpcall corrupt (core dump) for tuxedo 8.1 in solaris9
Dear All,
I'm develope the tuxedo client program on solaris9 (SunOS olympus 5.9 Generic_118558-06 sun4u sparc SUNW,Sun-Fire-880),tuxedo 8.1 and compiled under 32bits libraries. My application is a multithread program but a few concurrent transaction. It also runs correctly but some time it crash when the service performs a tpcall function.
The information from gdb is follow:-
(gdb) bt
#0 0xff2db0f0 in enet_send () from /export/home/tux/tuxedo8.1/lib/libgpnet.so.71
#1 0xff31b500 in wscnw_msgsnd () from /export/home/tux/tuxedo8.1/lib/libwsc.so.71
#2 0xff31fc80 in wscmsgsnd () from /export/home/tux/tuxedo8.1/lib/libwsc.so.71
#3 0xff315390 in tpcallinternal () from /export/home/tux/tuxedo8.1/lib/libwsc.so.71
#4 0xff314f3c in tpcall () from /export/home/tux/tuxedo8.1/lib/libwsc.so.71
#5 0x0001fa1c in chkPPPack (strMobileNo=0xfeb7be28 "072031554", strChannel=0xfeb7bf58 "IVR",
strPromoType=0x54bd8 "N", response=0xfeb7b978 "",
error=0xfeb7b780 "Info : Connect to Tuxido id=0/10 Success") at PPChkPack.h:213
#6 0x0002cd64 in CallThread (sd=0x16bc40) at PPPromotionIVR.c:99
#7 0xff2157bc in lwpstart () from /usr/lib/lwp/libthread.so.1
#8 0xff2157bc in lwpstart () from /usr/lib/lwp/libthread.so.1
Previous frame identical to this frame (corrupt stack?)
(gdb) up
#1 0xff31b500 in wscnw_msgsnd () from /export/home/tux/tuxedo8.1/lib/libwsc.so.71
(gdb) up
#2 0xff31fc80 in wscmsgsnd () from /export/home/tux/tuxedo8.1/lib/libwsc.so.71
(gdb) up
#3 0xff315390 in tpcallinternal () from /export/home/tux/tuxedo8.1/lib/libwsc.so.71
(gdb) up
#4 0xff314f3c in tpcall () from /export/home/tux/tuxedo8.1/lib/libwsc.so.71
(gdb) up
#5 0x0001fa1c in chkPPPack (strMobileNo=0xfeb7be28 "072031554", strChannel=0xfeb7bf58 "IVR",
strPromoType=0x54bd8 "N", response=0xfeb7b978 "",
error=0xfeb7b780 "Info : Connect to Tuxido id=0/10 Success") at PPChkPack.h:213
213 if (tpcall("A_ChkPPIVRPack", (char *)callbf1, 0, (char **)&callbf1, &callbf1_len, 0L) < 0)
(gdb) print callbf1
$1 = (FBFR32 *) 0x173a80
and the information from ULOG file is follow:-
112347.olympus!PPPromotionIVR09.9971.1179.7: 04-11-2006: Tuxedo Version 8.1, 32-bit
112347.olympus!PPPromotionIVR09.9971.1179.7: LIBWSC_CAT:1037: ERROR: Network message receive failure
112347.olympus!PPPromotionIVR09.9971.1179.7: LIBWSC_CAT:1013: ERROR: tpcall() get reply failed
Note. I already set TPMULTICONTEXTS in TPINIT flag before perform a tpinit.
Do you have any idea for solve this problem. thanks!
Sitthisak C.
Errors and crashes in multithreaded programs can be very hard to debug.
Sometimes a problem occurs every time a particular piced of code is
executed, and other times the problem is timing dependent. Sometimes the
problem is located in the module where the failure occurs, and other times
the problem is due to memory corruption in a different thread. You may want
to try executing your program with a memory analyzer such as Purify to see
if there are any references to unallocated memory that could be causing
corruption. Also, if you are not running a recent patch of 8.1, you may
want to upgrade to the latest patch to see if that fixes the problem.
(However, I don't know of any specific problems in this area for release
8.1.) If the above suggestions don't work, then you should open a support
case.
<sitthisak C.> wrote in message news:[email protected]...
Dear All,
I'm develope the tuxedo client program on solaris9 (SunOS olympus 5.9
Generic_118558-06 sun4u sparc SUNW,Sun-Fire-880),tuxedo 8.1 and compiled
under 32bits libraries. My application is a multithread program but a few
concurrent transaction. It also runs correctly but some time it crash when
the service performs a tpcall function.
The information from gdb is follow:-
(gdb) bt
#0 0xff2db0f0 in enet_send () from
/export/home/tux/tuxedo8.1/lib/libgpnet.so.71
#1 0xff31b500 in wscnw_msgsnd () from
/export/home/tux/tuxedo8.1/lib/libwsc.so.71
#2 0xff31fc80 in wscmsgsnd () from
/export/home/tux/tuxedo8.1/lib/libwsc.so.71
#3 0xff315390 in tpcallinternal () from
/export/home/tux/tuxedo8.1/lib/libwsc.so.71
#4 0xff314f3c in tpcall () from
/export/home/tux/tuxedo8.1/lib/libwsc.so.71
#5 0x0001fa1c in chkPPPack (strMobileNo=0xfeb7be28 "072031554",
strChannel=0xfeb7bf58 "IVR",
strPromoType=0x54bd8 "N", response=0xfeb7b978 "",
error=0xfeb7b780 "Info : Connect to Tuxido id=0/10 Success") at
PPChkPack.h:213
#6 0x0002cd64 in CallThread (sd=0x16bc40) at PPPromotionIVR.c:99
#7 0xff2157bc in lwpstart () from /usr/lib/lwp/libthread.so.1
#8 0xff2157bc in lwpstart () from /usr/lib/lwp/libthread.so.1
Previous frame identical to this frame (corrupt stack?)
(gdb) up
#1 0xff31b500 in wscnw_msgsnd () from
/export/home/tux/tuxedo8.1/lib/libwsc.so.71
(gdb) up
#2 0xff31fc80 in wscmsgsnd () from
/export/home/tux/tuxedo8.1/lib/libwsc.so.71
(gdb) up
#3 0xff315390 in tpcallinternal () from
/export/home/tux/tuxedo8.1/lib/libwsc.so.71
(gdb) up
#4 0xff314f3c in tpcall () from
/export/home/tux/tuxedo8.1/lib/libwsc.so.71
(gdb) up
#5 0x0001fa1c in chkPPPack (strMobileNo=0xfeb7be28 "072031554",
strChannel=0xfeb7bf58 "IVR",
strPromoType=0x54bd8 "N", response=0xfeb7b978 "",
error=0xfeb7b780 "Info : Connect to Tuxido id=0/10 Success") at
PPChkPack.h:213
213 if (tpcall("A_ChkPPIVRPack", (char *)callbf1, 0, (char
**)&callbf1, &callbf1_len, 0L) < 0)
(gdb) print callbf1
$1 = (FBFR32 *) 0x173a80
and the information from ULOG file is follow:-
112347.olympus!PPPromotionIVR09.9971.1179.7: 04-11-2006: Tuxedo Version
8.1, 32-bit
112347.olympus!PPPromotionIVR09.9971.1179.7: LIBWSC_CAT:1037: ERROR:
Network message receive failure
112347.olympus!PPPromotionIVR09.9971.1179.7: LIBWSC_CAT:1013: ERROR:
tpcall() get reply failed
Note. I already set TPMULTICONTEXTS in TPINIT flag before perform a
tpinit.
Do you have any idea for solve this problem. thanks!
Sitthisak C.
Similar Messages
-
Throws Core Dump for OCISessionBegin() on Linux for Oracle Client v10.2.0.2
hi,
The OCI method, OCISessionBegin() is throwing an core dump on 10g client in Linux on C++, but the same code works fine for 8i and 9i client. Core dumps for 10g Client. 10g tnsnames.ora file is same as of 9i. I just debeggued with the core and says failing in OCISessionBegin() method. I would like to know is there any problem with Oracle Client v10.2.0.2? or how does i can solve the issue? appriciate a quick help in this regard.
Thanks,
SreeniHave you looked in the Knowledge Base information at metalink? That would be the place to start.
If that does not work then the next step would be to remove this thread and post in the OCI - OCCI forum where there are people that can actually help you. -
How to turn off core dump for WebLogic 8.1 running on AIX 5.3
Hi there,
Is there a way we can turn off core dumping for WebLogic 8.1 running on AIX 5.3?
Thank you.
Regards,
SurenderHi Surender,
Please add the following Flag in the JAVA_OPTIONS of your servers StartScript like following :
JAVA_OPTIONS=${JAVA_OPTIONS} -Xdump:system:none
Thanks
Jay SenSharma
http://jaysensharma.wordpress.com/2009/12/30/jvm-crash-and-native-outofmemory/ (WebLogic Wonders Are Here) -
Sun ONE Web Server 6.1SP2 B04/07/2004 core dump enablement
What is the procedure to enable core dump for future analysis? Earlier versions code changes for magnus.conf does not seem to work!
What magnus.conf changes are you trying?
If its a non secure(no SSL) 6.1 web server running on solaris 8 or later the following coreadm settings should allow core dump creation:
# coreadm
global core file pattern:
init core file pattern: core.%p
global core dumps: disabled
per-process core dumps: enabled
global setid core dumps: disabled
per-process setid core dumps: enabled
global core dump logging: disabled
To set the coreadm options as shown above, refer to man pages of coreadm command.
Thanks
Manish -
Segmentation Fault (core dumped)
Hello.
Guys I got an issue.
I have a server running Solaris version 9.
When I execute a command and it returns the result I get this message:
Segmentation Fault (core dumped)
for example
df -h
gzip
I am also getting this messages when executing dmesg:
Nov 11 18:39:12 TRSTSQATREMDB01 genunix: [ID 603404 kern.notice] NOTICE: core_log: logger[8730] core dumped: /var/core/core_TR STSQATREMDB01_logger_0_0_1289518751_8730
Nov 11 18:49:35 TRSTSQATREMDB01 genunix: [ID 603404 kern.notice] NOTICE: core_log: logger[9922] core dumped: /var/core/core_TR STSQATREMDB01_logger_0_0_1289519375_9922
Why Am I getting this messages, is it time to reboot ?
Thanks for your help.It is a generic error message which is due to multiple reasons..
1) /tmp full.
2) Wrong Inventory locations.
3) Wrong Library
4) Broken softlinks.
etc.
We have faced one such issue recently.. Where the some softlinks under $ORACLE_HOME/oui/bin was broken.
Please do these basic checks.
Paste the command with error here if you are still facing issue.
Edited by: user768907 on Nov 20, 2010 8:11 AM -
Tuxedo8 core dumps when performing a tpcall in Solaris
Hi all,
I'm installing a Tuxedo application on a Solaris OS:
SunOS 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-280R
Tuxedo 8.0 compiled under 32bits libraries.
This application also runs correctly under a RedHat Linux 7.1 (kernel 2.4.9-31)
and on a Digital (OSF1 V4.0 878 alpha)
When running the application on Solaris, we always get a core dump when the service
performs a tpcall. Debugging the Tuxedo server we can see the core dump is produced
when the service gets de response from the tpcall, i.e: when the service called
performs the tpreturn.
Any clues will be appreciated, thanks!
Yol.Oh, thanks very much, what a stupid mistake! sorry :(
We knew about the cast, but after looking for the problem in many ways we didn't
realize FLDLEN was a short!
Thank you all for your quick help!
Yol.
Scott Orshan <[email protected]> wrote:
FLDLEN nLongitud is a short. Casting its pointer to a long * does not
change the
fact that the return value will overwrite other memory. On Linux, the
alignment or
arrangement of the stack was different, so it didn't core dump. You need
to pass
the address of a real long for the return length.
Scott Orshan
Yol. wrote:
Yes, that's what we thought at first sight, nevertheless remember itruns ok in
other OS.
Anyway here I give you 2 samples of code we've tried.
Any of this cases fail creating a core dump.
Case 1:
Src1 calls Src2:
Src1:
void SRC1(TPSVCINFO * BufferFml)
FLDLEN nLongitud;
FBFR *pBuffer;
pBuffer = (FBFR *) BufferFml->data;
if (tpcall("SRC2", (char *) pBuffer, 0, (char **) &pBuffer, (long*) &nLongitud,
0) == -1)
userlog("Error!!!!!!!!!!!!!!!!!");
tpreturn(TPSUCCESS, 0, (char *) pBuffer, 0L, 0);
Src2
void SRC2(TPSVCINFO * BufferFml)
FLDLEN nLongitud;
FBFR *pBuffer;
pBuffer = (FBFR *) BufferFml->data;
tpreturn(TPSUCCESS, 0, (char *) pBuffer, 0L, 0);
Case 2:
Src1 calls Src2:
Src1:
The same as in case 1
Src2:
void SRC2(TPSVCINFO * BufferFml)
tpreturn(TPSUCCESS, 0, NULL, 0L, 0);
Thanks anyway for your attention ;-)
Peter Holditch <[email protected]> wrote:
Yol,
My initial guess is that your code is not keeping track of the tpalloced
buffers correctly - in particular, the one that the reply is received
into.
If you post some code, maybe someone will see the error. Alternatively,
have you got purift or some other bounds checking software that might
help you track the problem?
Regards,
Peter.
Yol. wrote:
Hi all,
I'm installing a Tuxedo application on a Solaris OS:
SunOS 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-280R
Tuxedo 8.0 compiled under 32bits libraries.
This application also runs correctly under a RedHat Linux 7.1 (kernel2.4.9-31)
and on a Digital (OSF1 V4.0 878 alpha)
When running the application on Solaris, we always get a core dumpwhen the service
performs a tpcall. Debugging the Tuxedo server we can see the coredump is produced
when the service gets de response from the tpcall, i.e: when the servicecalled
performs the tpreturn.
Any clues will be appreciated, thanks!
Yol. -
Import command for one table core dumps
Hi,
The following import command is causing a core dump;
$ imp system/***** file=/upload/dbdumps/06-09-19_11.00.01-db.dmp fromuser=ioeadmin tables=(utils) 2>&1 |tee imp.log
But this one does not:
$ cat imp.params
FULL=y
FILE=/upload/dbdumps/06-09-19_11.00.01-db.dmp
GRANTS=y
INDEXES=y
$ imp system/*****@odinprd parfile=imp.params 2>&1 |tee imp.log
More info:
SunOS 5.8 / Oracle 8.1.5
Thank you for any help on thisI don't have access to Metalink. What would it say -- "imp tables=" doesn't work in 8i?
So I have tried the following:
1. drop the table I want to restore.
2. run this command to restore all tables and let it fail on those tables that already exist and recreate the one i dropped.
imp system/code4202@odinprd full=y show=y file=/upload/dbdumps/06-09-27_00.00.00-db.dmp 2>&1 |tee imp.log
But it doesn't. It says this about the table in question:
"ALTER SCHEMA = "IOEADMIN""
"CREATE TABLE "PARTNER" ("PARTNER_ID" VARCHAR2(16) NOT NULL ENABLE, "PARTNER"
"_TYPE" VARCHAR2(16), "ADDRESS_ID" NUMBER(10, 0), "PAYMENT_ID" NUMBER(10, 0)"
", "PRICE_LIST_ID" NUMBER(10, 0), "DEFAULT_CARRIER" VARCHAR2(32), "DEFAULT_M"
"ETHOD" VARCHAR2(32), "CARRIER_ACCOUNT_NUMBER" VARCHAR2(32), "BILLTYPE" VARC"
"HAR2(10), "TMB_TYPE" NUMBER) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255"
" LOGGING STORAGE(INITIAL 10240) TABLESPACE "APP_DATA""
. . skipping table "PARTNER"
why is it skip this guy? It does not exist:
SQL> desc partner;
ERROR:
ORA-04043: object partner does not exist
SQL> desc ioeadmin.partner;
ERROR:
ORA-04043: object ioeadmin.partner does not exist -
Control core dump behavior for executables matching a pattern
Systemd directs me to coredump.conf(5) for the gory details on configuring core dumps but even after reading that it's not clear to me if there's a way to have core dumps only generated for certain executables. Ideally, I'd like to pattern match the full path to an executable to determine whether or not a core dump should be generated.
Can this be done? How?Which database version are you working with....????
Some alternatives might work for example, xdbUriType
begin
DBMS_XMLSCHEMA.registerSchema(
schemaURL => 'http://www.myserver.com/myapp/1.0/xsd/xmlschema.xsd',
schemaDoc => xdbURIType('/home/myapp/1.0/xsd/xmlschema.xsd').getClob(),
local => FALSE, -- local
genTypes => TRUE, -- generate object types
genBean => FALSE, -- no java beans
genTables => TRUE -- generate object tables
end;
/ or bfilename
create or replace directory XMLDIR as '&XMLDIR/xsd'
-- alter session SET events = '31098 trace name context forever';
declare
V_FILENAME VARCHAR2(700) := 'xmlschema.xsd';
V_XMLSCHEMA XMLTYPE := xmltype(bfilename('XMLDIR',V_FILENAME),nls_charset_id('AL32UTF8'));
begin
dbms_xmlschema.registerSchema
schemaurl => V_FILENAME,
schemadoc => V_XMLSCHEMA.getClobVal(),
local => TRUE,
genTypes => TRUE,
genBean => FALSE,
genTables => TRUE,
enablehierarchy => DBMS_XMLSCHEMA.ENABLE_HIERARCHY_NONE,
owner => user
end;
/ -
Gateway for Sybase - core dump [npixfc()+243] [SIGSEGV]
Hi All,
We are using a couple of gateways to various Sybase servers in our environment, which generally work very fine.
However, occasionally we find the following lines in the alert.log on one or the other node of the cluster.
The DB platform is currently 11.2.0.1 in RAC on Linux x86-64 RHEL5, but similar problems happened
before on 11.1.0.7 (the entries in the logs were not as descriptive as on 11gR2).
Thu Feb 11 07:48:33 2010
HS: Lost RPC connection to remote Agent...
HS: ... Agent SID = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx043vip)(PORT=1521))(CONNECT_DATA=(SID=PM04PMDB))), NCR status = -2147385341
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x7FFF20B670B8] [PC:0x59BAADD, npixfc()+243] [flags: 0x0, count: 1]
Errors in file /oracle/app/diag/rdbms/xxx1/xxx11/trace/xxx11_ora_32050.trc (incident=16497):
ORA-07445: exception encountered: core dump [npixfc()+243] [SIGSEGV] [ADDR:0x7FFF20B670B8] [PC:0x59BAADD] [Address not mapped to object] []
ORA-28511: lost RPC connection to heterogeneous remote agent using SID=ORA-28511: lost RPC connection to heterogeneous remote agent using SID=(DESCRIPTION=(ADDRESS=(PR
OTOCOL=TCP)(HOST=xxx043vip)(PORT=1521))(CONNECT_DATA=(SID=PM04PMDB)))
ORA-02063: preceding line from PM04PMDB
Incident details in: /oracle/app/diag/rdbms/xxx1/xxx11/incident/incdir_16497/xxx11_ora_32050_i16497.trc
The .trc file starts with:
Dump file /oracle/app/diag/rdbms/xxx1/xxx11/incident/incdir_16497/xxx11_ora_32050_i16497.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/app/product/11.2.0/dbhome_1
System name: Linux
Node name: xxx043
Release: 2.6.18-128.el5
Version: #1 SMP Wed Dec 17 11:41:38 EST 2008
Machine: x86_64
Instance name: xxx11
Redo thread mounted by this instance: 1
Oracle process number: 62
Unix process pid: 32050, image: oracle@xxx043
*** 2010-02-11 07:48:33.186
*** SESSION ID:(695.7521) 2010-02-11 07:48:33.186
*** CLIENT ID:() 2010-02-11 07:48:33.186
*** SERVICE NAME:(xxx1) 2010-02-11 07:48:33.186
*** MODULE NAME:(JDBC Thin Client) 2010-02-11 07:48:33.186
*** ACTION NAME:() 2010-02-11 07:48:33.186
Dump continued from file: /oracle/app/diag/rdbms/xxx1/xxx11/trace/xxx11_ora_32050.trc
ORA-07445: exception encountered: core dump [npixfc()+243] [SIGSEGV] [ADDR:0x7FFF20B670B8] [PC:0x59BAADD] [Address not mapped to object] []
ORA-28511: lost RPC connection to heterogeneous remote agent using SID=ORA-28511: lost RPC connection to heterogeneo
========= Dump for incident 16497 (ORA 7445 [npixfc()+243]) ========
----- Beginning of Customized Incident Dump(s) -----
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x7FFF20B670B8] [PC:0x59BAADD, npixfc()+243] [flags: 0x0, count: 1]
Registers:
%rax: 0x000000000a99d750 %rbx: 0x0000000000000001 %rcx: 0x00007fff20b6dee0
%rdx: 0x0000000000000000 %rdi: 0x00007fff20b6d710 %rsi: 0x00002aed89f745a0
%rsp: 0x00007fff20b670c0 %rbp: 0x00007fff20b6dce0 %r8: 0x0000000000000000
%r9: 0x0000000000000000 %r10: 0x0000000000000000 %r11: 0x0000000000000001
%r12: 0x0000000000000010 %r13: 0x00002aed89fa7560 %r14: 0x00002aed89f73c18
%r15: 0x0000000000000001 %rip: 0x00000000059baadd %efl: 0x0000000000010202
(0x59baadd) call 0x9d24a0(0x59baae2) mov %eax,-0x14(%rbp)
(0x59baae5) test %eax,%eax
(0x59baae7) jnz 0x59bfd26
(0x59baaed) mov -0x120(%rbp),%rsi
Is it something to worry about? Any hints about the reasons?
Thanks,
P.Thanks for your reply. I expected the advice to utilize the support for that :)
The results of my investigation:
Listener log - normal activity. New connections to the DB and to different gateways (including the one that caused the problem) every couple of seconds, everything seemed to be working fine.
Alert log - no other entries +/- 1 hour around the incident, except log switching.
I checked the application logs and managed to find out the session that caused the problem. It is an ETL process that runs the same extraction query on Sybase machine every minute. The query does not change and it was executed successfully hundreds of times before. Other similar processes were running fine, executing similar queries on all Sybase machines, including the one in the incident. So the incident seems to be random, with no correlation to other activities.
The flow of events in the problematic session iis as follows:
1. opens Gateway connection and sets session parameters on Sybase by executing:
dbms_hs_passthrough.execute_immediate@PM04PMDB('set lock wait 60 ') -> that went OK
2. starts data extraction by running:
insert into ... select ... from ...@PM04PMDB -> that operation hang, no further logs from this point
3. commits
4. closes DB link by executing:
alter session close database link PM04PMDB
The SQL that failed was executed at 7:23, and the incident entry in the alert log is dated 7:33.
Is it possible that the 10 seconds delay is caused by HS_FDS_CONNECT_PROPERTIES="timeout='10'" ?
The gateway config:
HS_FDS_CONNECT_INFO=xxx
HS_FDS_TRANSACTION_MODEL=READ_ONLY
HS_FDS_TRACE_LEVEL=OFF
HS_OPEN_CURSORS=10
HS_FDS_CONNECT_PROPERTIES="timeout='10'"
HS_FDS_RECOVERY_ACCOUNT=xxx
HS_FDS_RECOVERY_PWD=xxx
Listener config:
(SID_DESC=
(SID_NAME=PM04PMDB)
(ORACLE_HOME=/oracle/app/product/11.2.0/dbhome_1)
(ENVS=LD_LIBRARY_PATH=/oracle/app/product/11.2.0/dbhome_1/dg4sybs/driver/lib:/oracle/app/product/11.2.0/dbhome_1/lib)
(PROGRAM=dg4sybs)
) -
Setting up two machines for core dump
Hi, I'm trying to set up two Macs to collect a Core Dump after a Kernel Panic.
A MacBook Pro 3,1 triggers a kernel panic when Mavericks is installed, and either Ethernet or WiFi connections are changed. No diagnostic reports get generated at /Library/Logs/DiagnosticReports.
I have been reading on how to set up a core dump over FireWire, since Ethernet seems to be compromised. I'm able to do a core dump by triggering a kernel panic with DTrace. The Development Machine receives and stores the core dump correctly. However if a kernel panic occurs when WiFi is switched off, the Core Dump does not take place, and I don't know if it should work as the DTrace trigger does.
I have System 10.9.1 on both Target and Development machines. The machines are each other connected with a FireWire 800 cable and a ThuderBolt adapter, since Development machine lacks the FireWire port (It's a MacBook Pro retina).
- Target machine is connected to my WiFi network and is also connected to the Ethernet network. The FireWire 800 port is manually set to IP 10.0.1.127
- Development machine is connected to my WiFi network. The FireWire 800 cable coming from the Target machine connects to a ThunderBolt adapter and the port is manually set to IP 10.0.1.128
- On the Target machine (MacBook Pro 3,1) I've set
sudo nvram boot-args="debug=0xd46 _panicd_ip=10.0.1.128 kdp_match_name = firewire"
- On the Development machine (MacBook Pro retina)
sudo mkdir /PanicDumps
sudo chown root:wheel /PanicDumps
sudo chmod 1777 /PanicDumps
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.kdumpd.plist
- verified that the core dump server is working with
sudo launchctl list | grep kdump
- after connecting the FireWire cable to the Macs
run fwkdp
- and machine responds with:
FireWire KDP Tool (v1.6)
KDP Proxy and CoreDump-Receive dual mode active.
Use 'localhost' as the KDP target in gdb.
Ready.
As mentioned above, triggering a Core Dump with DTrace works just fine.
Turning WiFi Off causes a Kernel Panic, Target machine freezes immediatedly and nothing happens on Development machine.
Forcing power off on Target machine and restarting shows no logs on Console.
I've read very little on GDB and it seems hard to find information, at least on what I'm doing. I'm not trying to debug a kernel extension.
nvram -p dumps mostly jibberish on the terminal screen
I'm tempted on setting up the core dump with Ethernet, but hesitate since WiFi and Ethernet seem to block the system abruptly.
Can someone illuminate me please?
Thanks in advance and best regards,
GuidoThank you Ian, however, when I click this option, my library looses all of its preferences/user presets?? I am confused
They aren't lost, instead they have been left outside the catalog because they preceded the change.
You can drag the contents of your Lightroom presets folder into the Lightroom Settings folder within Lightroom catalog folder and the application will then see them after relaunch. This is by far the quickest and easiest way of copying existing presets to the central catalog. Follow these steps:
Step 1 - Open you original catalog
Step 2 - Open Lightroom Preferences and choose the Presets tab
Step 3 - Make sure that Store presets with catalog is unchecked
Step 4 - Hit the Show Lightroom Presets Folder... button.
The presets folder will see multiple sub-folders which contain your existing
Step 5 - Open the folder with the moved catalog (i.e. the version you put on the external disk)
Step 6 - Open the folder named Lightroom Settings
Step 7 - Delete it's contents
Step 8 - Drag the contents of the folder you opened in step 4 in to the Lightroom Settings folder that you opened in Step 6
Step 9 - Launch the moved catalog as described in my previous post (i.e. double click it)
If you did everything correctly the catalog will now have access to your presets -
Core Dump in Foccur32() due to Address Misalignment
Hi,
I am working on Tuxedo 11.1_RP090 with HP-UX IA64, and after a call to tpcall() there is a core dumped due to address alignment issue. The following is excerpt from gdb backtrace.
<snip>
Program terminated with signal 10, Bus error.
BUS_ADRALN - Invalid address alignment. Please refer to the following link that helps in handling unaligned data: http://docs.hp.com/en/7730/newhelp0610/pragmas.htm#pragma-pack-ex3
#0 0xc000000000211ab0:0 in _lwp_kill+0x30 ()
from /usr/lib/hpux64/libpthread.so.1
(gdb) db
Undefined command: "db". Try "help".
(gdb) bt
#0 0xc000000000211ab0:0 in _lwp_kill+0x30 ()
from /usr/lib/hpux64/libpthread.so.1
#1 0xc000000000178810:0 in pthread_kill+0x9d0 ()
from /usr/lib/hpux64/libpthread.so.1
#2 0xc0000000003f80e0:0 in raise+0xe0 () from /usr/lib/hpux64/libc.so.1
#3 0xc00000001e5a2d80:0 in skgesigOSCrash () at skgesig.c:376
#4 0xc00000001f666900:0 in kpeDbgSignalHandler () at kpedbg.c:1074
#5 0xc00000001e5a3220:0 in skgesig_sigactionHandler () at skgesig.c:799
#6 <signal handler called>
#7 Foccur32 () at Foccur32.c:87
#8 0xc00000001498c020:0 in _tmaff_delallflds () at affinity.c:725
#9 0xc00000001498b570:0 in _tmaff_acall () at affinity.c:117
#10 0xc00000001478f7a0:0 in _tpacall_internal () at tmacall.c:588
#11 0xc0000000147a2a30:0 in _tpcall_internal () at tmcall.c:349
#12 0xc0000000147a0ed0:0 in _tpcall_ () at tmcall.c:157
#13 0xc0000000147a3790:0 in tpcall () at tmcall.c:474
#14 0xc000000002a3bc90:2 in inline mtux_flags () at my_app.c:1078
#15 0xc000000002a3bc80:2 in mtux_sync (l_name=<not available>,
l_service=<not available>, l_request_buf=<not available>,
l_request_buf_len=<not available>, l_response_buf=<not available>,
l_response_buf_len=<not available>, l_flags=<not available>)
at my_app.c:1215
</snip>
In Frame 15, there is a call to tpcall() as follows:-
tpcall((char *)l_service,
l_request_buf,
l_request_buf_len,
l_response_buf,
l_response_buf_len,
mtux_flags(l_flags))
From there the tuxedo code gets called and Signal 10 is raised in Frame 7, inside Foccur32(). Since we do not have the code for Foccur32.c,
it is difficult for us to determine which address data structure passed as input parameter to tpcall() is misaligned or is it some misaligned pointer in Foccur32() code.
It would be helpful, if someone can guide as to which structure needs to be examined for possible misalignment.
Can someone please let me know what can be done to know whether code causing issue at line no. 87 in Foccut32() comes from the parameters passed to tpcall()?
I am not sure whether it is due to the parameters we pass or due to some internal data structure used by Foccur32().
Message was edited by: 642aa413-1410-45b0-8534-b407133fb819Hi,
From a quick look at the code in affinity.c I'm guessing that you have a memory corruption problem. The fault is occurring while trying to access the Tuxedo META TCM, a header that Tuxedo associates with the request. If you can create a simple reproducer I would suggest opening a support request and provide the reproducer.
As always, if this is a new problem, what's changed in your environment or application? Also what is the environment/configuration of your Tuxedo application?
Regards,
Todd Little
Oracle Tuxedo Chief Architect -
Value type exception causes core dump
Hi,
Here is the situation: Session EJB (SynchronousAdapterBean) running on WebLogic
7.0 is being called by C++ client using Tuxedo 8.1 Solaris 8. The SynchronousAdapterBean
has a find method which throws a user defined exception (SynchronousAdapterException)
resulting in a core dump.
I have read through much documentation on the newsgroups, edocs.bea.com, and
the examples coming with WebLogic.
Here some of the things I did:
1.
When using the 'idl' command to generate the C++ code, I did not forget to use
a '-i' to generate the implementation files: SynchronousAdapterException_i.cpp
and SynchronousAdapterException_i.h.
In my "play with it to make it work" phase, I also did this for: SynchronousAdapterEx_i.cpp
and SynchronousAdapterEx_i.h.
2.
In my C++ client, I did not forget to register the factory as such:
orb->register_value_factory
((char* const)com::trs::cv::comm::cnja::synchadapter::_tc_SynchronousAdapterException->id(),
(CORBA::ValueFactory)
new com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterException_factory());
This seemed to work because I actually put debug cout statements in the 'com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterException_factory'
in the file SynchronousAdapterEx_i.cpp and it confirmed that it was constructed
and the reference count was incremented.
3.
I know for sure that it is a 'SynchronousAdapterException' being thrown on the
server side because all the find method does it this point is:
throw new SynchronousAdapterException("test1");
Questions:
1. I read at a few places that one only has to register the "most derived" class
being thrown (in my case 'SynchronousAdapterException'). What does one do with
all the other exceptions generated:
EJBException_c.h
EJBException_c.cpp
EJBEx_c.h
EJBEx_c.cpp
CreateEx_c.h
CreateEx_c.cpp
CreateException_c.h
CreateException_c.cpp
RemoveEx_c.h
RemoveEx_c.cpp
RemoveException_c.h
RemoveException_c.cpp
RuntimeEx_c.h
RuntimeEx_c.cpp
RuntimeException_c.cpp
RuntimeException_c.h
SynchronousAdapterEx_c.cpp
SynchronousAdapterEx_c.h
SynchronousAdapterEx_i.cpp
SynchronousAdapterEx_i.h
Exc.cpp
Exc.h
Exceptionc.cpp
Exceptionc.h
2. What step could I have missed?
AlexHi Andy,
1.
Well no new member classes in SynchronousAdapterException it just looks like this:
public class SynchronousAdapterException extends Exception {
public SynchronousAdapterException() {
super();
Not available in 1.3.1, but is available in 1.4
public SynchronousAdapterException(String message, Throwable ex) {
super(message, ex);
public SynchronousAdapterException(String message) {
super(message);
Not available in 1.3.1, but is available in 1.4
public SynchronousAdapterException(Throwable ex) {
super(ex);
2.
We are using:
java version "1.3.1_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03)
Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode)
3.
dbx produces the following, anything ring a bell?
Reading libdl.so.1
Reading libaio.so.1
Reading libmp.so.2
Reading libc_psr.so.1
Reading liborbiiop.so.71
Reading liborbtcp.so.71
detected a multithreaded program
t@2 (l@2) terminated by signal ABRT (Abort)
0xfec9bbd4: lwpkill+0x0008: bgeu,a lwpkill+0x1c
Current function is operator>>
218 mb.UnMarshalValue(::com::trs::cv::comm::cnja::synchadapter::_tc_SynchronousAdapterException,
obj);
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
current thread: t@2
[1] lwpkill(0x0, 0x2, 0x0, 0x6, 0x197f0, 0x4c6e0), at 0xfec9bbd4
[2] raise(0x6, 0x0, 0xffffffff, 0xc00cc, 0x8, 0xfee355c0), at 0x4c6e8
[3] abort(0xd2040, 0xbeaf8, 0xff3b2aac, 0xfee34684, 0x15398, 0xfee34874), at
0x4c6a8
[4] __Cimpl::ex_terminate(0x0, 0x0, 0xfee4a500, 0xff1edf90, 0xff09ecd0, 0x1),
at 0xfee34684
---- hidden frames, use 'where -h' to see them all ----
[6] OBB::MarshalBuf::UnMarshalValue(0xfeaf9a28, 0xc9dd8, 0xfeaf99b0, 0xff1edf90,
0xff1edfd0, 0xfed2ebb8), at 0xff0a3980
=>[7] operator>>(mb = CLASS, obj = CLASS), line 218 in "SynchronousAdapterExc.cpp"
[8] _tcr_com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterEx_unmarsh(mh =
0xce520, obj = 0xfeaf9b7c, flags = 130U), line 259 in "SynchronousAdapterEx_c.cpp"
[9] TCInterpreter::DecodeByTypeCode(0x16, 0xff1d674c, 0xfeaf9b7c, 0xce520, 0x82,
0xfeaf9b07), at 0xff0f3aec
[10] TCInterpreter::DecodeById(0xcbaa0, 0xcf230, 0xfeaf9b7c, 0xce520, 0x82,
0xfeaf9f98), at 0xff0f3c94
[11] ReplyMessage::DecodeMessageBody(0x18000, 0xcd820, 0xfeaf9f98, 0xbf358,
0xfebcffb0, 0xfed2ebb8), at 0xff0e1938
[12] GIOPMessage::DecodeBody(0xce240, 0xfeaf9f98, 0xff0dd494, 0xff0dd494, 0xffffffd0,
0xfeb93e24), at 0xff0c23a0
[13] IiopProtocol::Reply(0xd0958, 0xce240, 0xce148, 0xfeaf9f98, 0x100, 0xfebd0010),
at 0xfeb94064
[14] IiopMsgReceiver::MsgReceived(0xca5a0, 0xce240, 0xce148, 0xfeaf9f98, 0x0,
0xfeaf9f98), at 0xfeb9bc74
[15] GiopMessageProtocol::MsgReceived(0xcb358, 0xfeaf9dd8, 0xd1160, 0xfeaf9f98,
0x0, 0xfeaf9f98), at 0xfebac6fc
[16] MessageManager::RecvMsgFirstTime(0xcf8c0, 0xce240, 0xd1160, 0xcb358, 0xd11d0,
0xfeaf9f98), at 0xfebab1b0
[17] MessageManager::AvailableForRecvMsg(0xcf8c0, 0xd1160, 0xcb358, 0xfeaf9f98,
0x3e8, 0xd1170), at 0xfebaa030
[18] ChannelManager::DoReadWork(0xff1d674c, 0xfebd0038, 0xd1160, 0x0, 0x0, 0xcfd58),
at 0xfeba54dc
[19] ChannelManager::DoIt(0xcb3b0, 0xfeaf9f98, 0x0, 0xfebcffd0, 0xcfda0, 0xfebcffd0),
at 0xfeba0750
[20] WorkerManager::DoWorkerThread(0x0, 0xca648, 0xfeaf9f98, 0xcfda0, 0xfeba9924,
0x0), at 0xfeba7894
[21] WorkerThread(0xcfd98, 0xfeafa000, 0x0, 0x0, 0x0, 0x0), at 0xfeba9974
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx)
Thanks,
Alex
Andy Piper <[email protected]> wrote:
"Alex" <[email protected]> writes:
It sounds like you have done all the right steps. More comments in-line:
1.
When using the 'idl' command to generate the C++ code, I did not forgetto use
a '-i' to generate the implementation files: SynchronousAdapterException_i.cpp
and SynchronousAdapterException_i.h. Ok.
In my "play with it to make it work" phase, I also did this for: SynchronousAdapterEx_i.cpp
and SynchronousAdapterEx_i.h.This should not be necessary - XXXEx is an IDL exception.
2.
In my C++ client, I did not forget to register the factory as such:
orb->register_value_factory
((char* const)com::trs::cv::comm::cnja::synchadapter::_tc_SynchronousAdapterException->id(),
(CORBA::ValueFactory)
new com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterException_factory());Ok. What does the Exception actually look like in Java? (Incidentally
the _i file creates a useful helper function called _register() which
will do this step for you). Did you register all member classes? You
are correct about most derived types being the important ones, but you
need to also register member classes if they are not standard.
This seemed to work because I actually put debug cout statements inthe 'com_trs_cv_comm_cnja_synchadapter_SynchronousAdapterException_factory'
in the file SynchronousAdapterEx_i.cpp and it confirmed that it wasconstructed
and the reference count was incremented.
3.
I know for sure that it is a 'SynchronousAdapterException' being thrownon the
server side because all the find method does it this point is:
throw new SynchronousAdapterException("test1");Ok (incidentally you are not running the server on JDK 1.4 are
you. This would cause problems).
Questions:
1. I read at a few places that one only has to register the "most derived"class
being thrown (in my case 'SynchronousAdapterException'). What doesone do with
Yes.
all the other exceptions generated:These are just needed at compile time so that you don't get undefined
symbols.
2. What step could I have missed?Its not clear. You should try running in a debugger and seeing where
its falling over.
andy -
Intresting segv:studio12update1 core dump in stlport 4 startup:mixing C&C++
Hi
I am getting core dump below is the stack trace:
(dbx) where
current thread: t@1
=>[1] std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::imbue(0xffffffff4b3d0bf0, 0xffffffff7fffe790, 0x4c8, 0xffffffff6971f128, 0x400, 0xffffffff69711e68), at 0xffffffff69592200
[2] std::basic_streambuf<wchar_t,std::char_traits<wchar_t> >::pubimbue(0xffffffff695921a0, 0xffffffff4b3d0bf0, 0xffffffff7fffe790, 0xffffffff6971a938, 0x0, 0xffffffff7fffe6d0), at 0xffffffff6956d4e8
[3] std::basic_ios<wchar_t,std::char_traits<wchar_t> >::imbue(0xffffffff7fffe798, 0xffffffff6971fbd0, 0xffffffff7fffe790, 0xffffffff69711e68, 0x13da94, 0x400), at 0xffffffff6957284c
[4] std::basic_ios<wchar_t,std::char_traits<wchar_t> >::init(0xffffffff6971fbd0, 0xffffffff4b3d0bf0, 0x448, 0xffffffff69711e68, 0x19f4c4, 0x400), at 0xffffffff69572a0c
[5] std::basic_ostream<wchar_t,std::char_traits<wchar_t> >::basic_ostream(0xffffffff6971fbc8, 0xffffffff4b3d0bf0, 0xc0, 0x185fec, 0x0, 0xffffffff69711e68), at 0xffffffff6958becc
[6] std::__Wide_Init::__Wide_Init(0xffffffff4b3ceec0, 0xffffffff4b3d0bf0, 0xffffffff4b3d0c90, 0xffffffff4b3c27d0, 0xffffffff6971fd38, 0xe000), at 0xffffffff4b21444c
---- hidden frames, use 'where -h' to see them all ----
[8] __Cimpl::cplus_init(0x1, 0xffffffff4de0dd60, 0xffffffff4de0dd68, 0x0, 0x1044a4, 0xffffffff4b3cf460), at 0xffffffff4dd08660
[9] 0xffffffff4b235ae8(0x0, 0x0, 0xffffffff7f72cb18, 0xffffffff7f611ee8, 0x11e6a0, 0xffffffff7f402400), at 0xffffffff4b235ae8
[10] call_init(0x1, 0x1, 0xffffffff4b235a10, 0xffffffff68a007b8, 0xffdfffff, 0xffffffff7f72cb18), at 0xffffffff7f611ef0
[11] setup(0xc7, 0x28, 0xc10000, 0xa000000, 0xffffffff61a01b08, 0x100000), at 0xffffffff7f6113b4
[12] _setup(0x6ffffff9, 0xb00, 0xffffffff7f62ae5c, 0x100000040, 0x0, 0xffffffff7ffff158), at 0xffffffff7f620554
[13] rtboot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7f60511c
Some important notes I am mixing C & C++
wrap is the C interface so when I link application I am explicitly linking libC & libstlport.so
-L/opt/sunstudio12.1/lib/stlport4/v9 -lstlport
-L/usr/lib/64
-lstlport
-lCrun
I am compiling my application like this :
CC -g0 -mt -compat=5 -I/opt/sunstudio12.1/prod/include/CC/stlport4 -D_POSIX_PTHREAD_SEMANTICS -DACE_HAS_KSTAT -DACE_HAS_SCTP -DACE_HAS_LKSCTP -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -DSUN_CC_HAS_PVFC_BUG -DACE_HAS_CUSTOM_EXPORT_MACROS=0 -m64 -DXALTEDSUN64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -m64 -D_THREAD_SAFE -D_LARGE_FILES=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I/export/home/frtbld/3rdparty/include/bdb -I/export/home/frtbld/3rdparty/include -I/export/home/oracle/OraHome/precomp/public -I/export/home/oracle/OraHome/network/public -I/export/home/oracle/OraHome/rdbms/public -I/export/home/oracle/OraHome/plsql/public -I/export/home/oracle/OraHome/rdbms/demo -I/export/home/frtbld/libcinc -I/usr/local/include -c DBAbs.cpp -o /export/home/frtbld/TMPOBJ/DBAbs.o
Generating MyDb.o file from MyDb.cpp file ...
CC -g0 -mt -compat=5 -I/opt/sunstudio12.1/prod/include/CC/stlport4 -D_POSIX_PTHREAD_SEMANTICS -DACE_HAS_KSTAT -DACE_HAS_SCTP -DACE_HAS_LKSCTP -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -DSUN_CC_HAS_PVFC_BUG -DACE_HAS_CUSTOM_EXPORT_MACROS=0 -m64 -DXALTEDSUN64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -m64 -D_THREAD_SAFE -D_LARGE_FILES=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I/export/home/frtbld/3rdparty/include/bdb -I/export/home/frtbld/3rdparty/include -I/export/home/oracle/OraHome/precomp/public -I/export/home/oracle/OraHome/network/public -I/export/home/oracle/OraHome/rdbms/public -I/export/home/oracle/OraHome/plsql/public -I/export/home/oracle/OraHome/rdbms/demo -I/export/home/frtbld/libcinc -I/usr/local/include -c MyDb.cpp -o /export/home/frtbld/TMPOBJ/MyDb.o
Generating wrap.o file from wrap.cpp file ...
CC -g0 -mt -compat=5 -I/opt/sunstudio12.1/prod/include/CC/stlport4 -D_POSIX_PTHREAD_SEMANTICS -DACE_HAS_KSTAT -DACE_HAS_SCTP -DACE_HAS_LKSCTP -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -DSUN_CC_HAS_PVFC_BUG -DACE_HAS_CUSTOM_EXPORT_MACROS=0 -m64 -DXALTEDSUN64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -m64 -D_THREAD_SAFE -D_LARGE_FILES=1 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I/export/home/frtbld/3rdparty/include/bdb -I/export/home/frtbld/3rdparty/include -I/export/home/oracle/OraHome/precomp/public -I/export/home/oracle/OraHome/network/public -I/export/home/oracle/OraHome/rdbms/public -I/export/home/oracle/OraHome/plsql/public -I/export/home/oracle/OraHome/rdbms/demo -I/export/home/frtbld/libcinc -I/usr/local/include -c wrap.cpp -o /export/home/frtbld/TMPOBJ/wrap.o
ar *.o -o /export/home/frtbld/libcbin/LIB_BDBManager.a
/export/home/tuxedo/bea/tuxedo10gR3/bin/buildclient -o /export/home/frtbld/TMPBIN/CompilerPP -f-L/export/home/oracle/OraHome/lib -f-lclntsh \
-f /export/home/frtbld/TMPOBJ/CompilerMainPP.o \
-f /export/home/frtbld/TMPOBJ/CompilerDataBasePP1.o \
-f /export/home/frtbld/TMPOBJ/CompilerDataBasePP2.o \
-f /export/home/frtbld/TMPOBJ/utilityPP.o \
-f "-L/opt/sunstudio12.1/lib/stlport4/v9 -lstlport -L/export/home/frtbld/3rdparty/lib/bdblib -L/export/home/frtbld/3rdparty/lib/acelib -ldb_cxx-4.7 -lACE /export/home/frtbld/libcbin/LIB_DataBase.a /export/home/frtbld/libcbin/LIB_FileManager.a /export/home/frtbld/libcbin/LIB_Log.a /export/home/frtbld/libcbin/LIB_SHMManager.a /export/home/frtbld/libcbin/LIB_Expression.a /export/home/frtbld/libcbin/LIB_Timing.a /export/home/frtbld/libcbin/LIB_MMFManager.a /export/home/frtbld/libcbin/LIB_LicManager.a /export/home/frtbld/libcbin/LIB_InterProcComm.a /export/home/frtbld/libcbin/LIB_BDBManager.a /export/home/frtbld/libcbin/LIB_RatingPPMMFManager.a -L/usr/lib/hpux32/ -L/usr/local/lib/hpux32 -L/lib/hpux32 -L/export/home/frtbld/3rdparty/lib/ssllib -lcrypto -lz -lm -L/usr/lib/64 -L/opt/sunstudio12.1/lib/stlport4/v9 -lCrun "
Regards
Anand RathiHi Thanks for your help
I changed the linking process to use CC
but still its same .....
and i can also see that its invoking __Cimpl::cplus_init
also i have an doubt about 64bit and std::__Wide_Init::__Wide_Init
weather issue is with wide character 64 bit ?
Now the command is
CC -g0 -mt -compat=5 -I/opt/sunstudio12.1/prod/include/CC/stlport4 -D_POSIX_PTHREAD_SEMANTICS -DACE_HAS_KSTAT -DACE_HAS_SCTP -DACE_HAS_LKSCTP -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -DSUN_CC_HAS_PVFC_BUG -DACE_HAS_CUSTOM_EXPORT_MACROS=0 -m64 -DXALTEDSUN64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -m64 -mt -I/export/home/tuxedo/bea/tuxedo10gR3/include -o /export/home/frtbld/TMPBIN/CompilerPP -L/export/home/tuxedo/bea/tuxedo10gR3/lib -xarch=v9 -L/export/home/oracle/OraHome/lib -lclntsh /export/home/frtbld/TMPOBJ/CompilerMainPP.o /export/home/frtbld/TMPOBJ/CompilerDataBasePP1.o /export/home/frtbld/TMPOBJ/CompilerDataBasePP2.o /export/home/frtbld/TMPOBJ/utilityPP.o -L/opt/sunstudio12.1/lib/stlport4/v9 -lstlport -L/export/home/frtbld/3rdparty/lib/bdblib -L/export/home/frtbld/3rdparty/lib/acelib -ldb_cxx-4.7 -lACE /export/home/frtbld/libcbin/LIB_DataBase.a /export/home/frtbld/libcbin/LIB_FileManager.a /export/home/frtbld/libcbin/LIB_Log.a /export/home/frtbld/libcbin/LIB_SHMManager.a /export/home/frtbld/libcbin/LIB_Expression.a /export/home/frtbld/libcbin/LIB_Timing.a /export/home/frtbld/libcbin/LIB_MMFManager.a /export/home/frtbld/libcbin/LIB_LicManager.a /export/home/frtbld/libcbin/LIB_InterProcComm.a /export/home/frtbld/libcbin/LIB_BDBManager.a /export/home/frtbld/libcbin/LIB_RatingPPMMFManager.a -L/usr/lib/hpux32/ -L/usr/local/lib/hpux32 -L/lib/hpux32 -L/export/home/frtbld/3rdparty/lib/ssllib -lcrypto -lz -lm -L/usr/lib/64 -L/opt/sunstudio12.1/lib/stlport4/v9 -lCrun -ltux -lbuft -lfml -lfml32 -lengine -R/usr/lib/lwp -lpthread -lposix4 -lsocket -lnsl -lm -lnsl -lsocket
t@1 (l@1) program terminated by signal SEGV (no mapping at the fault address)
0xffffffff7e192200: imbue+0x0060: ldx [%o0], %o1
(dbx) where
current thread: t@1
=>[1] std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::imbue(0xffffffff7acd0bf0, 0xffffffff7fffe4d0, 0x4c8, 0xffffffff7e31f128, 0x400, 0xffffffff7e311e68), at 0xffffffff7e192200
[2] std::basic_streambuf<wchar_t,std::char_traits<wchar_t> >::pubimbue(0xffffffff7e1921a0, 0xffffffff7acd0bf0, 0xffffffff7fffe4d0, 0xffffffff7e31a938, 0x13da94, 0xffffffff7fffe410), at 0xffffffff7e16d4e8
[3] std::basic_ios<wchar_t,std::char_traits<wchar_t> >::imbue(0xffffffff7fffe4d8, 0xffffffff7e31fbd0, 0xffffffff7fffe4d0, 0xffffffff7e311e68, 0x13da94, 0x400), at 0xffffffff7e17284c
[4] std::basic_ios<wchar_t,std::char_traits<wchar_t> >::init(0xffffffff7e31fbd0, 0xffffffff7acd0bf0, 0x448, 0xffffffff7e311e68, 0x19f4c4, 0x400), at 0xffffffff7e172a0c
[5] std::basic_ostream<wchar_t,std::char_traits<wchar_t> >::basic_ostream(0xffffffff7e31fbc8, 0xffffffff7acd0bf0, 0xc0, 0x185fec, 0x0, 0xffffffff7e311e68), at 0xffffffff7e18becc
[6] std::__Wide_Init::__Wide_Init(0xffffffff7acceec0, 0xffffffff7acd0bf0, 0xffffffff7acd0c90, 0xffffffff7acc27d0, 0xffffffff7e31fd38, 0xe000), at 0xffffffff7ab1444c
---- hidden frames, use 'where -h' to see them all ----
[8] __Cimpl::cplus_init(0x1, 0xffffffff7d00dd60, 0xffffffff7d00dd68, 0x0, 0x1044a4, 0xffffffff7accf460), at 0xffffffff7cf08660
[9] 0xffffffff7cf0a500(0x0, 0x0, 0xffffffff7f72cb18, 0xffffffff7f611ee8, 0x11e6a0, 0xffffffff79702000), at 0xffffffff7cf0a500
[10] call_init(0x1, 0x3, 0xffffffff7cf0a428, 0xffffffff7f201530, 0xffdfffff, 0xffffffff7f72cb18), at 0xffffffff7f611ef0
[11] elf_bndr(0xffffffff7f500718, 0xffffffff7cf016e0, 0xffffffff7ab35ab4, 0xffffffff7cf06610, 0xffffffff78d009e8, 0xffffffff7f72f6d8), at 0xffffffff7f61f060
[12] elf_rtbndr(0x590000, 0x1001d3538, 0x0, 0xffffffff7ab35ab4, 0x0, 0x0), at 0xffffffff7f60514c
[13] 0x0(0xffffffff7acc7e28, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x0
[14] 0xffffffff7ab35ab4(0x0, 0x0, 0xffffffff7f72cb18, 0xffffffff7f611ee8, 0x11e6a0, 0xffffffff79702000), at 0xffffffff7ab35ab4
[15] call_init(0x1, 0x1, 0xffffffff7ab35a10, 0xffffffff7a900030, 0xffdfffff, 0xffffffff7f72cb18), at 0xffffffff7f611ef0
[16] setup(0x0, 0x27, 0xc10000, 0xa000000, 0xffffffff78d01780, 0x100000), at 0xffffffff7f6113b4
[17] _setup(0x6ffffff9, 0xb00, 0xffffffff7f62ae5c, 0x100000040, 0x0, 0xffffffff7ffff288), at 0xffffffff7f620554
[18] rtboot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xffffffff7f60511c
Edited by: anandprathi on Aug 12, 2009 9:48 AM
Edited by: anandprathi on Aug 12, 2009 9:52 AM -
Core dump when running the Proc Application
I have client that has decided to upgrade from Oracle 10g to Oracle11g version. Presently the client code is compiled with Oracle version 11.1.0.7. We have tuxedo version as 9.0 patch02. When running the ProC application, I am getting the core dump. The stack trace for dump is as follows :-
core 'core' of 7784: bp_Customer -C dom=KenanFX -g 5 -i 225 -u dsesun10 -U /users/denver/pc
ffffffff6e8d9bbc kill (2, ffffffff7ffe002c, 1, ffffffff7de3b9a0, ffffffff7ffe0028, ffffffff7e10b5a0) + 8
ffffffff7d27b1f4 skgesigCrash (ffffffff7ffe09a8, ffffffff7e10a070, 1a0c00, ffffffff7dfdbc40, d60a7c, 1) + 34
ffffffff7d27b81c skgesig_sigactionHandler (ffffffff7d6fb9a0, ffffffff7ffe1800, ffffffff7ffe0990, ffffffff7e10b578, ffffffff7ffe0998, ffffffff7ffe09a8) + dc
ffffffff6e8d62e0 __sighndlr (b, ffffffff7ffe1800, ffffffff7ffe1520, ffffffff7d27b740, 0, a) + c
ffffffff6e8c9e44 call_user_handler (ffffffff75f00200, ffffffff75f00200, ffffffff7ffe1520, 8, 0, 0) + 3e0
ffffffff6e8ca03c sigacthandler (0, ffffffff7ffe1800, ffffffff7ffe1520, ffffffff75f00200, 0, ffffffff6ea3c000) + 54
--- called from signal handler with signal 0 (SIGEXIT) ---
ffffffff7c24bb24 sqlrlc (ffffffff7e0f9fc0, 0, 60, c0, 4, 8) + 4
ffffffff7c253594 sqlbrl (ffffffff7e0f9fc0, 1004bc630, 1004bc658, 1004bc5d0, ffffffff7ffe1b30, 2) + 114
ffffffff7c2745ec sqlhvdsc (1004bc5c0, ffffffff7e0f9fc0, 8, ffffffff7fff27a0, 0, 1d676b0) + ac
ffffffff7c274e68 sqlshv (c, 0, e, 0, f, 1c) + 128
ffffffff7c25bd8c sqlsel (ffffffff7fff27a0, 1002d0850, 1002d0d80, 1, ffffffff7e0f9fc0, ffffffff7dd09d70) + 38c
ffffffff7c24ed18 sqlcmex (1, ffffffff7ffe1e80, 0, c, 1002d0850, 0) + 278
ffffffff7c24f724 sqlcxt (0, ffffffff74fd3800, ffffffff7fff27a0, ffffffff74e5d3e4, 16400, 0) + 44
ffffffff74c65aec selectCMF_XIDDB (788, 16450, 2, ffffffff74fbb978, ffffffff7fff4344, ffffffff7971de60) + f14
ffffffff79f5743c bp_AccountFind (0, 0, 1002b6118, 1002b6118, 1002b6118, 1002b6118) + 137c
000000010001748c commonServiceWrapper (30, 0, 558, 1, 100140428, ffffffff6fa08560) + cac
000000010001d1a4 I_AccountFind (100188220, 12336c, 2e60, 100186b80, ffffffff7fffa440, ffffffff6fa08560) + ec
ffffffff7f25ea34 _tmsvcdsp (100186b80, 0, 1001f7b60, 800, 100186b80, 1400) + 11ac
ffffffff7f28241c _tmrunserver (2bb4, 0, 100186b80, 10017c480, 10017d5a0, 0) + 11ac
ffffffff7f25d47c _tmstartserver (1, 2c00, 100144c90, 800, 10017ebe0, 1001444e0) + 1ac
0000000100014e4c main (1b, ffffffff7fffab18, ffffffff7fffabf8, ffffffff6e84b8e0, ffffffff75b05200, ffffffff75f00200) + 14
0000000100014d9c _start (0, 0, 0, 0, 0, 0) + 17c
Can you please help what is causing problem in the applications. Thanks in advanced.This forum is about C programming in general, and about using Oracle Studio C in particular.
Your question seems to be about a database application that now crashes when run on an updated version of Oracle database.
You mention "Proc" and ProC". If you are referring to the Pro*C compiler, that would also be a database question, since the Pro*C compiler is not related to Oracle Studio or Oracle Studio C.
You are more likely to find a helpful answer in a database programming forum. Start here:
https://forums.oracle.com/forums/category.jspa?categoryID=18 -
Application dying with core dump on what appears to be berkeley
I have a web app being run on a solaris server. This web app ran for approximately 20 hours before crashing. I have the core dump file, but it is quite large (11GB). Using mdb I am able to get the stack trace from the core dump. Could this be an issue with a corrupted BDB? Or could it be corrupted environment file(s)? A similar, but different (slightly different stack trace) error that happened on another server a few hours later. We have 3 other servers that continue to run successfully though with the same BDB objects.
We are not writing to any of the BDBs. They are read only. Same with secondary BDBs. It is a java webapp interacting with the native solaris libraries. I forgot to add, this is a 64 bit machine.
If you have any ideas/suggestions/need more info please let me know.
Top of the stack trace below.
libc.so.1`_lwp_kill+8(6, 0, ffffffff7ef45538, ffffffffffffffff, ffffffff7ef3a000, 0)
libc.so.1`abort+0x118(1, 1d8, ffffffff7e2fc6f8, 1ef13c, 0, 0)
libjvm.so`__1cCosFabort6Fb_v_+0x58(1, 1, 2dbc8, ffffffff7e69e000, 3abb94, 2d800)
libjvm.so`__1cHVMErrorOreport_and_die6M_v_+0xcb4(ffffffff7e700480, 0, 1, ffffffff7e70ace0, ffffffff7e6cbb80, ffffffff7e55c873)
libjvm.so`JVM_handle_solaris_signal+0xa6c(a, fffffffccbefd500, fffffffccbefd220, 1a0c00, 101b8a800, 280000)
libc.so.1`__sighndlr+0xc(a, fffffffccbefd500, fffffffccbefd220, ffffffff7ddf5df0, 0, 9)
libc.so.1`call_user_handler+0x3e0(ffffffff7bc15a00, ffffffff7bc15a00, fffffffccbefd220, c, 0, 0)
libc.so.1`sigacthandler+0x54(0, fffffffccbefd500, fffffffccbefd220, ffffffff7bc15a00, 0, ffffffff7ef3a000)
libdb_java-4.6.so`__env_alloc_free+0x140(100bab1c0, fffffffc6c0c75f8, fffffffc8bcff5dc, 1a, 66e, fffffffccbefe461)
libdb_java-4.6.so`__memp_free+0x1c(100bab1c0, fffffffc82123140, fffffffc6c0c75f8, fffffffccbefe710, 0, fffffffc6a00f1d0)
libdb_java-4.6.so`__memp_bhfree+0x6fc(100fc46e0, 100bab1c0, fffffffc6a00f1c8, fffffffc6c0c75f8, 1, 3)
libdb_java-4.6.so`__memp_alloc+0x1df8(100fc46e0, 100bab1c0, fffffffc82100698, 0, 0, fffffffccbefdeb0)
libdb_java-4.6.so`__memp_fget+0x233c(100ba5e50, 10142eb84, 0, 1, 10142eb78, 0)
libdb_java-4.6.so`__ham_get_cpage+0x33c(101258860, 1, 4, 1, 10142ebc8, 10142ebb0)
libdb_java-4.6.so`__ham_lookup+0x104(101258860, fffffffccbefe770, 0, 1, fffffffccbefe34c, 4c000)
libdb_java-4.6.so`__hamc_get+0x278(101258860, fffffffccbefe770, fffffffccbefe710, 1a, fffffffccbefe34c, 0)
libdb_java-4.6.so`__dbc_get+0x81c(101258860, fffffffccbefe770, fffffffccbefe710, 1a, 66e, fffffffccbefe461)
libdb_java-4.6.so`__db_get+0x1a4(1012b2570, 0, fffffffccbefe770, fffffffccbefe710, 0, 4c000)
libdb_java-4.6.so`__db_get_pp+0x3e0(1012b2570, 0, fffffffccbefe770, fffffffccbefe710, 0, fffffffccbefe700)
libdb_java-4.6.so`Db_get+0x40(1012b2570, 0, fffffffccbefe770, fffffffccbefe710, 0, 0)
libdb_java-4.6.so`Java_com_sleepycat_db_internal_db_1javaJNI_Db_1get+0x128(101b8a9b8, fffffffccbefe8e8, 1012b2570, 0, fffffffccbefe8c8, fffffffccbefe8d0)
0xffffffff78391410(1012b2570, 0, ffffffff11fc9a38, ffffffff11fc9a70, 0, fffffffccbefe101)
0xffffffff78005eac(ffffffff559ee358, b6, fffffffce2f93180, ffffffff78018100, 7124, fffffffccbefe221)
0xffffffff78005eac(ffffffff559ee338, b6, fffffffce2f92f60, ffffffff78017d20, ae1, fffffffccbefe331)
0xffffffff78005e60(ffffffff5fad4f80, b7, fffffffce2ff6ac0, ffffffff78017d28, 66e, fffffffccbefe461)
0xffffffff78005e60(ffffffff5fad4f80, fffffffce150e618, fffffffce2f9dd20, ffffffff78017f60, 5, fffffffccbefe5e1)
0xffffffff780063b8(ffffffff5fad4f20, b7, 0, ffffffff78018200, 1e400, fffffffccbefe701)
0xffffffff78005e60(ffffffff5fad4f20, fffffffce14a5828, 0, ffffffff78017f60, ffffffff11ff0cf0, fffffffccbefe811)
0xffffffff780063b8(ffffffff5f995ce0, fffffffce145f868, 0, ffffffff78017ce0, ffffffff11ff0cf0, fffffffccbefe931)
0xffffffff780063b8(ffffffff5f995d78, b6, 0, ffffffff78018200, ffffffff11ff0cf0, fffffffccbefea51)
0xffffffff78005fdc(fffffffef354e068, fffffffce00427e0, 0, ffffffff78017ce0, 0, fffffffccbefeb71)
0xffffffff78006534(fffffffef354e0f8, b7, 0, ffffffff78018200, 0, fffffffccbefecb1)
0xffffffff78005fdc(fffffffef354e0f8, fffffffce00427e0, 0, ffffffff78017f60, 912c14, fffffffccbefedc1)
0xffffffff78006534(fffffffccbefff50, 60800, 0, ffffffff78018200, fffffffef354e178, fffffffccbefeeb1)
0xffffffff78000240(fffffffccbeff8a0, fffffffccbeffd50, a, fffffffce00441e8, ffffffff7800bda0, fffffffccbeffb48)
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x1f4(1, 101b8a800, fffffffccbeffb38, a,
ffffffff780001e0, fffffffccbeff870)
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4pnRJavaCallArguments_pnGThread__v_+0x130(fffffffccbeffd48,
ffffffff7e6ea148, fffffffef354e178, 4c148, fffffffccbeffb38, ffffffffff6f4950)
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x50(fffffffccbeffd48, 100c8f880, 100c8f888,
ffffffff7e71c2b0, ffffffff7e71c798, 101b8a800)
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0xf0(fffffffef354e178, 101b8a800, 7dd50, 85fc64, ffffffff7e71bd50, 7dc00)
Edited by: user11287228 on Jun 9, 2011 11:33 AMHello,
If you can one thing that might help is rebuilding the Berkeley DB library with enable-debug and enable-diagnostic. With enable-debug we might get line numbers and see exact where we are in __env_alloc_free and see what the input parameters leading up to the abort are. With enable-diagnostic run-time checking is in place which might also help see what is causing this. (see http://download.oracle.com/docs/cd/E17076_02/html/installation/build_unix_conf.html) Another thing to do if you are not using a private environment is to look at the db_stat -E output:
http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/db_stat.html
Thank you,
Sandra
Maybe you are looking for
-
9.2.0.6 on RHEL 5 x86_64. Install Hangs: Link Pending... Copying naeet.o
I am trying to install 9.2.0.6 on RedHat EL 5 (x86_64). I am getting a known error, where the Installer hangs on 18% completion. The step it hangs at is "Installing Oracle Required Support Files 32 bit 9.2.1.0" and the text above the status bar is "C
-
Ciscoworks -- Intrenal error in communication channel
Hi Netpro Team, I am getting an error "Intrenal error in communication channel" while editing or adding/deleting snmp credentials in common services...(LMS-3.x); We tried restarting the ciscoworks services, but still getting the same problem. Please
-
Pictures do not display when I hover over event
I have noticed just recently that I have 2 problems with iPhoto11 which are; 1. When I hover over the eventy normally I see all the pictures in that event show in the event window. However on my recent events added I can no longer see the pictures in
-
Thank the gods - and Barefeats! Save your cash :-)) http://www.barefeats.com/nehal10.html
-
Why can't I log in to sign up new software upgrade? I have internet connection and my clock is corre
Why can't I log in to sign up new software upgrade? I have internet connection and my clock is correct.