Core dump using OCI HP 32 bit package
Does any one successfully run OCI application on HP using 32 bit libraries?
I got core dump at the end of running application, around desctruction part. Following are the statement I got from GDB:
#0 0xc005db14 in pthread_mutex_destroy+0x18 () from /usr/lib/libpthread.1
#1 0xc021efd8 in __thread_mutex_free+0x40 () from /usr/lib/libc.2
#2 0xc0abb4b8 in HPMutexWrapper::~HPMutexWrapper+0x48 () from /usr/lib/libstd_v2.2
#3 0x613c in std::basic_string<char,std::char_traits<char>,std::allocator<char>>::_C_unlink (this=0x7bff153c) at /opt/aCC/include_std/string:1002
#4 0xccd0 in ociWrapper::cursor::~cursor (this=0x7bff1538, #free=2) at /vobs/Guru2/IDCE/ociWrapper/ociWrapper.cpp:220
#5 0x65a8 in main () at /vobs/Guru2/Oracle/HP-UX/sdk/demo/oci_wrapper_insert.cpp:73
If I build my application in 64 bit using OCI 64 bit package, no problem at all. But I have to make my application work in 32 bit so that I can not simply switch to 64 bit.
Please give me some help. Thanks.
I got the problem solved myself. The core dump happens when use OCI 32 bit libraries with STL string. It cores at destroying the STL string.
Add the option "-mt" to the compile command, the problem will go away.
Similar Messages
-
Weblogic 6.1 sp5 core dump by OCI driver
I have encountered a core dump problem on weblogic server 6.1 SP5 the error message
as below, I am using weblogic oci driver for oracle "libweblogicoci37.so" , anyone
can help?
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 4 occurred at PC=0x242795c
Function name=(N/A)
Library=(N/A)
NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.Galen Boyer wrote:
On Sun, 28 Mar 2004, [email protected] wrote:
Galen Boyer wrote:
On Sat, 27 Mar 2004, [email protected] wrote:
One way to get a substantial boost in reliability is to switch
to the latest appropriate Oracle thin driver.But then you can suffer performance losses.Actually, the latest oracle thin drivers are very fast. The 10g
driver in particular. Well, we are on 9i here and we have lots of CLOB and BLOB
operations. Understood. The latest should work. (How comfortable does that make you ;) )
It is a sad choice we used to have to make between
faster-but-buggy homicidal old OCI code (wherein a bug in one
module can cause a segfault in an innocent unrelated module's
execution, and bring down a whole JVM) and the reliability of
Java. Fortunately, the future is at hand. The future is at hand? I do believe you are starting to sound a
bit like an evangelist. :-)Yep. Back in '96 when we wrote and marketed all the first JDBC drivers
for MS SQLServer, Oracle, Informix and Sybase, we did it solely
so enable our application server to be able to do real work. We were all
absolutely sure the driver market would dry up in 6 months as all the
DBMS vendors made excellent free type-4 drivers. We were over-optimistic.
Sybase's driver still requires you to install non-standard tables and
procedures in the DBMS. Oracle drivers are sloutching toward sufficiency,
but their first GA driver had a hard-wired value of READ_UNCOMMITTED
for getTransactionIsolation, and if you tried setTransactionIsolation
of either READ_COMMITTED or SERIALIZABLE, the driver would throw an
exception! We actually had a weblogic workaround to intercept this
jdbc call and send the "ALTER SESSION " to do what the customer wanted!
At the same time we had a major struggle to get Oracle to admit that
in spite of their documentation, OCI was not threadsafe (killing our
OCI-based driver in weblogic applications) until 7.1.4 on solaris
and NT, and 8.0.5 on other platforms. Did you know they had separate
codelines for OCI on each platform? For a while each platform's OCI
had a different hard-wired limit of the number of simultaneous connections
on client could have? For a while that limited what our application server
could do. OCI was written for simple teller-like client applications.
The new thin drivers take on more of the possible client-side
processing, and can do RAC failover etc. JoeOh well. I for one am a bit skeptical that Oracle is going to
fix java driver bugs before OCI bugs and I don't have any reason
to commit to any "platform independent" solution like java's thin
driver. We are completely based on Oracle here and we have a
J2EE solution for the app just cause we had to choose something.
If thin is better, than we will go with that.The last highest-level talks I had with Oracle folks they indicated that
they wanted everyone to go thin. OCI was a headache for them. Their
OCI code was undocumented and all the original experts had left the company.
That was in 2000 or so, so it is likely better now. They may well have
invested a lot of reverse-documentation by now.
One of the benefits of Java is the reliability. I think you'll
ultimately be happier with the thin. We do want you successful.
Joe -
We are getting the following core dump on an OCI call ....
fde12fe0 kpucHTDelete (f872ac, f68380, 0, 31, 203d203a, f7c684) + 9c
fddae464 kpursetstmttext (f872ac, f871c8, 8, fdd9fa84, d49c40,
fe449a64) + 9c
fddae61c kpurclientparse (f872ac, f7cc7c, f682e8, 9a, 400000, d49a14) +
28
fddae928 kpureq (f77338, f7cc7c, f682e8, 9a, 1, 0) + 150
fde69efc OCIStmtPrepare (f872ac, f7cc7c, f682e8, 9a, 1, 0) + 7c
004642b4 arb_internal_process_query (f68138, f68154, 0, 0, ffbfae28,
1037de2) + 594
00453178 arb_next_row (f68138, 10d6c58, 1037d88, ffbfaea4, 29, 2e) + 18
0028d64c ???????? (f61828, 1067d00, ffbfafa8, 0, 0, 80808080)
0028db68 list_abp_product_types (f61828, 1067d00, ffbfafa8, 1037c10,
1067d00, 1067d00) + 20
002e78a0 insert_abp_serv_inst_product (f61828, 103ee18, 1, ffbfb46c,
fecd29e8, fd9f0240) + 278
0014feb8 GTEAB_InsertMRC (ffbfbd54, ffbfc2d0, ffbfbda7, ffbfc2d0,
ffbfbd98, ffbfc2d0) + 33b8
000d193c run_pieces (e2f820, e33528, e35aa0, ffbfc3d4, e3f8c0, 0) + 1dc
000d11b0 handle_request (e2f820, 5, e33528, e34e48, 0, 0) + 278
000ce1a8 process_request (e2f820, 5, e33528, e34e48, fed73700,
fd9f2a00) + c8
000cdfd0 main (3, ffbfc9ac, ffbfc9bc, 79a000, fd9f0180, fd9f01c0) +
568
000cce08 _start (0, 0, 0, 0, 0, 0) + 108
It always seems to happen on the kpucHTDelete call. I have searched the net for kpucHTDelete but found nothing.
Can someone
1. describe what kpucHTDelete is supposed to accomplish and why it might fail.
2. Is there a way to trace / log OCI ?
3. Any other suggestions to help with this problem.
Thanks in advance.
GaryWell, it seems to me a bug.
You can enable tracing using NET 8 Assistant, and from there go to the tracing tab.
Select the SUPPORT trace level from the following pull down menu located in the Client Information section:
OFF: Tracing disabled.
USER: Trace information applicable for users.
ADMIN: Trace information applicable for database administrators.
SUPPORT: Trace information applicable for customer support staff.
Enter a valid directory name in the Trace Directory field in the Client Information section. This directory specification is where trace files are written on either the client or server.
Enter a valid filename in the Trace File field in the Client Information section. This filename specifies the name of the trace file on the client or server.
Click on the "unique File Trace Name" checkbox if you want a unique identifier appended to each new trace file created.
Save your configuration.
You can check the SQLNET.ORA file found in the net80/admin directory path to verify that tracing is enabled. There is an entry called TRACE_LEVEL_CLIENT=SUPPORT located in that file and entries that indicate the log file location and name that you specified in the Oracle Net8 Assistant.
regards -
XMLType table Core Dump using CLOB
I've created an object based XMLType table based on a valid XML Schema. The Schema has an element which has been declared as a CLOB.
<xs:element name="complete_entry" xdb:SQLType="CLOB" xdb:SQLName="complete_entry"/>
This registers ok with Oracle and the object that this element is in shows the element as a CLOB as expected.
However when performing a insert into this table, SQLPlus gives and end-of-communication error and the server core dumps.
A PL/SQL function retreives an XML file from the file system for insert, here is the code for the function:
create or replace function getClobDocument(
filename in varchar2,
charset in varchar2 default NULL)
return CLOB deterministic
is
file bfile := bfilename('DIR',filename);
charContent CLOB := ' ';
targetFile bfile;
lang_ctx number := DBMS_LOB.default_lang_ctx;
charset_id number := 0;
src_offset number := 1 ;
dst_offset number := 1 ;
warning number;
begin
if charset is not null then
charset_id := NLS_CHARSET_ID(charset);
end if;
targetFile := file;
DBMS_LOB.fileopen(targetFile, DBMS_LOB.file_readonly);
DBMS_LOB.LOADCLOBFROMFILE(charContent, targetFile,
DBMS_LOB.getLength(targetFile), src_offset, dst_offset,
charset_id, lang_ctx,warning);
DBMS_LOB.fileclose(targetFile);
return charContent;
end;
The function is called like so:
INSERT INTO boss_contracts
VALUES(XMLTYPE(getCLOBDocument('contract_82.xml','UTF8')));
This works perfectly when the element is declared as a string and Oracle converts it to a varchar2(4000), but core dumps when it is a CLOB.
I need this element to be able to handle more than 4k of data.
please help,
Paul Linney
[email protected]void print_affect(struct oci_connection* conn, OCIStmt* sh) {
sb2 rowCount;
ub4 sizep = sizeof(sb2);
OCIAttrGet(sh, OCI_HTYPE_STMT,&rowCount,
&sizep,OCI_ATTR_ROW_COUNT, conn->err);OCI_ATTR_ROW_COUNT is a ub4 attribute, not a sb2 one.
ub4 rowCount = 0;
ub4 size = sizeof(rowCount);
--DD -
Core dump using iostream with Sun Studio 8
I'm running on Solaris 9 using C++ compiler Sun Studio 8, and encoutered a very strange problem.
My application failed with a core and here is the stack.
[1] t_splay(0x3774b470, 0x387a0ec0, 0x389aec60, 0x39e5ef1f, 0x3774b470, 0x1), at 0xfc347930
[2] t_delete(0x387a0ec0, 0x80, 0x39be9748, 0x20, 0x383ccd20, 0x0), at 0xfc347698
[3] mallocunlocked(0x80, 0x0, 0x21b08, 0xfc3bc000, 0x10, 0x20), at 0xfc346d40
[4] malloc(0x80, 0xfbaa7400, 0x1, 0x759c40, 0x0, 0x0), at 0xfc346b74
[5] operator new(0x80, 0x0, 0xd3a18, 0x759c74, 0x0, 0x8345fc), at 0x760c10
[6] strstreambuf::overflow(0xf41f6e28, 0x29, 0xf41f6e28, 0x39fe0e88, 0x39fe0e88, 0x8345fc), at 0x75bb1c
[7] streambuf::xsputn(0xf41f6e28, 0xfee00bc0, 0x1, 0x0, 0x81010100, 0x1), at 0x75ab94
[8] unsafe_ostream::outstr(0xf41f6e78, 0xfee00bbf, 0x0, 0x0, 0xf41f6e7c, 0xfffffffe), at 0x757bac
=>[9] unsafe_ostream::operator<<(this = 0xf41f6e78, _s = 0xfee00bbf ")"), line 1211 in "iostream.h"
[10] ostream::operator<<(this = 0xf41f6e74, _s = 0xfee00bbf ")"), line 1350 in "iostream.h"
[11] CorInterfaceEntity::ifState(this = 0x1bc3de78, newState = MISMATCH_OF_INSTALLED_AND_EXPECTED, needToSendEvent = false
Can somebody help me giving a direction of investigation ?
Is there perhaps known problem with iostream on Sun Studio 8 running on Solaris 9 ?
Thanks for any tips.
Yaakov Berkovitch
[email protected]But sorry for my insistence, but do you think that
purify or/and runtime are not able to detect any
corruption of the heap ?They can detect some kinds of corruption, such as some uses of an invalid pointer.
But a wild pointer that changes the value of data that is part of your program cannot be detected by RTC or Purify. Those programs can't know whether that change is intentional.
>
BTW, we are not using any volatile declaration, and weIf non-local data is shared among threads, it should be declared volatile. For example, suppose you have
x = foo;
... // code not changing foo
y = foo;
If foo is not marked volatile, the compiler is allowed to assume its value hasn't changed, and assign to y the same value assigned to x. If foo was changed by another thread, y will not have the current value of foo. The "volatile" declaration says that the variable's value might change without any obvious reason, and the compiler should generate code to load a fresh value each time it is referenced.
are using the rwtools library packaged with the
compiler, and are not using the STD library.OK, you are not running into a std::string synchronization bug.
>
Also about the compiler option -xarch=v8, is probably
not relevant for us because we are running Solaris 9.
So the relevant compiler is probably -xarch=v9. Do you
advise us using this option ?I think you misunderstand. The -xarch values refer to the kind of processor your program will run on.
The -xarch=v8 option generates 32-bit code that will run on all SPARC chips, including the chips found in very old SPARCstations. This option is the default for compilers prior to Sun Studio 9 (which ships this week).
The -xarch=v8plus option generates 32-bit code that runs only on UltraSPARC chips, found in Ultra workstations. These are the only kinds of workstations shipped by Sun since about 1996. Unless you need to support the ancient SPARCstations, we recommend compiling with -xarch=v8plus, to get smaller and faster code.
The -xarch=v9 option generates 64-bit code that runs only on UltraSPARC chips, an only on Solaris 7 or later. Unless your program requires a very large address space, you generally don't want to generate 64-bit code. On SPARC, 64-bit code is larger and slower than 32-bit code. (Type "long" and all pointers are 64 bits instead of 32 bits.)
>
Also I want to return you two new questions:
1) I read in another discussion,
http://forum.sun.com/thread.jsp?forum=5&thread=18124&me
sage=47854#47854
that another memory manager can be more efficient in
multi-threaded environment (libmtmalloc.so), and also
an alternate threads library (/usr/lib/lwp) that
reduced CPU usage. Do you advice us using this
alternate library ?The libmtmalloc library usually has better performance in MT programs than the default version of malloc. It also can result in more memory fragmentation. In that case, the larger working set can sometimes have a large negative effect, more than offsetting the MT efficiency. You have to experiment to see whether it is appropriate for your particlular program. If you are running into heap corruption, the pattern of corruption will probably be different with libmtmalloc than with the default malloc. The differences might provide a clue to what is wrong.
The alternative "T2" threads library was introduced in Solaris 8 as an option.
In Solaris 9 it is the default, so you are already using it.
>
2) We are using the Rogue Wave library shiped with the
compiler. Is it an up-to-date version ? Can we assume
that is a good choice or it will be preferable to move
to the STD library ?I assume you mean Rogue Wave Tools.h++. As explained in the compiler docs, this version of Tools is obsolete, and has not been supported for many years. We continue to provide it for customers who used it before the introduction of the C++ Standard Library in 1998, and who don't want to change their code. We do not recommend it for use in new code. -
JDB crashes while lodading core dump or throws errors
I'm having here RHEL 5.1 system and some core dumps generated by our 32 bit java application. This application uses JNI and for some reason (that I'm still trying to figure out) is crashing while executing JNI calls.
I can load the core dumps inside gdb and even backtrace the native stack of the program and see the variables inside the shared library where it's crashing. But I need to take a closer look on the java stack and some of the variable values on the java side also.
I did try to use JDB to do this like it's described in the Troubleshooting guide for Java 6 but for some unknown reason when I do try to attach JDB to the core dumps I either get some error thrown on the console or JDB crashes and produces a hs_err_pit*.log file. I have used this technique already few times and didn't had any problems with JDB. I'm wondering if it could be that the core dump files are too big - some of them are around 3 Gb. But one of them is ~600Mb and also is crashing. So is ti possible bug in JDB or I'm missing something. I'm posting the error and the one of the hs_err_pid files.
Appreciate any help and ideas
$ jdb -connect sun.jvm.hotspot.jdi.SACoreAttachingConnector:javaExecutable=/usr/java/jdk/bin/java,core=core.31919
java.io.IOException
at sun.jvm.hotspot.jdi.SACoreAttachingConnector.attach(SACoreAttachingConnector.java:123)
at com.sun.tools.example.debug.tty.VMConnection.attachTarget(VMConnection.java:358)
at com.sun.tools.example.debug.tty.VMConnection.open(VMConnection.java:168)
at com.sun.tools.example.debug.tty.Env.init(Env.java:64)
at com.sun.tools.example.debug.tty.TTY.main(TTY.java:1010)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.jvm.hotspot.jdi.SACoreAttachingConnector.createVirtualMachine(SACoreAttachingConnector.java:80)
at sun.jvm.hotspot.jdi.SACoreAttachingConnector.attach(SACoreAttachingConnector.java:108)
... 4 more
Caused by: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the core file
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(LinuxDebuggerLocal.java:258)
at sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:625)
at sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(HotSpotAgent.java:611)
at sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:322)
at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:297)
at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:157)
at sun.jvm.hotspot.jdi.VirtualMachineImpl.createVirtualMachineForCorefile(VirtualMachineImpl.java:190)
... 10 more
Fatal error:
Unable to attach to target VM.
# An unexpected error has been detected by Java Runtime Environment:
# SIGSEGV (0xb) at pc=0xafcfa6bd, pid=3653, tid=4160613264
# Java VM: Java HotSpot(TM) Server VM (1.6.0_03-b05 mixed mode)
# Problematic frame:
# C [libsaproc.so+0x36bd]
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
--------------- T H R E A D ---------------
Current thread (0x08058000): JavaThread "main" [_thread_in_native, id=3654]
siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000151
Registers:
EAX=0xf7ffdabc, EBX=0xafcff25c, ECX=0xafd72d08, EDX=0x00000149
ESP=0xf7fdc520, EBP=0xf7fdc538, ESI=0xafd72d08, EDI=0x08058000
EIP=0xafcfa6bd, CR2=0x00000151, EFLAGS=0x00010206
Top of Stack: (sp=0xf7fdc520)
0xf7fdc520: 464c457f 00010101 000000a2 0000009c
0xf7fdc530: 0000009f afcff25c f7fdc588 afcfb01a
0xf7fdc540: afd67780 f7ffdabc 00200034 afcfaff4
0xf7fdc550: 004a004b 00000000 00200034 0028000a
0xf7fdc560: 004a004b afba13e0 00001110 afcff25c
0xf7fdc570: afb8e2e8 08058000 f7fdc5a8 afcf93b3
0xf7fdc580: 00000004 afcff25c f7fdc5a8 afcf9964
0xf7fdc590: afd67780 f7ffdabc f7fdd72c 00000004
Instructions: (pc=0xafcfa6bd)
0xafcfa6ad: 8d 14 85 00 00 00 00 8b 41 24 8b 14 10 8b 45 0c
0xafcfa6bd: 3b 42 08 72 08 8b 45 f8 89 45 f4 eb b1 8b 45 f8
Stack: [0xf7f8e000,0xf7fdf000), sp=0xf7fdc520, free space=313k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libsaproc.so+0x36bd]
C [libsaproc.so+0x401a]
C [libsaproc.so+0x2964] ps_pdread+0x1c
C [libsaproc.so+0x4d3e]
C [libsaproc.so+0x4ffd] Pgrab_core+0x281
C [libsaproc.so+0x56c7] Java_sun_jvm_hotspot_debugger_linux_LinuxDebuggerLocal_attach0__Ljava_lang_String_2Ljava_lang_String_2+0x99
j sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Ljava/lang/String;Ljava/lang/String;)V+0
j sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(Ljava/lang/String;Ljava/lang/String;)V+29
j sun.jvm.hotspot.HotSpotAgent.attachDebugger()V+43
j sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux()V+122
j sun.jvm.hotspot.HotSpotAgent.setupDebugger()V+95
j sun.jvm.hotspot.HotSpotAgent.go()V+1
j sun.jvm.hotspot.HotSpotAgent.attach(Ljava/lang/String;Ljava/lang/String;)V+56
j sun.jvm.hotspot.jdi.VirtualMachineImpl.createVirtualMachineForCorefile(Lcom/sun/jdi/VirtualMachineManager;Ljava/lang/String;Ljava/lang/String;I)Lsun/jvm/hotspot/jdi/VirtualMachineImpl;+58
v ~StubRoutines::call_stub
V [libjvm.so+0x2c5ecd]
V [libjvm.so+0x4523b8]
V [libjvm.so+0x2c5d60]
V [libjvm.so+0x49a08f]
V [libjvm.so+0x49ca8c]
V [libjvm.so+0x331e88]
C [libjava.so+0x15224] Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x34
j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
j sun.jvm.hotspot.jdi.SACoreAttachingConnector.createVirtualMachine(Ljava/lang/Class;Ljava/lang/String;Ljava/lang/String;)Lcom/sun/jdi/VirtualMachine;+122
j sun.jvm.hotspot.jdi.SACoreAttachingConnector.attach(Ljava/util/Map;)Lcom/sun/jdi/VirtualMachine;+90
j com.sun.tools.example.debug.tty.VMConnection.attachTarget()Lcom/sun/jdi/VirtualMachine;+13
j com.sun.tools.example.debug.tty.VMConnection.open()Lcom/sun/jdi/VirtualMachine;+33
j com.sun.tools.example.debug.tty.Env.init(Ljava/lang/String;ZI)V+28
j com.sun.tools.example.debug.tty.TTY.main([Ljava/lang/String;)V+1207
v ~StubRoutines::call_stub
V [libjvm.so+0x2c5ecd]
V [libjvm.so+0x4523b8]
V [libjvm.so+0x2c5d60]
V [libjvm.so+0x2ef186]
V [libjvm.so+0x2e082b]
C [jdb+0x1af8] JavaMain+0x2c8
C [libpthread.so.0+0x543b]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Ljava/lang/String;Ljava/lang/String;)V+0
j sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(Ljava/lang/String;Ljava/lang/String;)V+29
j sun.jvm.hotspot.HotSpotAgent.attachDebugger()V+43
j sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux()V+122
j sun.jvm.hotspot.HotSpotAgent.setupDebugger()V+95
j sun.jvm.hotspot.HotSpotAgent.go()V+1
j sun.jvm.hotspot.HotSpotAgent.attach(Ljava/lang/String;Ljava/lang/String;)V+56
j sun.jvm.hotspot.jdi.VirtualMachineImpl.createVirtualMachineForCorefile(Lcom/sun/jdi/VirtualMachineManager;Ljava/lang/String;Ljava/lang/String;I)Lsun/jvm/hotspot/jdi/VirtualMachineImpl;+58
v ~StubRoutines::call_stub
j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
j sun.jvm.hotspot.jdi.SACoreAttachingConnector.createVirtualMachine(Ljava/lang/Class;Ljava/lang/String;Ljava/lang/String;)Lcom/sun/jdi/VirtualMachine;+122
j sun.jvm.hotspot.jdi.SACoreAttachingConnector.attach(Ljava/util/Map;)Lcom/sun/jdi/VirtualMachine;+90
j com.sun.tools.example.debug.tty.VMConnection.attachTarget()Lcom/sun/jdi/VirtualMachine;+13
j com.sun.tools.example.debug.tty.VMConnection.open()Lcom/sun/jdi/VirtualMachine;+33
j com.sun.tools.example.debug.tty.Env.init(Ljava/lang/String;ZI)V+28
j com.sun.tools.example.debug.tty.TTY.main([Ljava/lang/String;)V+1207
v ~StubRoutines::call_stub
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0xafd08c00 JavaThread "Thread-1" daemon [_thread_blocked, id=3682]
0x0819b000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3680]
0x08199400 JavaThread "CompilerThread1" daemon [_thread_blocked, id=3679]
0x08198000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=3678]
0x08196c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3677]
0x08183c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3676]
0x08183400 JavaThread "Reference Handler" daemon [_thread_blocked, id=3675]
=>0x08058000 JavaThread "main" [_thread_in_native, id=3654]
Other Threads:
0x08180800 VMThread [id=3671]
0x0819c800 WatcherThread [id=3681]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
PSYoungGen total 9280K, used 2718K [0xedca0000, 0xee6f0000, 0xf4e60000)
eden space 8000K, 33% used [0xedca0000,0xedf47b40,0xee470000)
from space 1280K, 0% used [0xee5b0000,0xee5b0000,0xee6f0000)
to space 1280K, 0% used [0xee470000,0xee470000,0xee5b0000)
PSOldGen total 84992K, used 0K [0xb4e60000, 0xba160000, 0xedca0000)
object space 84992K, 0% used [0xb4e60000,0xb4e60000,0xba160000)
PSPermGen total 16384K, used 3088K [0xb0e60000, 0xb1e60000, 0xb4e60000)
object space 16384K, 18% used [0xb0e60000,0xb1164398,0xb1e60000)
Dynamic libraries:
00b31000-00b4a000 r-xp 00000000 fd:00 5932045 /lib/ld-2.5.so
00b4a000-00b4b000 r-xp 00019000 fd:00 5932045 /lib/ld-2.5.so
00b4b000-00b4c000 rwxp 0001a000 fd:00 5932045 /lib/ld-2.5.so
00b4e000-00c88000 r-xp 00000000 fd:00 5932057 /lib/libc-2.5.so
00c88000-00c8a000 r-xp 00139000 fd:00 5932057 /lib/libc-2.5.so
00c8a000-00c8b000 rwxp 0013b000 fd:00 5932057 /lib/libc-2.5.so
00c8b000-00c8e000 rwxp 00c8b000 00:00 0
00c90000-00ca3000 r-xp 00000000 fd:00 5932059 /lib/libpthread-2.5.so
00ca3000-00ca4000 r-xp 00012000 fd:00 5932059 /lib/libpthread-2.5.so
00ca4000-00ca5000 rwxp 00013000 fd:00 5932059 /lib/libpthread-2.5.so
00ca5000-00ca7000 rwxp 00ca5000 00:00 0
00ca9000-00cab000 r-xp 00000000 fd:00 5932058 /lib/libdl-2.5.so
00cab000-00cac000 r-xp 00001000 fd:00 5932058 /lib/libdl-2.5.so
00cac000-00cad000 rwxp 00002000 fd:00 5932058 /lib/libdl-2.5.so
00caf000-00cb6000 r-xp 00000000 fd:00 5932062 /lib/librt-2.5.so
00cb6000-00cb7000 r-xp 00006000 fd:00 5932062 /lib/librt-2.5.so
00cb7000-00cb8000 rwxp 00007000 fd:00 5932062 /lib/librt-2.5.so
00d9b000-00dc0000 r-xp 00000000 fd:00 5932060 /lib/libm-2.5.so
00dc0000-00dc1000 r-xp 00024000 fd:00 5932060 /lib/libm-2.5.so
00dc1000-00dc2000 rwxp 00025000 fd:00 5932060 /lib/libm-2.5.so
06000000-065a0000 r-xp 00000000 fd:00 16777229 /usr/java/jdk1.6.0_03/jre/lib/i386/server/libjvm.so
065a0000-065db000 rwxp 005a0000 fd:00 16777229 /usr/java/jdk1.6.0_03/jre/lib/i386/server/libjvm.so
065db000-069fc000 rwxp 065db000 00:00 0
08048000-08052000 r-xp 00000000 fd:00 16810695 /usr/java/jdk1.6.0_03/bin/jdb
08052000-08053000 rwxp 00009000 fd:00 16810695 /usr/java/jdk1.6.0_03/bin/jdb
08053000-08289000 rwxp 08053000 00:00 0 [heap]
afa00000-afa39000 rwxp afa00000 00:00 0
afa39000-afb00000 ---p afa39000 00:00 0
afb00000-afbf2000 rwxp afb00000 00:00 0
afbf2000-afc00000 ---p afbf2000 00:00 0
afcf7000-afcff000 r-xp 00000000 fd:00 16777232 /usr/java/jdk1.6.0_03/jre/lib/i386/libsaproc.so
afcff000-afd00000 rwxp 00007000 fd:00 16777232 /usr/java/jdk1.6.0_03/jre/lib/i386/libsaproc.so
afd00000-afe00000 rwxp afd00000 00:00 0
afe60000-afe63000 ---p afe60000 00:00 0
afe63000-afeb1000 rwxp afe63000 00:00 0
afeb1000-afeb6000 r-xp 00000000 fd:00 5931062 /lib/libthread_db-1.0.so
afeb6000-afeb7000 r-xp 00004000 fd:00 5931062 /lib/libthread_db-1.0.so
afeb7000-afeb8000 rwxp 00005000 fd:00 5931062 /lib/libthread_db-1.0.so
afecb000-afede000 r-xp 00000000 fd:00 16777249 /usr/java/jdk1.6.0_03/jre/lib/i386/libnet.so
afede000-afedf000 rwxp 00013000 fd:00 16777249 /usr/java/jdk1.6.0_03/jre/lib/i386/libnet.so
afedf000-afefe000 r-xs 00152000 fd:00 16810648 /usr/java/jdk1.6.0_03/lib/sa-jdi.jar
afefe000-aff5b000 r-xs 00b3c000 fd:00 16811549 /usr/java/jdk1.6.0_03/lib/tools.jar
aff5b000-aff5c000 ---p aff5b000 00:00 0
aff5c000-affdc000 rwxp aff5c000 00:00 0
affdc000-affdf000 ---p affdc000 00:00 0
affdf000-b002d000 rwxp affdf000 00:00 0
b002d000-b0030000 ---p b002d000 00:00 0
b0030000-b00ae000 rwxp b0030000 00:00 0
b00ae000-b00b1000 ---p b00ae000 00:00 0
b00b1000-b012f000 rwxp b00b1000 00:00 0
b012f000-b0132000 ---p b012f000 00:00 0
b0132000-b0180000 rwxp b0132000 00:00 0
b0180000-b0380000 r-xp 00000000 fd:00 15535906 /usr/lib/locale/locale-archive
b0380000-b0383000 ---p b0380000 00:00 0
b0383000-b03d1000 rwxp b0383000 00:00 0
b03d1000-b03d4000 ---p b03d1000 00:00 0
b03d4000-b0422000 rwxp b03d4000 00:00 0
b0422000-b0423000 ---p b0422000 00:00 0
b0423000-b04d3000 rwxp b0423000 00:00 0
b04d3000-b064f000 r-xs 02c8f000 fd:00 16777319 /usr/java/jdk1.6.0_03/jre/lib/rt.jar
b064f000-b0650000 ---p b064f000 00:00 0
b0650000-b06d0000 rwxp b0650000 00:00 0
b06d0000-b06d1000 ---p b06d0000 00:00 0
b06d1000-b0751000 rwxp b06d1000 00:00 0
b0751000-b0752000 ---p b0751000 00:00 0
b0752000-b07d2000 rwxp b0752000 00:00 0
b07d2000-b07d3000 ---p b07d2000 00:00 0
b07d3000-b0853000 rwxp b07d3000 00:00 0
b0853000-b0854000 ---p b0853000 00:00 0
b0854000-b08d4000 rwxp b0854000 00:00 0
b08d4000-b08d5000 ---p b08d4000 00:00 0
b08d5000-b0955000 rwxp b08d5000 00:00 0
b0955000-b0956000 ---p b0955000 00:00 0
b0956000-b09d6000 rwxp b0956000 00:00 0
b09d6000-b09d7000 ---p b09d6000 00:00 0
b09d7000-b0a5f000 rwxp b09d7000 00:00 0
b0a5f000-b0a77000 rwxp b0a5f000 00:00 0
b0a77000-b0aa1000 rwxp b0a77000 00:00 0
b0aa1000-b0c3f000 rwxp b0aa1000 00:00 0
b0c3f000-b0c47000 rwxp b0c3f000 00:00 0
b0c47000-b0c5f000 rwxp b0c47000 00:00 0
b0c5f000-b0c89000 rwxp b0c5f000 00:00 0
b0c89000-b0e26000 rwxp b0c89000 00:00 0
b0e26000-b0e2c000 rwxp b0e26000 00:00 0
b0e2c000-b0e5f000 rwxp b0e2c000 00:00 0
b0e5f000-b1e60000 rwxp b0e5f000 00:00 0
b1e60000-b4e60000 rwxp b1e60000 00:00 0
b4e60000-ba160000 rwxp b4e60000 00:00 0
ba160000-edca0000 rwxp ba160000 00:00 0
edca0000-ee6f0000 rwxp edca0000 00:00 0
ee6f0000-f4e60000 rwxp ee6f0000 00:00 0
f4e63000-f4e6c000 rwxp f4e63000 00:00 0
f4e6c000-f4f23000 rwxp f4e6c000 00:00 0
f4f23000-f5163000 rwxp f4f23000 00:00 0
f5163000-f7f23000 rwxp f5163000 00:00 0
f7f23000-f7f32000 r-xp 00000000 fd:00 16777245 /usr/java/jdk1.6.0_03/jre/lib/i386/libzip.so
f7f32000-f7f34000 rwxp 0000e000 fd:00 16777245 /usr/java/jdk1.6.0_03/jre/lib/i386/libzip.so
f7f34000-f7f57000 r-xp 00000000 fd:00 16777241 /usr/java/jdk1.6.0_03/jre/lib/i386/libjava.so
f7f57000-f7f59000 rwxp 00023000 fd:00 16777241 /usr/java/jdk1.6.0_03/jre/lib/i386/libjava.so
f7f59000-f7f62000 r-xp 00000000 fd:00 5931048 /lib/libnss_files-2.5.so
f7f62000-f7f63000 r-xp 00008000 fd:00 5931048 /lib/libnss_files-2.5.so
f7f63000-f7f64000 rwxp 00009000 fd:00 5931048 /lib/libnss_files-2.5.so
f7f64000-f7f77000 r-xp 00000000 fd:00 5931145 /lib/libnsl-2.5.so
f7f77000-f7f78000 r-xp 00012000 fd:00 5931145 /lib/libnsl-2.5.so
f7f78000-f7f79000 rwxp 00013000 fd:00 5931145 /lib/libnsl-2.5.so
f7f79000-f7f7b000 rwxp f7f79000 00:00 0
f7f82000-f7f8d000 r-xp 00000000 fd:00 16777240 /usr/java/jdk1.6.0_03/jre/lib/i386/libverify.so
f7f8d000-f7f8e000 rwxp 0000b000 fd:00 16777240 /usr/java/jdk1.6.0_03/jre/lib/i386/libverify.so
f7f8e000-f7f91000 ---p f7f8e000 00:00 0
f7f91000-f7fe1000 rwxp f7f91000 00:00 0
f7fe1000-f7fe8000 r-xp 00000000 fd:00 16777243 /usr/java/jdk1.6.0_03/jre/lib/i386/jli/libjli.so
f7fe8000-f7fea000 rwxp 00006000 fd:00 16777243 /usr/java/jdk1.6.0_03/jre/lib/i386/jli/libjli.so
f7fec000-f7ff4000 rwxs 00000000 fd:00 19562502 /tmp/hsperfdata_omnitrak/3653
f7ff4000-f7ffa000 r-xp 00000000 fd:00 16777227 /usr/java/jdk1.6.0_03/jre/lib/i386/native_threads/libhpi.so
f7ffa000-f7ffb000 rwxp 00006000 fd:00 16777227 /usr/java/jdk1.6.0_03/jre/lib/i386/native_threads/libhpi.so
f7ffb000-f7ffc000 rwxp f7ffb000 00:00 0
f7ffc000-f7ffd000 r-xp f7ffc000 00:00 0
f7ffd000-f7ffe000 rwxp f7ffd000 00:00 0
ff9fb000-ffa03000 rwxp ff9fb000 00:00 0 [stack]
ffffe000-fffff000 r-xp ffffe000 00:00 0
VM Arguments:
jvm_args: -Dapplication.home=/usr/java/jdk1.6.0_03
java_command: com.sun.tools.example.debug.tty.TTY -connect sun.jvm.hotspot.jdi.SACoreAttachingConnector:javaExecutable=/usr/java/jdk/bin/java,core=core.25602
Launcher Type: SUN_STANDARD
Environment Variables:
PATH=/usr/java/jdk/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin
LD_LIBRARY_PATH=/usr/java/jdk1.6.0_03/jre/lib/i386/server:/usr/java/jdk1.6.0_03/jre/lib/i386:/usr/java/jdk1.6.0_03/jre/../lib/i386
SHELL=/bin/bash
Signal Handlers:
SIGSEGV: [libjvm.so+0x53c560], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x53c560], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x451a50], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x451a50], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x451a50], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x453a80], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR2: [libjvm.so+0x453a80], sa_mask[0]=0x00000000, sa_flags=0x10000004
--------------- S Y S T E M ---------------
OS:Red Hat Enterprise Linux Client release 5.1 (Tikanga)
uname:Linux 2.6.18-53.el5 #1 SMP Wed Oct 10 16:34:19 EDT 2007 x86_64
libc:glibc 2.5 NPTL 2.5
rlimit: STACK 10240k, CORE 0k, NPROC 53248, NOFILE 1024, AS infinity
load average:0.07 0.22 0.42
CPU:total 8 (4 cores per cpu, 1 threads per core) family 6 model 7 stepping 6, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
Memory: 4k page, physical 6113940k(245496k free), swap 2097144k(2097144k free)
vm_info: Java HotSpot(TM) Server VM (1.6.0_03-b05) for linux-x86, built on Sep 24 2007 22:32:39 by "java_re" with gcc 3.2.1-7a (J2SE release)Thank you for your responds!
I'm not trying at all to transfer the core to a different system. I'm debugging on the same linux red hat box where the cores where produced and I'm using the JDB version from the same JDK that was used to run the app.
I'm wondering what makes you think that I'm possibly mixing core files?
Here is the output that JDB generates when I define LIBSAPROC_DEBUG=1. This is the case when JDB crashes:
$ jdb -connect sun.jvm.hotspot.jdi.SACoreAttachingConnector:javaExecutable=/usr/java/jdk/bin/java,core=core.23850
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24310
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0x0
libsaproc DEBUG: ebx = 0x5d2a
libsaproc DEBUG: ecx = 0x5ef6
libsaproc DEBUG: edx = 0x6
libsaproc DEBUG: esp = 0x324fd0e4
libsaproc DEBUG: ebp = 0x324fd0e4
libsaproc DEBUG: esi = 0x324fd19c
libsaproc DEBUG: edi = 0x78eff4
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 3 and n_descsz = 124
libsaproc DEBUG: Note header with n_type = 6 and n_descsz = 144
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 27070
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffe00
libsaproc DEBUG: ebx = 0xa
libsaproc DEBUG: ecx = 0x312edad8
libsaproc DEBUG: edx = 0x33f4d1a4
libsaproc DEBUG: esp = 0x312edac0
libsaproc DEBUG: ebp = 0x312edac0
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x2000
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 27063
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffe00
libsaproc DEBUG: ebx = 0xa
libsaproc DEBUG: ecx = 0x334fccd8
libsaproc DEBUG: edx = 0x33f4d1a4
libsaproc DEBUG: esp = 0x334fccc0
libsaproc DEBUG: ebp = 0x334fccc0
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x2000
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 1754
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x32baab38
libsaproc DEBUG: ecx = 0x1
libsaproc DEBUG: edx = 0x6ddd00
libsaproc DEBUG: esp = 0x32baaaf0
libsaproc DEBUG: ebp = 0x32baaaf0
libsaproc DEBUG: esi = 0x1eed0
libsaproc DEBUG: edi = 0x78eff4
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24325
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x834486c
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x306bf
libsaproc DEBUG: esp = 0x32bfdda8
libsaproc DEBUG: ebp = 0x32bfdda8
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x306bf
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24319
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x831e8cc
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x2d49f7
libsaproc DEBUG: esp = 0x33259cb0
libsaproc DEBUG: ebp = 0x33259cb0
libsaproc DEBUG: esi = 0x33259cc4
libsaproc DEBUG: edi = 0x2d49f7
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24318
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x83783a4
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x38dd3
libsaproc DEBUG: esp = 0x3330ab30
libsaproc DEBUG: ebp = 0x3330ab30
libsaproc DEBUG: esi = 0x3330ab44
libsaproc DEBUG: edi = 0x38dd3
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24317
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0x1
libsaproc DEBUG: ebx = 0x827bb60
libsaproc DEBUG: ecx = 0x1
libsaproc DEBUG: edx = 0x1
libsaproc DEBUG: esp = 0x3335bb0c
libsaproc DEBUG: ebp = 0x3335bb0c
libsaproc DEBUG: esi = 0x3335bbb8
libsaproc DEBUG: edi = 0x827bb60
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24316
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x8082d14
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x1
libsaproc DEBUG: esp = 0x33d5ca98
libsaproc DEBUG: ebp = 0x33d5ca98
libsaproc DEBUG: esi = 0x33d5caac
libsaproc DEBUG: edi = 0x1
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24315
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x8378204
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x1
libsaproc DEBUG: esp = 0x334adac8
libsaproc DEBUG: ebp = 0x334adac8
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x1
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24314
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0x19
libsaproc DEBUG: ebx = 0x33f164cc
libsaproc DEBUG: ecx = 0x9b
libsaproc DEBUG: edx = 0x39f99940
libsaproc DEBUG: esp = 0x320f9a14
libsaproc DEBUG: ebp = 0x1e
libsaproc DEBUG: esi = 0x2
libsaproc DEBUG: edi = 0x39f975a0
libsaproc DEBUG: eip = 0x33f0e054
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24313
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0x39c534e0
libsaproc DEBUG: ebx = 0x33f164cc
libsaproc DEBUG: ecx = 0x321fabba
libsaproc DEBUG: edx = 0x6
libsaproc DEBUG: esp = 0x321faa70
libsaproc DEBUG: ebp = 0x321faa7c
libsaproc DEBUG: esi = 0x2
libsaproc DEBUG: edi = 0x39c53478
libsaproc DEBUG: eip = 0x33f1028e
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24312
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0x29
libsaproc DEBUG: ebx = 0x39bd4780
libsaproc DEBUG: ecx = 0x1
libsaproc DEBUG: edx = 0x2400d1a2
libsaproc DEBUG: esp = 0x322fbc50
libsaproc DEBUG: ebp = 0x322fbc7c
libsaproc DEBUG: esi = 0x33f167a8
libsaproc DEBUG: edi = 0xf9000607
libsaproc DEBUG: eip = 0x33f0ef54
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24311
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x827ac04
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x137ee7
libsaproc DEBUG: esp = 0x323fcd28
libsaproc DEBUG: ebp = 0x323fcd28
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x137ee7
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24309
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0x6
libsaproc DEBUG: ebx = 0x3a5c0970
libsaproc DEBUG: ecx = 0x2
libsaproc DEBUG: edx = 0xb
libsaproc DEBUG: esp = 0x325febd0
libsaproc DEBUG: ebp = 0x3a5c1cdc
libsaproc DEBUG: esi = 0x6
libsaproc DEBUG: edi = 0x4
libsaproc DEBUG: eip = 0x33f0ef06
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24308
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0x5
libsaproc DEBUG: ebx = 0x3a98cb48
libsaproc DEBUG: ecx = 0x2
libsaproc DEBUG: edx = 0x9
libsaproc DEBUG: esp = 0x32cfea50
libsaproc DEBUG: ebp = 0x3a98dde8
libsaproc DEBUG: esi = 0x5
libsaproc DEBUG: edi = 0x5
libsaproc DEBUG: eip = 0x33f0f084
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24307
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0x8
libsaproc DEBUG: ebx = 0x3a1fd104
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x6
libsaproc DEBUG: esp = 0x3345c984
libsaproc DEBUG: ebp = 0x3345c984
libsaproc DEBUG: esi = 0x29
libsaproc DEBUG: edi = 0x0
libsaproc DEBUG: eip = 0x33f0f210
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24304
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x82ee0ac
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x1
libsaproc DEBUG: esp = 0x332aad90
libsaproc DEBUG: ebp = 0x332aad90
libsaproc DEBUG: esi = 0x332aada4
libsaproc DEBUG: edi = 0x1
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24015
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x856427c
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x1
libsaproc DEBUG: esp = 0x33b5ca90
libsaproc DEBUG: ebp = 0x33b5ca90
libsaproc DEBUG: esi = 0x33b5caa4
libsaproc DEBUG: edi = 0x1
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24014
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x818b8e4
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x3
libsaproc DEBUG: esp = 0x33bada98
libsaproc DEBUG: ebp = 0x33bada98
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x3
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24013
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffe00
libsaproc DEBUG: ebx = 0x5
libsaproc DEBUG: ecx = 0x33bfedd0
libsaproc DEBUG: edx = 0x33f4d1a4
libsaproc DEBUG: esp = 0x33bfedb8
libsaproc DEBUG: ebp = 0x33bfedb8
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x827e400
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24011
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x828951c
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x1
libsaproc DEBUG: esp = 0x33dadcd8
libsaproc DEBUG: ebp = 0x33dadcd8
libsaproc DEBUG: esi = 0x33dadcec
libsaproc DEBUG: edi = 0x1
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 24010
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x849caac
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x1
libsaproc DEBUG: esp = 0x33dfec68
libsaproc DEBUG: ebp = 0x33dfec68
libsaproc DEBUG: esi = 0x33dfec7c
libsaproc DEBUG: edi = 0x1
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23868
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x80c213c
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x1
libsaproc DEBUG: esp = 0x34090f78
libsaproc DEBUG: ebp = 0x34090f78
libsaproc DEBUG: esi = 0x34090f8c
libsaproc DEBUG: edi = 0x1
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23867
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x819e294
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x1
libsaproc DEBUG: esp = 0x340e2018
libsaproc DEBUG: ebp = 0x340e2018
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x1
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23866
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x8199a5c
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x434
libsaproc DEBUG: esp = 0x34162e48
libsaproc DEBUG: ebp = 0x34162e48
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x434
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23865
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x8199a5c
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x432
libsaproc DEBUG: esp = 0x341e3ec8
libsaproc DEBUG: ebp = 0x341e3ec8
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x432
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23864
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x65e80a0
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x0
libsaproc DEBUG: esp = 0x34234fb0
libsaproc DEBUG: ebp = 0x34234fb0
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0xffc
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23863
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x818ba8c
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x289
libsaproc DEBUG: esp = 0x34485de0
libsaproc DEBUG: ebp = 0x34485de0
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x289
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23862
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x81887d4
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x2b3
libsaproc DEBUG: esp = 0x344d6c90
libsaproc DEBUG: ebp = 0x344d6c90
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x2b3
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23861
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x31e0548c
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x3
libsaproc DEBUG: esp = 0x345580d8
libsaproc DEBUG: ebp = 0x345580d8
libsaproc DEBUG: esi = 0x345580ec
libsaproc DEBUG: edi = 0x3
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23860
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x8096674
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x161e9b
libsaproc DEBUG: esp = 0x34784f68
libsaproc DEBUG: ebp = 0x34784f68
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x161e9b
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23859
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x8096674
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x161e9a
libsaproc DEBUG: esp = 0x34805fe8
libsaproc DEBUG: ebp = 0x34805fe8
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x161e9a
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23858
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x8096674
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x161e9c
libsaproc DEBUG: esp = 0x34886e68
libsaproc DEBUG: ebp = 0x34886e68
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x161e9c
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23857
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x8096674
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x161e99
libsaproc DEBUG: esp = 0x34907ee8
libsaproc DEBUG: ebp = 0x34907ee8
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x161e99
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23856
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x8096674
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x161e98
libsaproc DEBUG: esp = 0x34989168
libsaproc DEBUG: ebp = 0x34989168
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x161e98
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23855
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x8096674
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x161e97
libsaproc DEBUG: esp = 0x34a0a1e8
libsaproc DEBUG: ebp = 0x34a0a1e8
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x161e97
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23854
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x8096674
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x161e96
libsaproc DEBUG: esp = 0x34a8b068
libsaproc DEBUG: ebp = 0x34a8b068
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x161e96
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23853
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x8096674
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x161e95
libsaproc DEBUG: esp = 0x34b0c0e8
libsaproc DEBUG: ebp = 0x34b0c0e8
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x161e95
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23852
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0x33e5e19c
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x1
libsaproc DEBUG: esp = 0xf7fde228
libsaproc DEBUG: ebp = 0xf7fde228
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x1
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: Note header with n_type = 1 and n_descsz = 144
libsaproc DEBUG: got integer regset for lwp 23850
libsaproc DEBUG: integer regset
libsaproc DEBUG: eax = 0xfffffffc
libsaproc DEBUG: ebx = 0xf7fdebd8
libsaproc DEBUG: ecx = 0x0
libsaproc DEBUG: edx = 0x5d2c
libsaproc DEBUG: esp = 0xffb93630
libsaproc DEBUG: ebp = 0xffb93630
libsaproc DEBUG: esi = 0x0
libsaproc DEBUG: edi = 0x7a8ff4
libsaproc DEBUG: eip = 0xffffe410
libsaproc DEBUG: Note header with n_type = 2 and n_descsz = 108
libsaproc DEBUG: Note header with n_type = 1189489535 and n_descsz = 512
libsaproc DEBUG: ELF interpreter /lib/ld-linux.so.2
libsaproc DEBUG: address of _DYNAMIC is 0x8052548
libsaproc DEBUG: ---- sorted virtual address map ----
libsaproc DEBUG: base = 0x64f000 size = 4096
libsaproc DEBUG: base = 0x650000 size = 4096
libsaproc DEBUG: base = 0x78d000 size = 8192
libsaproc DEBUG: base = 0x78f000 size = 4096
libsaproc DEBUG: base = 0x790000 size = 12288
libsaproc DEBUG: base = 0x7a8000 size = 4096
libsaproc DEBUG: base = 0x7a9000 size = 4096
libsaproc DEBUG: base = 0x7aa000 size = 8192
libsaproc DEBUG: base = 0x7b0000 size = 4096
libsaproc DEBUG: base = 0x7b1000 size = 4096
libsaproc DEBUG: base = 0x879000 size = 4096
libsaproc DEBUG: base = 0x87a000 size = 4096
libsaproc DEBUG: base = 0x884000 size = 4096
libsaproc DEBUG: base = 0x885000 size = 4096
libsaproc DEBUG: base = 0xc37000 size = 16384
libsaproc DEBUG: base = 0xc3b000 size = 4096
libsaproc DEBUG: base = 0xc3c000 size = 24576
libsaproc DEBUG: base = 0xd38000 size = 4096
libsaproc DEBUG: base = 0x6000000 size = 5898240
libsaproc DEBUG: base = 0x65a0000 size = 241664
libsaproc DEBUG: base = 0x65db000 size = 4329472
libsaproc DEBUG: base = 0x8048000 size = 38100
libsaproc DEBUG: base = 0x8052000 size = 4096
libsaproc DEBUG: base = 0x8053000 size = 14032896
libsaproc DEBUG: base = 0x30f00000 size = 1007616
libsaproc DEBUG: base = 0x31100000 size = 1048576
libsaproc DEBUG: base = 0x312a0000 size = 12288
libsaproc DEBUG: base = 0x312a3000 size = 319488
libsaproc DEBUG: base = 0x3133a000 size = 16384
libsaproc DEBUG: base = 0x31344000 size = 753664
libsaproc DEBUG: base = 0x313fc000 size = 16384
libsaproc DEBUG: base = 0x31400000 size = 929792
libsaproc DEBUG: base = 0x31500000 size = 1028096
libsaproc DEBUG: base = 0x31600000 size = 966656
libsaproc DEBUG: base = 0x31700000 size = 1028096
libsaproc DEBUG: base = 0x31800000 size = 991232
libsaproc DEBUG: base = 0x31900000 size = 1044480
libsaproc DEBUG: base = 0x31a00000 size = 1032192
libsaproc DEBUG: base = 0x31b00000 size = 1032192
libsaproc DEBUG: base = 0x31c00000 size = 1003520
libsaproc DEBUG: base = 0x31d51000 size = 319488
libsaproc DEBUG: base = 0x31df9000 size = 28672
libsaproc DEBUG: base = 0x31e00000 size = 1048576
libsaproc DEBUG: base = 0x31f03000 size = 552960
libsaproc DEBUG: base = 0x31f8a000 size = 20480
libsaproc DEBUG: base = 0x31f90000 size = 331776
libsaproc DEBUG: base = 0x31fe1000 size = 8192
libsaproc DEBUG: base = 0x31ffa000 size = 12288
libsaproc DEBUG: base = 0x31ffd000 size = 1040384
libsaproc DEBUG: base = 0x320fb000 size = 12288
libsaproc DEBUG: base = 0x320fe000 size = 1040384
libsaproc DEBUG: base = 0x321fc000 size = 12288
libsaproc DEBUG: base = 0x321ff000 size = 1040384
libsaproc DEBUG: base = 0x322fd000 size = 12288
libsaproc DEBUG: base = 0x32300000 size = 1040384
libsaproc DEBUG: base = 0x323fe000 size = 12288
libsaproc DEBUG: base = 0x32401000 size = 1040384
libsaproc DEBUG: base = 0x324ff000 size = 12288
libsaproc DEBUG: base = 0x32502000 size = 1957888
libsaproc DEBUG: base = 0x32700000 size = 1024000
libsaproc DEBUG: base = 0x32800000 size = 2072576
libsaproc DEBUG: base = 0x32a00000 size = 1040384
libsaproc DEBUG: base -
Core dump is not having much information
HI All,
We have multithreaded application running on Solaris 5.8.
Application produces core dump.
When we debug the core dump using DBX (for where command) , we can see our function calls on the paticular thread in which the crash is happend.
But the problem is other threads are having only address and can not be seen any applicaiton calls.
Simply what is the problem here ?
Should we install any paticular Solaris pathches ?
If anybody knows patch no , please let me know;
Thanks
KithsiriIt's hard to tell from your description. First of all, do you debug corefile on the same machine where this core was dumped? And could you also post dbx output that lacks information here?
-
Hi All,
We have a java application which works in protocol level. Our java application uses JNI to interact with others modules which are written in C++.
We are doing stress testing on the application. after that, we are stopping the java application and starting it. when this action happens java core dumps.
when i see the core dump using gdb it show the following message.
Core was generated by `java -server -Xmn64M -Xms170M -Xmx170M -cp :../lib/servic
es.jar:../lib/commons-'.
Program terminated with signal 3, Quit.
#0 0x400ea621 in nanosleep () from /lib/libc.so.6
(gdb) where
#0 0x400ea621 in nanosleep () from /lib/libc.so.6
#1 0x400208ee in __pthread_timedsuspend_new (self=0xbf1ffc00,
abstime=0xbf1ff914) at pthread.c:1125
#2 0x4001d183 in pthread_cond_timedwait_relative (cond=0x805ce38,
mutex=0x805ce20, abstime=0xbf1ff914) at restart.h:45
#3 0x405a666c in os::Linux::safe_cond_timedwait ()
from /sw/linuxapps/usr/java/jre1.5.0_17/lib/i386/server/libjvm.so
#4 0x4058db51 in Monitor::wait ()
from /sw/linuxapps/usr/java/jre1.5.0_17/lib/i386/server/libjvm.so
#5 0x40689c6b in VMThread::loop ()
from /sw/linuxapps/usr/java/jre1.5.0_17/lib/i386/server/libjvm.so
#6 0x406898d0 in VMThread::run ()
from /sw/linuxapps/usr/java/jre1.5.0_17/lib/i386/server/libjvm.so
#7 0x405a7408 in _start ()
from /sw/linuxapps/usr/java/jre1.5.0_17/lib/i386/server/libjvm.so
#8 0x4001dfb7 in pthread_start_thread (arg=0xbf1ffc00) at manager.c:284
#9 0x4011d84a in clone () from /lib/libc.so.6
Please provide your thoughts or suggestions. is this a known issue in JVM? or this is not related to JVM issue?
Thanks
iramar."stopping" and "starting" are two actions here. Which action triggered core dumps? How did you stop the application?
From your gdb message, the core dump was generated when your java application received a "kill -QUIT" signal.
In my Solaris java 1.5.0_10 environment, if you had a "-Xs" in your java option, the "kill -QUIT" signal will generate a core dump -
Using perl DBI on Solaris 10 gives core dump
I am using perl 5.8.4 which comes along with Solaris 10.
I have installed DBI-1.58.
Even a test command is not working.
perl -MDBI -e 'print "$DBI::VERSION\n";'
Bus Error (core dumped)
truss perl -MDBI -e 'print "$DBI::VERSION\n";'
shows
stat("/usr/local/lib/libc.so.1", 0xFFBFE5D0) Err#2 ENOENT
mprotect(0xFEED0000, 104171, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0xFEED0000, 104171, PROT_READ|PROT_EXEC) = 0
munmap(0xFF370000, 8192) = 0
brk(0x000A2470) = 0
brk(0x000A4470) = 0
brk(0x000A4470) = 0
brk(0x000A6470) = 0
brk(0x000A6470) = 0
brk(0x000A8470) = 0
brk(0x000A8470) = 0
brk(0x000AA470) = 0
brk(0x000AA470) = 0
brk(0x000AC470) = 0
Incurred fault #5, FLTACCESS %pc = 0xFEED44CC
siginfo: SIGBUS BUS_ADRALN addr=0x00000001
Received signal #10, SIGBUS [default]
siginfo: SIGBUS BUS_ADRALN addr=0x00000001
$perl -v
command shows like its compiled with Intsize of 64 is this creating problem?
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=solaris, osvers=2.10, archname=sun4-solaris-64int
uname='sunos localhost 5.10 sun4u sparc SUNW,Ultra-2'
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO',
optimize='-xO3 -xspace -xildoff',
cppflags=''
ccversion='Sun WorkShop', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=87654321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =''
libpth=/lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -ldl -lm -lc
perllibs=-lsocket -lnsl -ldl -lm -lc
libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-R /usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE'
cccdlflags='-KPIC', lddlflags='-G'
Characteristics of this binary (from libperl):
Compile-time options: USE_64_BIT_INT USE_LARGE_FILES
Locally applied patches:
22667 The optree builder was looping when constructing the ops ...
22715 Upgrade to FileCache 1.04
22733 Missing copyright in the README.
22746 fix a coredump caused by rv2gv not fully converting a PV ...
22755 Fix 29149 - another UTF8 cache bug hit by substr.
22774 [perl #28938] split could leave an array without ...
22775 [perl #29127] scalar delete of empty slice returned garbage
22776 [perl #28986] perl -e "open m" crashes Perl
22777 add test for change #22776 ("open m" crashes Perl)
22778 add test for change #22746 ([perl #29102] Crash on assign ...
22781 [perl #29340] Bizarre copy of ARRAY make sure a pad op's ...
22796 [perl #29346] Double warning for int(undef) and abs(undef) ...
22818 BOM-marked and (BOMless) UTF-16 scripts not working
22823 [perl #29581] glob() misses a lot of matches
22827 Smoke [5.9.2] 22818 FAIL(F) MSWin32 WinXP/.Net SP1 (x86/1 cpu)
22830 [perl #29637] Thread creation time is hypersensitive
22831 improve hashing algorithm for ptr tables in perl_clone: ...
22839 [perl #29790] Optimization busted: '@a = "b", sort @a' ...
22850 [PATCH] 'perl -v' fails if local_patches contains code snippets
22852 TEST needs to ignore SCM files
22886 Pod::Find should ignore SCM files and dirs
22888 Remove redundant %SIG assignments from FileCache
23006 [perl #30509] use encoding and "eq" cause memory leak
23074 Segfault using HTML::Entities
23106 Numeric comparison operators mustn't compare addresses of ...
23320 [perl #30066] Memory leak in nested shared data structures ...
23321 [perl #31459] Bug in read()
Built under solaris
Compiled at Jul 26 2005 05:26:55
@INC:
/usr/perl5/5.8.4/lib/sun4-solaris-64int
/usr/perl5/5.8.4/lib
/usr/perl5/site_perl/5.8.4/sun4-solaris-64int
/usr/perl5/site_perl/5.8.4
/usr/perl5/site_perl
/usr/perl5/vendor_perl/5.8.4/sun4-solaris-64int
/usr/perl5/vendor_perl/5.8.4
/usr/perl5/vendor_perl
Other details:
file /usr/bin/perl
/usr/bin/perl: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
I tried installing DBI module using perlgcc also.
perlgcc Makefile.PL
make
make test
make install.
$uname -a
SunOS twirl 5.10 Generic_118822-25 sun4u sparc SUNW,Ultra-80
Please help me out.Try this guy's list, he maintain an archive of Solaris package.
http://www.ibiblio.org/pub/packages/solaris/sparc/html/creating.solaris.packages.html
Of course, if you can get directly from Sun will be better. -
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 listenerWe 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. -
Unable to install Adobe CS5 64 bit package created using Adobe Application Manager on Windows 7 64
I am unable to install Adobe CS5 64 bit package created using Adobe Application Manager on Windows 7 64 bit.Basically installation rollback on Win 7 64 bit image.
MSI Log File :-
Property(S): ProductToBeRegistered = 1
MSI (s) (5C:D4) [17:59:21:784]: Note: 1: 1708
MSI (s) (5C:D4) [17:59:21:784]: Product: Adobe_CreativieSuite_5_MNT -- Installation operation failed.
MSI (s) (5C:D4) [17:59:21:784]: Windows Installer installed the product. Product Name: Adobe_CreativieSuite_5_MNT. Product Version: 1.2.0000. Product Language: 1033. Manufacturer: Adobe Systems Incorporated. Installation success or error status: 1603.
Please let me how to install 64 bit package on Win7 64 bit.
Thanks in Advance.Ok so I downloaded the most current installer CS5.1, My previous installer was version 5.0. It did install fine fully updated to my license version. I just wanted to update in case anyone in the future has a similiar experience. Too bad this advice was not offered by the "experts" here.
-
Getting core dump when using EXEC SQL CLOSE
In my pro*c program , i have used a cursor to fetch the set of accounts.Once cursor is opened , code will perform set
of operation using fetched data and then cursor is closed. Between open and closing of cursor , i have used 23 EXEC
SQL CLOSE. For example i am copying the value of a to b using strlcpy between fetch and close cursor statement.If
returned value from strlcpy is greater than size of destination variable, then flow should not proceed , in that case I will
close the cursor using EXEC SQL CLOSE and return the flow to calling program. Similarly i have closed the cursor at
another 22 locations.
When i compile the code and run binary the core dump occurs. On analyzing the core it shows
t@null (l@8) terminated by signal SEGV (no mapping at the fault address)
0xffffffffffffffff: <bad address 0xffffffffffffffff>
dbx: core file read error: address 0xfc4ffe48 not in data space
Current function is dbMtBaseClass::Pswd_Change
7860 sqlcxt(&_dbMtCtx, &sqlctx, &sqlstm, &sqlfpn);
if I remove any of the three EXEC SQL CLOSE commands , core dump does not occurs.
It looks strange.Please help me to resolve the issue.In my pro*c program , i have used a cursor to fetch the set of accounts.Once cursor is opened , code will perform set
of operation using fetched data and then cursor is closed. Between open and closing of cursor , i have used 23 EXEC
SQL CLOSE. For example i am copying the value of a to b using strlcpy between fetch and close cursor statement.If
returned value from strlcpy is greater than size of destination variable, then flow should not proceed , in that case I will
close the cursor using EXEC SQL CLOSE and return the flow to calling program. Similarly i have closed the cursor at
another 22 locations.
When i compile the code and run binary the core dump occurs. On analyzing the core it shows
t@null (l@8) terminated by signal SEGV (no mapping at the fault address)
0xffffffffffffffff: <bad address 0xffffffffffffffff>
dbx: core file read error: address 0xfc4ffe48 not in data space
Current function is dbMtBaseClass::Pswd_Change
7860 sqlcxt(&_dbMtCtx, &sqlctx, &sqlstm, &sqlfpn);
if I remove any of the three EXEC SQL CLOSE commands , core dump does not occurs.
It looks strange.Please help me to resolve the issue. -
I am using Communicator Pro with Enterprise Calendaring, Calendar client 4.6,
and when I attempt to launch it I immediately get a core dump and it does not
launch.
<P>
The 4.6 motif client is not able to run against the 4.0 Calendar Server.
It is strongly recommended that you use the 4.61 motif Calendar client (bundled with the 4.7
Communicator Pro release) or 4.51/4.52 against Calendar Server 4.0. There are
known problems when going offline while using the 4.5 client on any platform
against the 4.0 Server. Both the 4.51 Windows and the 4.52 motif clients have
repaired this problem.You can get Firefox 3.6 from http://www.mozilla.com/en-US/firefox/all-older.html
-
Compaq Tru64 OCI Core dump at OCIServerAttach
Hello,
We get the below core dump on Tru64 and the same code has been working fine on other platforms and Oracle 9i.
We load connect using a shared object and I have displayed the ldd resolutions below as well..
Any help appreciated.
Thanks and Regards
A
0x300041a57c4 in sigpnm() "sigpnm.c":122
0x300041521c8 in sigpnmu() "si.c":240
0x30004062188 in snlpcgpgnm() "snlpc.c":433
0x30003fc92a8 in snigpgn() "sniq.c":325
0x30003f74b98 in niqnamcd() "niqnam.c":244
0x30003f756f8 in niqname() "niqnam.c":625
0x30003ccc8b4 in kwfnran() "kwfn.c":189
0x30003b92c40 in kwfcinit() "kwfc.c":351
0x30003ac0644 in kpuatch() "kpu.c":1941
0x30003b1a660 in OCIServerAttach() "oci8.c":722
0x3000301802c in DG_X_oci_connect(hdbc=0x140072a00, pszServer=0x14010f9a0="oracle10_test", pszUserID=0x14010f9c0="view", pszPassword=0x20000b09720="view", iError=0x20000b09600) "/compaqtrue64/src/lib/oracle10g/../oracle/liboci.c":140
[export/home2/oracle/10.2.0/lib]$ ldd /export/home2/oracle/i5xs_1/bin/abc_dbora10g.dll
Main => /export/home2/oracle/i5xs_1/bin/abc_dbora10g.dll
libclntsh.so.10.1 => /export/home2/oracle/10.2.0/lib/libclntsh.so.10.1
stc_common.dll => /export/home2/oracle/i5xs_1/bin/abc_common.dll
libpthread.so => /usr/shlib/libpthread.so
librt.so => /usr/shlib/librt.so
libcxx.so => /usr/lib/cmplrs/cxx/libcxx.so
libexc.so => /usr/shlib/libexc.so
libc.so => /usr/shlib/libc.so
libaio_raw.so => /usr/shlib/libaio_raw.so
libm.so => /usr/shlib/libm.so
[export/home2/oracle/10.2.0/lib]$ ldd /export/home2/oracle/10.2.0/lib/libclntsh.so.10.1
Main => /export/home2/oracle/10.2.0/lib/libclntsh.so.10.1
libexc.so => /usr/shlib/libexc.so
librt.so => /usr/shlib/librt.so
libaio_raw.so => /usr/shlib/libaio_raw.so
libm.so => /usr/shlib/libm.so
libc.so => /usr/shlib/libc.so
libpthread.so => /usr/shlib/libpthread.soHello.
We get the same core dump with the code which works fine on Win32.
Oracle version is 10.2.0.4. It doesn't depend on how linking is done - with shared libraries or static ones.
Thread terminated at PC 0x140000018 by signal ILL
0 0x140000018 in /ppqm/sim/bin/dbld#1 0x3ffbe372f14 in sigpnm() "sigpnm.c":122
#2 0x3ffbe31eed8 in sigpnmu() "si.c":240
#3 0x3ffbe22e898 in snlpcgpgnm() "snlpc.c":436
#4 0x3ffbe195738 in snigpgn() "sniq.c":325
#5 0x3ffbe134f30 in niqnamcd() "niqnam.c":242
#6 0x3ffbe135a98 in niqname() "niqnam.c":624
#7 0x3ffbde96140 in kwfnran() "kwfn.c":185
#8 0x3ffbdd5a780 in kwfcinit() "kwfc.c":359
#9 0x3ffbdc864f4 in kpuatch() "kpu.c":1952
#10 0x3ffbdce1600 in OCIServerAttach() "oci8.c":724
#11 0x1200d5c10 in oci_loader_init(argc=2, argv=0x11fffbd98, ctlp=0x11fffbea8, psess=0x1400c9268) "../../cdemodp.cpp":182
Does anybody know or guess what could be a reason and how to solve the problem?
Thanks in advance. -
Core dump while trying to access attributes in a node using SAX
I'm running the 10g xdk with Solaris 8 and was able to get the SAX examples working. However when I tried to add some code to the example code in order to access/print out attributes, I get a core dump.
code snippet:
void MyHandler::startElementNS ( oratext* qname, oratext* local, oratext* ns_URI, NodeListRef<xmlnode>* attrs_refp)
printf( " Element: %s\n", qname);
if (attrs_refp)
for (int i=0; i<attrs_refp->getLength(); i++) <-- core dumps with getLength() call
xmlnode* node = attrs_ref->item(i);
Am I not accessing the attributes correctly? Is there an easier way to do this that I have overlooked?I have very similar code for the parser and ran in to two problems. I am currently using 10.1.0.2.0 on Windows.
Problem 1:
Can the original poster of the following code tell me what you have under the ... section? I am trying to iterate through the attributes in attrs_refp
void MyHandler::startElementNS ( oratext* qname, oratext* local, oratext* ns_URI, NodeListRef<xmlnode>* attrs_refp)
printf( " Element: %s\n", qname);
if (attrs_refp)
for (int i=0; i<attrs_refp->getLength(); i++) <-- core dumps with getLength() call
xmlnode* node = attrs_ref->item(i);
In the ... section, I have the following line:
oratext* a = node->getname();
However, the compiler gives the following error:
error C2027: use of undefined type 'xmlnode'
Anyone have any clues as to why xmlnode is undefined?
Problem 2:
If I comment out the line oratext* a = node->getname();, I can successfully compile my program but I get a link error stating that both the methods item() and getLength() are unresolved external symbols. This lead me to believe these methods are not implemented in the Oracle XDK. user457758 seems to have gotten past this stage as he is getting a run time error so the compilation appears to be successful. I assume user457758 is using the latest 10.1.0.3.0 available on Solaris instead of 10.1.0.2.0 that I am currently using on Windows. Did anyone experience similar compilation errors?
Thanks for any help/info in advance.
Maybe you are looking for
-
I have 3 tapes from an event to capture and edit with my Panasonic DVX100B. The first tape captured fine. A couple of days later I try to capture another tape and suddenly I get "unable to initialize deck"! I have... 1) Tried to capture on my Macbook
-
I know there have been a lot of discussions about red frames in CC, I think I've read them all and tried every solution, here's my situation in case there is something that I missed. I work with many long (2 hour plus) .mov files with the AVdn codec
-
I have created a series of podcasts for my website using Garageband that went off without a hitch. I dropped in artwork and also episode artwork in the lower lefthand corner in GB. I exported to iWeb with no problems but hit a snag when uploading to
-
Ok, I've been pulling my hair out with this one all morning. The following code is causing a memory leak which eventually crashes tomcat. I'm hoping another set of eyes can find where the problem is. Right now I'm thinking it's inside the sun.jdbc.od
-
IPhone 3GS - Seriously - How Good?
Ok, had a Nokia N97, and if I had any hair, it would have been all pulled out at this stage. Terrible terrible handset, no support from the retailer ( here in Saudi ) and jaw droppingly shocking Customer care from Nokia. Please don't be offended when