SRW.APPLY_DEFINITION cause (core dumped) Segmentation fault

When I run report under Concurrent manager, i.e. within Oracle Applications I get this error:
(core dumped) Segmentation fault.
I use SRW.APPLY_DEFINITION in After Parameter Form. When I remove SRW.APPLY_DEFINITION report runs fine.
I tried following in the command line:
$ ar60runb report=/PATH_TO_RDF_FILE/NAME.rdf batch=yes destype=file desname=/PATH_TO_OUTPUT_FILE/NAME.out desformat=XML
and I get this error:
ar60runb: uisfz.c:173: uisfzfn_Fns: Assertion `0' failed.
Aborted (core dumped)
When I remove "batch=yes" or use "batch=no" everything passed fine.
I get the same result when I use .RDF file without SRW.APPLY_DEFINITION in the code.
I have applied the solution from Note:368457.1 but it didn't help.
I want to set "batch=no" when I run report under Oracle Applications or just resolve this problem somehow.
Platform SUSE \ UnitedLinux x86-64
Product Version 11.5.10.2

Come on, guys. Help! :(

Similar Messages

Redhat 6.0 Webdb 2.2 Server 8.1.5 sqlplus core dump segmentation fault solution

If anyone else is struggling with this installation, heres a workaround that
Got things going for me.
Redhat 6.0
Oracle 8.1.5
Webdb 2.2
The database was up and working fine. Not as many problems as earlier versions but there was still much grief getting it to work. Save yourself some time, dont charge ahead like I did, read the installation notes.
The installation of Webdb didnt go so well though. Sqlplus would core dump with segmentation fault when a connection to the local instance was attempted. I tried many things, install webdb to 8.1.5 , apply glibc patch, apply 8.0.5 patches to webdb install none of this worked. The workaround I finally found was to use the 8.1.5 listener and the old formatting of a listener.ora and tnsnames.ora file. (i.e. like 7.3.x). Sqlplus would then connect via tcp. Installation still had another problem I could never get past the sys password confirmation. I could connect from the command line with sqlplus s /nolog @passwd.sql sys/mypass@mytnsname but the installer just wouldnt work. An edit of the installation_dir ->webdb-2.2/owa40/owa40.vrf file did the trick. Hard code a location to a dummy pass.sys file.
After many frustrating hours 160 or so - I think I finally have a working database and a working webdb web site. Hope this info might help others.
Craig MacPherson
null

o Did you end up with 8.1.5 and WebDB2.2 in different Oracle_homes?
Yes - product/8.1.5
- product/8.0.5
o What do you mean that you used the 8.1.5 listener? My database is 8.1.5 so the tnslistener I'm using is from the 8.1.5 install - not the 8.0.5 version.
o Can you send a sample of the tnsnames.ora file that you used?
Sure - make sure you set TNS_ADMIN
# Filename: Listener.ora
LISTENER =
(ADDRESS_LIST =
(ADDRESS= (PROTOCOL= TCP)(Host= 139.142.231.213)(Port= 1521))
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(ORACLE_HOME= /oracle/product/8.1.5)
(SID_NAME = cmac)
STARTUP_WAIT_TIME_LISTENER = 0
CONNECT_TIMEOUT_LISTENER = 10
TRACE_LEVEL_LISTENER = OFF
# Filename: Tnsnames.ora
cmac =
(DESCRIPTION =
(ADDRESS = (PROTOCOL= TCP)(Host= 139.142.231.213)(Port= 1521))
(CONNECT_DATA = (SID = cmac))
test =
(DESCRIPTION =
(ADDRESS = (PROTOCOL= TCP)(Host= dmac)(Port= 1521))
(CONNECT_DATA = (SID = cmac))
null

Call SQLGLM creates core dump segmentation fault in oracle 9i database

Hi,
I am doing call to SQLGLM to get description of error message. This always worked in oracle 9i 32 bit but it does not work with 64 bit installation. I get core dump and segmentation fault.
Please help.
Altaf

wow.. I just upgraded glibc to 2.3.2... and everything works!
:D

Pro*c program causing core dump in 11g

hello every one,
I am trying to debug a pro*c program which is resulting in a core dump. It used to work fine in with Oracle 10g precompiler but is causing a core dump with 11g. When I run dbx here is what I get.
dbx wreg309
Type 'help' for help.
[using memory image in core]
reading symbolic information ...
Segmentation fault in u_fsetcodepage_3_8 at 0x9000000014f4f70 ($t1)
0x9000000014f4f70 (u_fsetcodepage_3_8+0x68) f87f0010 std r3,0x10(r31)
Any ideas what this means ? Thanks.

Hi,
I came across your problem on the Oracle Discussions Forum from back on June of 2009.
I am working with a pro*c program, in Banner 8. I getting the same message from a core dump,, that you got. I was hoping
you might have written down what you did to resolve it.
My pro*c program is key to running all the SQR code we have. So it's very important. The version of sqr that gets
linked into it is 32-bit and our environment is 64-bit. Our contract with Oracle for SQR has lapsed (it's a long
and expensive story and this is probably not the place). My whole migration to Oracle 11 is being held up by this.
I realize it's been a while since you worked on it but if you could tell me how you resolved your problem, I might be
able to do the same.
Thanks,
Tom Mayne
North Shore Community College
Danvers MA
[email protected]
cell 978 423 6867

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?
Alex

Hi 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

OCI connect error reported to cause core dump

I use OCI in my developped library. Other developers use my library for their development purposes. Last night, the oracle server went down for patching, and a user reported a core dump that I recognized it is comming from my OCI section of library.
I do OCI initialization, select, execute a query, and cleanup.
Has there been any reports as for the case, when a connection is initialized, and the server goes down after successful initialization but before calls to execute a query or commit?
Any comment???
I have the error message below, and replace prepriotory info with xxxxxxx.
thanks,
--M
Fatal NI connect error 12541, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxxxxxx)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=xxxxxx)(CID=(PROGRAM=xxxxxx@fashing)(HOST=xxxxxx)(USER=xxxxx))))
VERSION INFORMATION:
TNS for Solaris: Version 10.1.0.4.0 - Production
TCP/IP NT Protocol Adapter for Solaris: Version 10.1.0.4.0 - Production
Time: 15-FEB-2007 15:49:09
Tracing not turned on.
Tns error struct:
ns main err code: 12541
TNS-12541: TNS:no listener
ns secondary err code: 12560
nt main err code: 511
TNS-00511: No listener

We have seen core dumps in system calls earlier and have tried to debug them. We did not have the exact same stack as you but the core used to show up a stack in _malloc.
As it turned out that we had out of bound array reads (used purify to detect this) and which resulted in this dump. So the stack shown in this case could be totally misleading and the real cause could be somewhere else.
Hope this helps.

_smalloc cause core dump

Hi:
I got a core dump on _smalloc. Is it due to memory corruption on my application ? The frame stack on gdb is attached:
#0 0xff0456c8 in _smalloc () from /usr/lib/libc.so.1
(gdb) bt
#0 0xff0456c8 in _smalloc () from /usr/lib/libc.so.1
#1 0xff04570c in malloc () from /usr/lib/libc.so.1
#2 0x1fde4 in debug_malloc (nsize=11, ntype=1 '\001') at comm_utility.cpp:312
#3 0x1c144 in LNXSocket_OnReceive (sockfd=12) at comm_connect.cpp:418
#4 0x1cbc8 in Select_socket () at comm_connect.cpp:612
#5 0x1e028 in main () at comm.cpp:177
(gdb) quit
Thanks and Regards

We have seen core dumps in system calls earlier and have tried to debug them. We did not have the exact same stack as you but the core used to show up a stack in _malloc.
As it turned out that we had out of bound array reads (used purify to detect this) and which resulted in this dump. So the stack shown in this case could be totally misleading and the real cause could be somewhere else.
Hope this helps.

Dbxml Core Dump Seg Fault

Hi - We are currently using dbxml for many years successfully on CentOS and FreeBSD. Recently,we have been trying to get our dbxml application to run on Joyent's SmartOS platform.
Through the help of Joyent, we are able to build sbxml 2.5.16 binaries on smartos. Build ntes here:
https://github.com/joyent/smartos-live/issues/236
However, when we run the application, the java core dumps - both on jdk 7 and jdk 6. Same code runs find on other platforms. Core dump is included in the above post. Not sure if anyone here might have an idea on what is causing this.

Hi Lauren,
Thanks for the response. Here is what I posted about this on the smartos forums. They helped me in getting dbxml to compile on smartos. Including using an xquilla patch:
OK, so the build problem you're having there appears to be an error in the C++ source for xqilla. This diff appears to fix that:
--- pristine/dbxml-2.5.16/xqilla/src/items/DatatypeFactoryTemplate.hpp 2009-01-07 11:46:13.000000000 +0000 +++ dbxml-2.5.16/xqilla/src/items/DatatypeFactoryTemplate.hpp 2013-07-11 08:17:00.638395661 +0000 @@ -79,7 +79,7 @@ AnyAtomicType::Ptr createInstance(const XMLCh* value, const DynamicContext* context) const { - return createInstanceNoCheck(DatatypeFactoryTemplate<TYPE>::getPrimitiveTypeURI(), + return this->createInstanceNoCheck(DatatypeFactoryTemplate<TYPE>::getPrimitiveTypeURI(), DatatypeFactoryTemplate<TYPE>::getPrimitiveTypeName(), value, context); }
Here is the post about the core dump:
Hi - OK, so apparently, the newly compiled code core dumps the JVM every time I try to call the openContainer method.
At first, I thought this was a code issue or a jdk 7 issue. However, I've compiled dbxml on smartos via the instructions in above thread using both jdk 6 and jdk 7 and I get the same core dump on the same call.
Also, tested the code on jdk 7 and jdk 6 on FreeBSD, Linux and Solaris and everything works OK.
I also thought it was a problem with my data, but I tried this create a fresh container using dbxml shell.
Same thing. So it seems to be a problem with the dbxml build specific to smartos.
Anyone have any ideas on where I can start looking for a solution?
$ /opt/local/java/bin/java -d64 -cp ...
srv context: java.io.BufferedInputStream@1f2f0ce
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0x000000000028a89d, pid=4151, tid=2
JRE version: 7.0_25-b15
Java VM: Java HotSpot(TM) 64-Bit Server VM (23.25-b01 mixed mode solaris-amd64 compressed oops)
Problematic frame:
C 0x000000000028a89d
Core dump written. Default location: /home/nxd/srv/adm/core or core.4151
An error report file with more information is saved as:
/home/nxd/srv/adm/hs_err_pid4151.log
If you would like to submit a bug report, please visit:
http://bugreport.sun.com/bugreport/crash.jsp
Abort (core dumped)
========CORE DUMP
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0x000000000028a89d, pid=4116, tid=2
JRE version: 7.0_25-b15
Java VM: Java HotSpot(TM) 64-Bit Server VM (23.25-b01 mixed mode solaris-amd64 compressed oops)
Problematic frame:
C 0x000000000028a89d
Core dump written. Default location: /home/test/srv/adm/core or core.4116
If you would like to submit a bug report, please visit:
http://bugreport.sun.com/bugreport/crash.jsp
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.
T H R E A D
Current thread (0x000000000041e000): JavaThread "main" [_thread_in_native, id=2, stack(0xfffffd7ffe800000,0xfffffd7ffea00000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x000000000028a89d
Registers:
RAX=0x000000000028a89d, RBX=0x0000000000000001, RCX=0x0000000002b27ea0, RDX=0x474e5543432b2b00
RSP=0xfffffd7ffe9fec88, RBP=0xfffffd7ffe9fee30, RSI=0x0000000000000001, RDI=0x0000000000000001
R8 =0xfffffd7ffe9fecb0, R9 =0xfffffd7fbfeb8e60, R10=0x0000000000000434, R11=0xfffffd7fff202df0
R12=0x0000000002b27ec0, R13=0x0000000000000002, R14=0x0000000000000001, R15=0x0000000002b28630
RIP=0x000000000028a89d, RFLAGS=0x0000000000010286
Top of Stack: (sp=0xfffffd7ffe9fec88)
0xfffffd7ffe9fec88: fffffd7fff2a2e50 fffffd7ffe9fecc0
0xfffffd7ffe9fec98: 00000001ff3fc800 fffffd7ffe9fee50
0xfffffd7ffe9feca8: 0000000002b27ea0 fffffd7ffe9fefa0
0xfffffd7ffe9fecb8: fffffd7fff3b1422 0000000002b27ea0
0xfffffd7ffe9fecc8: 0000000002b9b530 fffffd7fbfeefd90
0xfffffd7ffe9fecd8: fffffd7ff53b7fb3 fffffd7ffe9ff190
0xfffffd7ffe9fece8: fffffd7ffe9ff090 0000000000000000
0xfffffd7ffe9fecf8: 0000000000000001 0000000000000000
0xfffffd7ffe9fed08: ffffff00000000ff 0000000002b8cf00
0xfffffd7ffe9fed18: fffffd7ffe9ff110 0000000002b1ea40
0xfffffd7ffe9fed28: 0000000002582310 0000000000000000
0xfffffd7ffe9fed38: 0000000000000001 6d2e42494c534f5f
0xfffffd7ffe9fed48: 0000000002b1ea40 0000000000000000
0xfffffd7ffe9fed58: 0000000000000000 fffffd7ffe9ff080
0xfffffd7ffe9fed68: fffffd7ffe9ff000 0000000000000000
0xfffffd7ffe9fed78: 0000000000000000 697600656e6f6e2d
0xfffffd7ffe9fed88: 2d65646f6e007765 0000000002b27ec0
0xfffffd7ffe9fed98: 0000000000000002 0000000000000001
0xfffffd7ffe9feda8: 0000000002b28630 fffffd7ffe9ff090
0xfffffd7ffe9fedb8: fffffd7fbfe81442 fffffd7fbfe3be1d
0xfffffd7ffe9fedc8: fffffd7fbfc51f28 000000000028a89d
0xfffffd7ffe9fedd8: fffffd7fbfe81108 fffffd7fbfeb8e60
0xfffffd7ffe9fede8: 0000000000000434 fffffd7ffe9fecb0
0xfffffd7ffe9fedf8: 0000000100000000 fffffd7fbfc9f120
0xfffffd7ffe9fee08: 0000000002b1ea40 0000000002b27ec0
0xfffffd7ffe9fee18: 0000000000000001 fffffd7ffe9fee50
0xfffffd7ffe9fee28: 0000000002b27ea0 fffffd7ffe9fefb0
0xfffffd7ffe9fee38: fffffd7fff2a302f 00000000000006c9
0xfffffd7ffe9fee48: 0000000002b27ea0 fffffd7ffe9fefa0
0xfffffd7ffe9fee58: fffffd7fff3b1422 0000000002b27ea0
0xfffffd7ffe9fee68: 0000000002b9b530 fffffd7fbfeefd90
0xfffffd7ffe9fee78: fffffd7ff53b7fb3 fffffd7ffe9ff190
Instructions: (pc=0x000000000028a89d)
0x000000000028a87d:
[error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xb]
Register to memory mapping:
RAX=0x000000000028a89d is an unknown value
RBX=0x0000000000000001 is an unknown value
RCX=0x0000000002b27ea0 is an unknown value
RDX=0x474e5543432b2b00 is an unknown value
RSP=0xfffffd7ffe9fec88 is pointing into the stack for thread: 0x000000000041e000
RBP=0xfffffd7ffe9fee30 is pointing into the stack for thread: 0x000000000041e000
RSI=0x0000000000000001 is an unknown value
RDI=0x0000000000000001 is an unknown value
R8 =0xfffffd7ffe9fecb0 is pointing into the stack for thread: 0x000000000041e000
R9 =0xfffffd7fbfeb8e60: _ZTSN5DbXml23DbXmlDebugHookDecoratorE+0x13040 in /home/test/srv/bdbxml.smartos_jdk7/lib/libdbxml-2.5.so at 0xfffffd7fbfc00000
R10=0x0000000000000434 is an unknown value
R11=0xfffffd7fff202df0: memcpy+0x60 in /lib/amd64/libc.so.1 at 0xfffffd7fff190000
R12=0x0000000002b27ec0 is an unknown value
R13=0x0000000000000002 is an unknown value
R14=0x0000000000000001 is an unknown value
R15=0x0000000002b28630 is an unknown value
Stack: [0xfffffd7ffe800000,0xfffffd7ffea00000], sp=0xfffffd7ffe9fec88, free space=2043k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C 0x000000000028a89d
C [libc.so.1+0x11302f] SUNW_Unwind_RaiseException+0x50
C [libstdc++.so.6.0.13+0x1380db] __cxa_throw+0x9b
C [libdbxml-2.5.so+0x281442] DbXml::SyntaxDatabase::SyntaxDatabase(const DbXml::Syntax(_db_env*, DbXml::Transaction(std::basic_string < char, std::char_traits, std::allocator >, bool, const DbXml::ContainerConfig(bool)&)*)*)+0x33a
C [libdbxml-2.5.so+0x23be1d] DbXml::Container::openIndexDbs(DbXml::Transaction(const DbXml::ContainerConfig&)*)+0x203
C [libdbxml-2.5.so+0x23c5a5] DbXml::Container::openInternal(DbXml::Transaction(const DbXml::ContainerConfig(bool)&)*)+0x649
C [libdbxml-2.5.so+0x23ce52] DbXml::Container::Container(DbXml::Manager(std::basic_string < char, std::char_traits, std::allocator >, DbXml::Transaction(const DbXml::ContainerConfig(bool)&)*)&)+0x212
C [libdbxml-2.5.so+0x26e2f1] DbXml::Manager::ContainerStore::findContainer(void&, std::basic_string < char, std::char_traits, std::allocator >, DbXml::Transaction(const DbXml::ContainerConfig(bool)&)*)+0xb7
C [libdbxml-2.5.so+0x26e4b9] DbXml::Manager::openContainer(std::basic_string < char, std::char_traits, std::allocator >, DbXml::Transaction(const DbXml::ContainerConfig(bool)&)*)+0x11b
C [libdbxml-2.5.so+0x28fa45] DbXml::XmlManager::openContainer(std::basic_string < char, std::char_traits, std::allocator >, const DbXml::XmlContainerConfig&)+0x73
C [libdbxml_java-2.5.so+0x61b68] Java_com_sleepycat_dbxml_dbxml_1javaJNI_XmlManager_1openContainerInternal_1_1SWIG_10+0x106
j com.sleepycat.dbxml.dbxml_javaJNI.XmlManager_openContainerInternal__SWIG_0(JLcom/sleepycat/dbxml/XmlManager;Ljava/lang/String;[ILjava/lang/String;)J+0
j com.sleepycat.dbxml.XmlManager.openContainerInternal(Ljava/lang/String;Lcom/sleepycat/dbxml/XmlContainerConfig;)Lcom/sleepycat/dbxml/XmlContainer;+18
j com.sleepycat.dbxml.XmlManager.openContainer(Ljava/lang/String;Lcom/sleepycat/dbxml/XmlContainerConfig;)Lcom/sleepycat/dbxml/XmlContainer;+3
j com.lightspoke.dbx.dao.DbxContainerManager.()V+411
j com.lightspoke.dbx.service.DbxRMIEngine.()V+45
j com.lightspoke.dbx.service.DbxRMIEngine.main([Ljava/lang/String;)V+29
v ~StubRoutines::call_stub
V [libjvm.so+0x54e5d1] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x5d1
V [libjvm.so+0x54e81b] void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x2b
V [libjvm.so+0x638695] jni_CallStaticVoidMethod+0x5c1
C [libjli.so+0x4d83] JavaMain+0x5e7
C [libc.so.1+0x10cfaa] _thrp_setup+0x8a
C [libc.so.1+0x10d2c0] _lwp_start+0x0
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sleepycat.dbxml.dbxml_javaJNI.XmlManager_openContainerInternal__SWIG_0(JLcom/sleepycat/dbxml/XmlManager;Ljava/lang/String;[ILjava/lang/String;)J+0
j com.sleepycat.dbxml.XmlManager.openContainerInternal(Ljava/lang/String;Lcom/sleepycat/dbxml/XmlContainerConfig;)Lcom/sleepycat/dbxml/XmlContainer;+18
j com.sleepycat.dbxml.XmlManager.openContainer(Ljava/lang/String;Lcom/sleepycat/dbxml/XmlContainerConfig;)Lcom/sleepycat/dbxml/XmlContainer;+3
j com.lightspoke.dbx.dao.DbxContainerManager.()V+411
j com.lightspoke.dbx.service.DbxRMIEngine.()V+45
j com.lightspoke.dbx.service.DbxRMIEngine.main([Ljava/lang/String;)V+29
v ~StubRoutines::call_stub
P R O C E S S
Java Threads: ( => current thread )
0x0000000002410000 JavaThread "Socket Server Thread-2" [_thread_in_native, id=20, stack(0xfffffd7ff4000000,0xfffffd7ff4200000)]
0x0000000002405000 JavaThread "KaRMI Object Queue" daemon [_thread_blocked, id=19, stack(0xfffffd7ff4400000,0xfffffd7ff4600000)]
0x00000000021eb800 JavaThread "Service Thread" daemon [_thread_blocked, id=17, stack(0xfffffd7ff4800000,0xfffffd7ff4a00000)]
0x00000000021e9800 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=16, stack(0xfffffd7ffe6ef000,0xfffffd7ffe7ef000)]
0x00000000021e6800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=15, stack(0xfffffd7ffec0f000,0xfffffd7ffed0f000)]
0x00000000021e4800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=14, stack(0xfffffd7ff4c00000,0xfffffd7ff4e00000)]
0x000000000217b800 JavaThread "Finalizer" daemon [_thread_blocked, id=13, stack(0xfffffd7ff5000000,0xfffffd7ff5200000)]
0x0000000002174800 JavaThread "Reference Handler" daemon [_thread_blocked, id=12, stack(0xfffffd7ffe000000,0xfffffd7ffe200000)]
=>0x000000000041e000 JavaThread "main" [_thread_in_native, id=2, stack(0xfffffd7ffe800000,0xfffffd7ffea00000)]
Other Threads:
0x000000000216c000 VMThread [stack: 0xfffffd7ffe2af000,0xfffffd7ffe3af000] [id=11]
0x0000000002205800 WatcherThread [stack: 0xfffffd7ffdeff000,0xfffffd7ffdfff000] [id=18]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
PSYoungGen total 19712K, used 16342K [0x00000000eaa00000, 0x00000000ec000000, 0x0000000100000000)
eden space 16896K, 96% used [0x00000000eaa00000,0x00000000eb9f5a00,0x00000000eba80000)
from space 2816K, 0% used [0x00000000ebd40000,0x00000000ebd40000,0x00000000ec000000)
to space 2816K, 0% used [0x00000000eba80000,0x00000000eba80000,0x00000000ebd40000)
ParOldGen total 43008K, used 0K [0x00000000c0000000, 0x00000000c2a00000, 0x00000000eaa00000)
object space 43008K, 0% used [0x00000000c0000000,0x00000000c0000000,0x00000000c2a00000)
PSPermGen total 22528K, used 7661K [0x00000000bae00000, 0x00000000bc400000, 0x00000000c0000000)
object space 22528K, 34% used [0x00000000bae00000,0x00000000bb57b450,0x00000000bc400000)
Card table byte_map: [0xfffffd7ff8c00000,0xfffffd7ff8e2a000] byte_map_base: 0xfffffd7ff8629000
Polling page: 0xfffffd7fff000000
Code Cache [0xfffffd7ff9000000, 0xfffffd7ff9400000, 0xfffffd7ffc000000)
total_blobs=371 nmethods=41 adapters=283 free_code_cache=48554Kb largest_free_block=49715392
Compilation events (10 events):
Event: 0.848 Thread 0x00000000021e9800 nmethod 34 0xfffffd7ff9072a90 code [0xfffffd7ff9072be0, 0xfffffd7ff9072c78]
Event: 0.848 Thread 0x00000000021e9800 35 java.util.ArrayList::get (11 bytes)
Event: 0.848 Thread 0x00000000021e9800 nmethod 35 0xfffffd7ff90788d0 code [0xfffffd7ff9078a20, 0xfffffd7ff9078ad8]
Event: 0.854 Thread 0x00000000021e9800 36 ! sun.misc.URLClassPath$JarLoader::getResource (91 bytes)
Event: 0.894 Thread 0x00000000021e9800 nmethod 36 0xfffffd7ff9080490 code [0xfffffd7ff9080840, 0xfffffd7ff9082128]
Event: 0.907 Thread 0x00000000021e9800 37 java.io.UnixFileSystem::parentOrNull (118 bytes)
Event: 0.917 Thread 0x00000000021e9800 nmethod 37 0xfffffd7ff907ddd0 code [0xfffffd7ff907df40, 0xfffffd7ff907e598]
Event: 0.968 Thread 0x00000000021e6800 nmethod 32 0xfffffd7ff908bf50 code [0xfffffd7ff908c660, 0xfffffd7ff90909c8]
Event: 1.019 Thread 0x00000000021e9800 38 java.util.Arrays::copyOf (19 bytes)
Event: 1.021 Thread 0x00000000021e9800 nmethod 38 0xfffffd7ff908a250 code [0xfffffd7ff908a3a0, 0xfffffd7ff908a578]
GC Heap History (0 events):
No events
Deoptimization events (6 events):
Event: 0.351 Thread 0x000000000041e000 Uncommon trap -34 fr.pc 0xfffffd7ff9062f04
Event: 0.352 Thread 0x000000000041e000 Uncommon trap -34 fr.pc 0xfffffd7ff9062f04
Event: 0.438 Thread 0x000000000041e000 Uncommon trap -83 fr.pc 0xfffffd7ff9067068
Event: 0.638 Thread 0x000000000041e000 Uncommon trap -83 fr.pc 0xfffffd7ff9067908
Event: 0.668 Thread 0x000000000041e000 Uncommon trap -83 fr.pc 0xfffffd7ff9076094
Event: 0.669 Thread 0x000000000041e000 Uncommon trap -12 fr.pc 0xfffffd7ff9065848
Internal exceptions (10 events):
Event: 1.079 Thread 0x000000000041e000 Threw 0x00000000eb94b5b8 at /export/HUDSON/workspace/jdk7u25-2-build-solaris-amd64-product/jdk7u25/hotspot/src/share/vm/prims/jvm.c
Event: 1.563 Thread 0x000000000041e000 Threw 0x00000000eb972960 at /export/HUDSON/workspace/jdk7u25-2-build-solaris-amd64-product/jdk7u25/hotspot/src/share/vm/prims/jvm.c
Event: 1.564 Thread 0x000000000041e000 Threw 0x00000000eb9756c0 at /export/HUDSON/workspace/jdk7u25-2-build-solaris-amd64-product/jdk7u25/hotspot/src/share/vm/prims/jvm.c
Event: 1.564 Thread 0x000000000041e000 Threw 0x00000000eb97fc60 at /export/HUDSON/workspace/jdk7u25-2-build-solaris-amd64-product/jdk7u25/hotspot/src/share/vm/prims/jvm.c
Event: 1.565 Thread 0x000000000041e000 Threw 0x00000000eb983ed0 at /export/HUDSON/workspace/jdk7u25-2-build-solaris-amd64-product/jdk7u25/hotspot/src/share/vm/prims/jvm.c
Event: 1.565 Thread 0x000000000041e000 Threw 0x00000000eb98d390 at /export/HUDSON/workspace/jdk7u25-2-build-solaris-amd64-product/jdk7u25/hotspot/src/share/vm/prims/jvm.c
Event: 1.566 Thread 0x000000000041e000 Threw 0x00000000eb992830 at /export/HUDSON/workspace/jdk7u25-2-build-solaris-amd64-product/jdk7u25/hotspot/src/share/vm/prims/jvm.c
Event: 1.566 Thread 0x000000000041e000 Threw 0x00000000eb996070 at /export/HUDSON/workspace/jdk7u25-2-build-solaris-amd64-product/jdk7u25/hotspot/src/share/vm/prims/jvm.c
Event: 1.567 Thread 0x000000000041e000 Threw 0x00000000eb9a1d10 at /export/HUDSON/workspace/jdk7u25-2-build-solaris-amd64-product/jdk7u25/hotspot/src/share/vm/prims/jvm.c
Event: 1.738 Thread 0x000000000041e000 Threw 0x00000000eb9a6840 at /export/HUDSON/workspace/jdk7u25-2-build-solaris-amd64-product/jdk7u25/hotspot/src/share/vm/prims/jvm.c
Events (10 events):
Event: 1.565 loading class 0x0000000002a678c0
Event: 1.565 loading class 0x0000000002a678c0 done
Event: 1.566 loading class 0x0000000002a67960
Event: 1.566 loading class 0x0000000002a67960 done
Event: 1.566 loading class 0x00000000022d9f00
Event: 1.566 loading class 0x00000000022d9f00 done
Event: 1.567 loading class 0x0000000002a67eb0
Event: 1.567 loading class 0x0000000002a67eb0 done
Event: 1.738 loading class 0x00000000022d9d40
Event: 1.738 loading class 0x00000000022d9d40 done
Dynamic libraries:
0x0000000000400000 /opt/local/jdk1.7.0_25/bin/amd64/dbxrmijvm
0xfffffd7ffd85c000 /usr/lib/amd64/libthread.so.1
0xfffffd7ffd700000 /opt/local/jdk1.7.0_25/bin/amd64/../../jre/lib/amd64/jli/libjli.so
0xfffffd7ffe56f000 /usr/lib/amd64/libdl.so.1
0xfffffd7fff190000 /usr/lib/amd64/libc.so.1
0xfffffd7ffc1a0000 /opt/local/jdk1.7.0_25/jre/lib/amd64/server/libjvm.so
0xfffffd7ffea40000 /usr/lib/amd64/libsocket.so.1
0xfffffd7ffd85b000 /usr/lib/amd64/libsched.so.1
0xfffffd7ffc180000 /usr/lib/amd64/libm.so.1
0xfffffd7ffc150000 /usr/lib/amd64/libCrun.so.1
0xfffffd7ffdaef000 /usr/lib/amd64/libdoor.so.1
0xfffffd7ffc110000 /usr/lib/amd64/libdemangle.so.1
0xfffffd7ffeee0000 /usr/lib/amd64/libm.so.2
0xfffffd7ffed10000 /usr/lib/amd64/libnsl.so.1
0xfffffd7ffeab0000 /usr/lib/amd64/libmd.so.1
0xfffffd7ffea90000 /usr/lib/amd64/libmp.so.2
0xfffffd7ffc0f0000 /opt/local/jdk1.7.0_25/jre/lib/amd64/libverify.so
0xfffffd7ffc0a0000 /opt/local/jdk1.7.0_25/jre/lib/amd64/libjava.so
0xfffffd7ffe670000 /usr/lib/amd64/libscf.so.1
0xfffffd7ffeba0000 /usr/lib/amd64/libuutil.so.1
0xfffffd7ffead0000 /usr/lib/amd64/libgen.so.1
0xfffffd7ffedb0000 /usr/lib/amd64/libnvpair.so.1
0xfffffd7ffe650000 /usr/lib/amd64/libsmbios.so.1
0xfffffd7ffc070000 /opt/local/jdk1.7.0_25/jre/lib/amd64/libzip.so
0xfffffd7ffc040000 /opt/local/jdk1.7.0_25/jre/lib/amd64/libnet.so
0xfffffd7ffc020000 /opt/local/jdk1.7.0_25/jre/lib/amd64/libnio.so
0xfffffd7ffeb20000 /usr/lib/amd64/librt.so.1
0xfffffd7ffc000000 /usr/lib/amd64/libsendfile.so.1
0xfffffd7ffdd30000 /home/test/srv/bdbxml.smartos_jdk7/lib/libdb_java-4.8.so
0xfffffd7ffdb60000 /usr/lib/amd64/libresolv.so.2
0xfffffd7ffeacd000 /usr/lib/amd64/libpthread.so.1
0xfffffd7ffe630000 /usr/lib/amd64/libgcc_s.so.1
0xfffffd7ffe220000 /home/test/srv/bdbxml.smartos_jdk7/lib/libdbxml_java-2.5.so
0xfffffd7ffd950000 /home/test/srv/bdbxml/lib/libdb-4.8.so
0xfffffd7fc0400000 /home/test/srv/bdbxml/lib/libxqilla.so.5
0xfffffd7fc0000000 /home/test/srv/bdbxml/lib/libxerces-c-3.0.so
0xfffffd7fbfc00000 /home/test/srv/bdbxml/lib/libdbxml-2.5.so
0xfffffd7ff5280000 /usr/lib/amd64/libstdc++.so.6
VM Arguments:
jvm_args: -Xss2048k -Djava.library.path=/home/test/srv/bdbxml/lib:/home/test/bdb/lib:/usr/lib:/usr/local/lib:/lib:/usr/lib/amd64: -Djava.rmi.server.codebase=/home/test/srv/lib/dbxrmi.jar -Duka.karmi.config=/home/test/srv/adm/.karmi.property -Djava.rmi.server.hostname=test.gaoxiong -Djava.security.policy=/home/test/adm/DbxRMI.policy -Dlog4j.configuration=file:/home/test/adm/log4j.xml
java_command: com.lightspoke.dbx.service.DbxRMIEngine
Launcher Type: SUN_STANDARD
Environment Variables:
JAVA_HOME=/opt/local/java
PATH=/opt/local/java/bin:/home/test/srv/bdbxml/bin:/opt/local/java/bin:/home/test/srv/bdbxml/bin:/opt/local/java/bin:/home/test/srv/bdbxml/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/usr/sbin:/home/test/srv/bdbxml/bin:
LD_LIBRARY_PATH=/home/test/srv/bdbxml/lib:/home/test/bdb/lib:/usr/lib:/usr/local/lib:/lib:/usr/lib/amd64:
SHELL=/bin/bash
Signal Handlers:
SIGSEGV: [libjvm.so+0x11b37b4], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGBUS: [libjvm.so+0x11b37b4], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGFPE: [libjvm.so+0x53fc78], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGPIPE: [libjvm.so+0x53fc78], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGXFSZ: [libjvm.so+0x53fc78], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGILL: [libjvm.so+0x53fc78], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGQUIT: [libjvm.so+0xff8ea8], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGHUP: [libjvm.so+0xff8ea8], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGINT: [libjvm.so+0xff8ea8], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGTERM: [libjvm.so+0xff8ea8], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIG39: [libjvm.so+0xffd27c], sa_mask[0]=0x00000000, sa_flags=0x00000008
SIG40: [libjvm.so+0x53fc78], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
S Y S T E M
OS: SmartOS x86_64
Copyright 2010 Sun Microsystems, Inc. All Rights Reserved.
Copyright 2010-2012 Joyent, Inc. All Rights Reserved.
Use is subject to license terms.
See uname -v for assembly date and time.
uname:SunOS 5.11 joyent_20130530T224720Z i86pc
(T2 libthread)
rlimit: STACK 10240k, CORE infinity, NOFILE 65536, AS infinity
load average:0.01 0.00 0.00
CPU:total 8 (4 cores per cpu, 1 threads per core) family 6 model 15 stepping 11, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, tsc
Memory: 4k page, physical 4194304k(4142372k free)
vm_info: Java HotSpot(TM) 64-Bit Server VM (23.25-b01) for solaris-amd64 JRE (1.7.0_25-b15), built on Jun 5 2013 21:57:39 by "" with Sun Studio 12u1
time: Tue Aug 6 01:12:44 2013
elapsed time: 2 seconds

Xcelsius Causes core dump when importing a workbook

When I try to import a certain workbook a message comes up saying that the server is busy and switch to the application. Switching to the application does nothing and the only way to get out of this is to kill Xcelsius which then causes a blue screen and core dump. Does anyone know how to address this problem?

Hi there,
I have posted a suggestion via this link [Server Busy issue with Xcelsius|Re: Server Busy; or you can refer to my following steps:
1. Open the Windows Task Manager.
2. Go to tab Applications and look for task Microsoft Excel - Compatibility Check and double click on it. This action will bring you to the small windows of Excel which alerts you about the compatibility check of the Excel file.
3. Click button Continue to process the import.
4. Go back to Xcelsius and click Retry button to import the Excel sheet.
Well, the issue is solved.
Hopefully this tips will be useful for you.
Cheers,
Danny Pham

/AdminMain causes core dump

I've installed WebLogic on a Solaris (SPARC) 2.7, JDK 1.2.2.
I'm just going through WebLogic and testing the various functionalities.
When I load then /AdminMain page the first time, it works beutifully.
However, if I click on any of the links or reload the page, the web server
goes down in flames (Core Dump)
Any Ideas?
I have attached two files, the one listing the webserver's output at startup
and the second being the webserver's output when it dies.
Regards
Johan Locke
http://www.JohanLocke.co.za
Certified Oracle 8 & 8i DBA
Certified Oracle Developer
Dimension Data i-Commerce Internet Services
Direct Line: +27 11 283 5789
mailto:[email protected]
http://www.is.co.za
[webLogic_startup.txt]
[web_logic_dump.txt]

Yes there is a problem with JD 1.2.2_05a. It's documented on our platform support
page
Check out: http://www.weblogic.com/platforms/index.html#solaris
Kumar
Cliff Hafen wrote:
I have the same problem and can't go back to an earlier jdk. Running Solcaris
2.7, WL5.1sp4. I can provide more info if needed.
Cliff
First Last wrote:
I got the same problem with 122-05a but the problem goes away once I change it
back to 121_04. Is there a problem with running weblogic51 under jdk122_05a ?
Michael Girdley wrote:
Are you on JDK version 1.2.2_05 a?
Thanks,
Michael
Michael Girdley
BEA Systems Inc
"Johan Locke" <[email protected]> wrote in message
news:[email protected]..
I've installed WebLogic on a Solaris (SPARC) 2.7, JDK 1.2.2.
I'm just going through WebLogic and testing the various functionalities.
When I load then /AdminMain page the first time, it works beutifully.
However, if I click on any of the links or reload the page, the web server
goes down in flames (Core Dump)
Any Ideas?
I have attached two files, the one listing the webserver's output atstartup
and the second being the webserver's output when it dies.
Regards
Johan Locke
http://www.JohanLocke.co.za
Certified Oracle 8 & 8i DBA
Certified Oracle Developer
Dimension Data i-Commerce Internet Services
Direct Line: +27 11 283 5789
mailto:[email protected]
http://www.is.co.za

ReplyTo header field from Java JMS read by C JMS API causes core dump...

Hi,

First step is to add the option -Xcheck:jni to your java command line. It will flag common JNI errors.
If that doesn't identify the problem, then compile your jni code with debugging symbols (-g) and add the following option to the java command line when you run your test: -XX:+ShowMessageBoxOnError. When you hit the problem again, the VM will keep the process alive instead of calling abort(). Then you can use dbx to attach to the live process and should be able to get a better idea of what went wrong.

OCILogon Causing Core Dump

I have created a shared lib on both AIX 5.2 and Tru64 UNIX 5.1A which calls the OCILogon() function to logon to the database. In a driver program, I dynamically load the shared library using dlopen() and call the function that contains the OCILogon() call. The driver program crashes when it tries to exit after calling dlclose(). Looking at the stack trace on Tru64 it appears to crash unloading the libc.so shared library.
0 0x3ff800ddee8 in exit(0x3ffc008a060, 0x0, 0x1000000, 0x3ffc0184000, 0x0, 0x1) in /usr/shlib/libc.so#1 0x3ff800ddee4 in exit(0x3ffc008a060, 0x0, 0x1000000, 0x3ffc0184000, 0x0, 0x1) in /usr/shlib/libc.so
#2 0x1200013f8 in __start(0x3ffc008a060, 0x0, 0x1000000, 0x3ffc0184000, 0x0, 0x1) in driver
On AIX I am not able to get a stack trace. The reason that I think the problem is in the OCILogon function is because when I take it out, the code does not crash. Any ideas?

My guess is that this is purely security/access permissions problem. Client probably needs to open up security on port or something to allow permissions. Perhaps something in java.policy can be edited to allow? Hope that helps somewhat.

[SOLVED] Adobe Reader (acroread) Segmentation Fault (KDE)

Hello everyone!
I've been playing with arch quite a long time and I have a problem with the acroread package, which I installed from the AUR.
Adobe Reader will never start and this is the output I get:
$ acroread
dirname: missing operand
Try 'dirname --help' for more information.
Segmentation fault (core dumped)
I did run strace and the output I got (last few lines) is:
access("/etc/gtk-2.0/gtkrc.en_US", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/gtk-2.0/gtkrc.en", F_OK) = -1 ENOENT (No such file or directory)
lstat64("/home/errikos/.gtkrc-2.0", 0xfffffffffff5e7f4) = -1 ENOENT (No such file or directory)
access("/home/errikos/.gtkrc-2.0.en_US", F_OK) = -1 ENOENT (No such file or directory)
access("/home/errikos/.gtkrc-2.0.en", F_OK) = -1 ENOENT (No such file or directory)
lstat64("/home/errikos/.gtkrc-2.0-kde4", {st_mode=S_IFREG|0644, st_size=328, ...}) = 0
open("/home/errikos/.gtkrc-2.0-kde4", O_RDONLY|O_LARGEFILE) = 5
read(5, "# This file was written by KDE\n#"..., 4000) = 328
lstat64("/usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc", {st_mode=S_IFREG|0644, st_size=6131, ...}) = 0
open("/usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc", O_RDONLY|O_LARGEFILE) = 6
read(6, "# this file is part of the oxyge"..., 4000) = 4000
access("/home/errikos/.gtk-2.0/2.10.0/x86_64-unknown-linux-gnu/engines/liboxygen-gtk.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/errikos/.gtk-2.0/2.10.0/x86_64-unknown-linux-gnu/engines/liboxygen-gtk.la", F_OK) = -1 ENOENT (No such file or directory)
access("/home/errikos/.gtk-2.0/2.10.0/engines/liboxygen-gtk.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/errikos/.gtk-2.0/2.10.0/engines/liboxygen-gtk.la", F_OK) = -1 ENOENT (No such file or directory)
access("/home/errikos/.gtk-2.0/x86_64-unknown-linux-gnu/engines/liboxygen-gtk.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/errikos/.gtk-2.0/x86_64-unknown-linux-gnu/engines/liboxygen-gtk.la", F_OK) = -1 ENOENT (No such file or directory)
access("/home/errikos/.gtk-2.0/engines/liboxygen-gtk.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/errikos/.gtk-2.0/engines/liboxygen-gtk.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib32/gtk-2.0/2.10.0/x86_64-unknown-linux-gnu/engines/liboxygen-gtk.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib32/gtk-2.0/2.10.0/x86_64-unknown-linux-gnu/engines/liboxygen-gtk.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib32/gtk-2.0/2.10.0/engines/liboxygen-gtk.so", F_OK) = 0
stat64("/usr/lib32/gtk-2.0/2.10.0/engines/liboxygen-gtk.so", {st_mode=S_IFREG|0755, st_size=1309120, ...}) = 0
open("/usr/lib32/gtk-2.0/2.10.0/engines/liboxygen-gtk.so", O_RDONLY|O_CLOEXEC) = 7
read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220-\4\0004\0\0\0"..., 512) = 512
fstat64(7, {st_mode=S_IFREG|0755, st_size=1309120, ...}) = 0
mmap2(NULL, 1314324, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 7, 0) = 0xf0f20000
mprotect(0xfffffffff105b000, 4096, PROT_NONE) = 0
mmap2(0xfffffffff105c000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 7, 0x13b) = 0xf105c000
close(7) = 0
mprotect(0xfffffffff105c000, 12288, PROT_READ) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)
I am running Arch with KDE.
Should it find all those files it is not finding? Could they be part of the problem?
I did a Google search, but got nowhere until now.
Last edited by errikosd (2013-05-08 01:10:04)

Well, I found a workaround, for those who really need acroread and want it well integrated into the KDE environment.
The solution is to use another KDE look-alike theme, QtCurve, instead of the "problematic" oxygen-gtk for GTK2 applications.
What you have to do is install the following packages from the AUR:
gtk-engines
qtcurve-gtk2
qtcurve-kde
lib32-qtcurve-gtk2
and also lib32-gtk-engines if it isn't resolved as a dependency.
You will also need to install the kde-gtk-config package from the AUR.
Then go to: KDE System Settings > Application Appearance > GTK, select QtCurve as the GTK2 theme and enjoy acroread and other GTK2 applications (well not fully, but the QtCurve theme is OK) integrated into your KDE desktop!
PS1: QtCurve is not (yet?) available for GTK3, so I left oxygen-gtk there.
PS2: Status changed to solved.

Solaris 9 + Checkpoint R55 CORE DUMPING, HELP!

Here are the list of revisions I have installe donto the machine:
Solaris 9 (core install) (09/04)
Checkpoint R55 (HFA 15)
Recommended 9 (07/18/05).
When we are running the commands 'cpstart' and 'cpstop' the Solaris 9 OS follows by doing 2/3 core dumps each time. We have redone this box to check if its a fault with the install but it still core dumps each time with use the 'cpstart' and 'cpstop' commands to start and stop the Checkpoint R55 software.
>
# cpstop
Segmentation Fault (core dumped)
Segmentation Fault (core dumped)
VPN-1/FW-1 stopped
SVN Foundation: cpd stopped....... etc.
Has anyone got and ideas or suggestions?
its has been suggested to send this onto our Solaris VAR for interrogation to have the dumps put through some sort of analyser, but we have no support (media kit only) HELP!

we're also unable to connect to the box using the r55 checkpoint software (if anyone knows about this)
"....make sure your server is up and running and that you're defined as a GUI client".
it WAS working before appliying the Recommended_9 patch

Service pack 5 core dumping

We were having the same trouble with 5.1.0 SP9
using Oracle Client 8.1.5, Oracle Server 8.1.7.
Also using Solaris 2.7 and JDK 1.3.1.
and OCI JDBC drivers supplied by Weblogic.
This gave us sporatic failures identical to below.
Thin drivers were too slow and also produced other
'wierd' side effects.
SP10 allows upgrade to Oracle 8.1.7 client drivers.
The combination upgrade to SP10 and Oracle 8.1.7 client
drivers appears to fix the problem.
--Rich
================
Kumar Allamraju <[email protected]> wrote:
type-4 driver is pure java. It doesn't use native code at all..
Kumar
arun wrote:
I treid using Oracle's type-4 jdbc driver and it work fine - no coredumps so far!
Arun.
Kumar Allamraju wrote:
I don't think SP-5 is causing core dump. The following stack trace
doesn't show me that JVM has core
dumped
on this particular native call. Post the full thread dump here ,so that we can analyze further.
If you take out SP4, don't you see this problem? Could you try type-4driver also?
Kumar
arun wrote:
Hi,
I'm getting a core dump on
SunOS packet 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-250
WebLogic Build: 5.1.0 Service Pack 5 08/17/2000 07:21:55 #79895
I'm including the relevant(?) stack trace below:
"ExecuteThread-9" (TID:0xf1171580, sys_thread_t:0x552570, state:R,
native ID:0x13) prio=5
at weblogic.db.oci.OciCursor.execAndFetch(Native Method)
at weblogic.db.oci.OciCursor.oci_execAndFetch(OciCursor.java,
Compiled Code)
at weblogic.jdbcbase.oci.Statement.executeQuery(Statement.java,
Compiled Code)
at weblogic.jdbc.pool.Statement.executeQuery(Statement.java,
Compiled Code)
at com.avulet.db.DataDock.getUser(DataDock.java, Compiled
Code)
at com.avulet.db.DataDock.getUser(DataDock.java, CompiledCode)
at
com.avulet.webapp.archive.ArchiveBean.getTop(ArchiveBean.java,Compiled
Code)
at
jsp_servlet._reservation._createRes._jspService(_createRes.java,
Compiled Code)
at weblogic.servlet.jsp.JspBase.service(JspBase.java, Compiled
Code)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java,
Compiled Code)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java,
Compiled Code)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java,
Compiled Code)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java,
Compiled Code)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java,
Compiled Code)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java,
Compiled Code)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java,
Compiled Code)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java,
Compiled Code)
This started happening ever since I applied the service pack 5.Any
ideas on how to get past this?
Thanks,
Arun.

SRW.APPLY_DEFINITION cause (core dumped) Segmentation fault

Similar Messages

Maybe you are looking for