Iwl3945 and Core Dump

Hi,
Had some problems connecting to my Wifi Network using core dump after installation. The problem was that the WPA_Supplicant was giving an ioctl [ SIOCSIWSSCAN ] error, saying resource temporarily unavailable.
All the details were correct in the wpa_supplicant and network profiles. So was rather confused, especially seeing as i had done a network install only minutes prior.
Tracked it down to a discrepancy in the driver versions used on the cd and that installed onto the system. The cd uses iwl3945 1.1.21 and the installed system 1.2.0ds.
Swapping the drivers over instantly solved the problem. This was on a Toshiba Satellite A200-1TO for reference.
Works perfectly now... Clearly
Just thought i'd mention this incase anyone has/or has had similar problems with the intel 3945 wireless adaptor. Was also wondering if anyone has a fix for this, as it'd surely be better to be using the later driver?

Might be worth filing a bug report with the intel wireless devs, the ds part sounds like a beta or something.

Similar Messages

Recycle Bin and Core Dump

Hi Friends,
Why do we use core dump I mean "core_dump_dest" till now I didn't see any files in this particular destination.
My 2nd Question is where is the Recycle Bin created and can we adjust the size of the recycle bin according to our requirement.
Say,
SQL>> drop table stock;
I can get back the table from the recyclebin using flashback option. I heard recyclebin stores in the same datafile pertaining to the table dropped.
Update me regarding this.
Cheers,
Sailesh

Hi,
>>Why do we use core dump I mean "core_dump_dest" till now I didn't see any files in this particular destination
"A core dump is a memory image of the Oracle shadow process produced when an unexpected , unrecoverable or invalid condition occurs." It seems it was primarily used on Unix platforms and I think they are normally produced when the session or the instance terminates abnormally with errors.
>>My 2nd Question is where is the Recycle Bin created and can we adjust the size of the recycle bin according to our requirement.
In fact, the recycle bin is a logical structure within each tablespace that holds dropped tables and objects related to the tables, such as indexes. By the way, there is no such initialization parameter that can limit the "size" of the recyclebin. In addition, according to documentation, the objects in the recycle bin are dropped to satisfy space requests before any of the tablespace’s datafiles are autoextended.
Cheers
Legatti

Any experience with iAS 6.0 SP1 and core dumps from .kjs?

We've been dumping core daily (2+ gig). Any reason why .kjs would be doing this? We're upgrading to SP4 soon, but we're wondering if we'll still run into this problem.

Hi,
2+ gigs daily?? OMG. There might be many reasons for KJS core dumps.I suspect there should be some connection problem, Whats the database do u use?.
I dont think any reason to connect with migrating to SP4 as far u have determined the reason of core dump.So its important to find the cause of KJS core dump.
Regards,
T.Raghulan.

Process core dumps when spawned by Runtime.exec()

I am using a Runtime.exec() command to spawn a local executable process on HP-UX. The local process (C++ executable) starts and is functional, though at a certain point during operation, the process creates a segmentation fault and core dumps. If the same process is spawned manully from a shell, this does not occur.
The process cores at the same point every time (a call to free+ in the system libC library). I have duplicated as much of my shell environment in the Runtime.exec() call as possible. Also, this issue does not occur on AIX or Linux (ports of my code to those platforms).
What is the fundimental difference between spawning a process from a shell V.S. the JVM spawning the process that could cause this difference in behavior?
java version "1.4.2.07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2.07-050121-15:53)
Java HotSpot(TM) Server VM (build 1.4.2 1.4.2.07-050121-17:30-PA_RISC2.0 PA2.0 (aCC_AP), mixed mode)

We are currently having the same problem, it is killing us.
We have upgraded to jdk 1.6u16 and still have the problem.
We think it is related to sparc platform we had been running for some time with same code on X86 server
Our solaris release is: Solaris 10 11/06 s10s_u3wos_10 SPARC
We can't get a reproducible small test case. It is getting us most often when the JVM running our
appserver uses the Runtime.getRuntime().exec(cmd);
We are jumping through hoops looking for workaround. We are trying to write a command server that can
have the command sent through a socket and have all the ouput sent back over the same socket.
That way the app server JVM is not the one doing the fork and exec.

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

Using Calendar client version 4.6 on Unix to connect to Calendar Server 4.0, I get a core dump and the client does not launch

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

Core dump (WL - 4.5 and Solaris 7)

We are using WebLogic 4.5 on Solaris 7. Some times the WebLogic dumps core and exits. There is no pattern for it. I am attaching the core generated:
Could there be a solution some one knows of.
Thanks.
-manish
kghalo bad size 0x15330128
********** Internal heap ERROR KGHALO2 addr=0x0 *********
HEAP DUMP heap name="Alloc environm" desc=0x37083f4
extent sz=0x1024 alt=32 het=32767 rec=0 flg=3 opc=2
parent=0 owner=0 nex=0 xsz=0x17a0
EXTENT 0
Chunk 3daff00 sz= 6040 free " "
EXTENT 1
Chunk 4a857b8 sz= 12040 free " "
EXTENT 2
Chunk 3eaac98 sz= 6372 free " "
EXTENT 3
Chunk 3dacfe8 sz= 12040 free " "
EXTENT 4
Chunk 37567a0 sz= 4660 free " "
Chunk 37579d4 sz= 4144 recreate "Alloc statemen " latch=0
ds 3758d70 sz= 4144 ct= 1
Chunk 3758a04 sz= 1080 freeable assoc with mark prv=0 nxt=0
Chunk 3758e3c sz= 4144 recreate "Alloc statemen " latch=0
ds 375a1d8 sz= 4144 ct= 1
Chunk 3759e6c sz= 1080 freeable assoc with mark prv=0 nxt=0
Chunk 375a2a4 sz= 28 freeable assoc with mark prv=0 nxt=0
Chunk 375a2c0 sz= 5224 free " "
Chunk 375b728 sz= 20 freeable assoc with mark prv=0 nxt=0
Chunk 375b73c sz= 20 freeable assoc with mark prv=0 nxt=0
Chunk 375b750 sz= 256 freeable assoc with mark prv=0 nxt=0
EXTENT 5
Chunk 404b50 sz= 13328 freeable "Alloc server h " ds=3709408
EXTENT 6
Chunk 3708980 sz= 40 perm "perm " alo=40
Chunk 37089a8 sz= 2212 recreate "Alloc server h " latch=0
ds 3709408 sz= 15540 ct= 2
404b50 sz= 13328
Chunk 370924c sz= 104 freeable assoc with mark prv=0 nxt=0
Chunk 37092b4 sz= 444 freeable assoc with mark prv=0 nxt=0
Chunk 3709470 sz= 1308 freeable assoc with mark prv=0 nxt=0
Total heap size = 74584
FREE LISTS:
Bucket 0 size=272
Bucket 1 size=528
Bucket 2 size=1040
Chunk 37567a0 sz= 4660 free " "
Chunk 3dacfe8 sz= 12040 free " "
Chunk 3eaac98 sz= 6372 free " "
Chunk 4a857b8 sz= 12040 free " "
Chunk 3daff00 sz= 6040 free " "
Chunk 375a2c0 sz= 5224 free " "
Total free space = 46376
UNPINNED RECREATABLE CHUNKS (lru first):
PERMANENT CHUNKS:
Chunk 3708980 sz= 40 perm "perm " alo=40
Permanent space = 40
Hla: 0
kgepop: no error frame to pop to for error 0
Segmentation Fault
si_signo [11]: Segmentation Fault
si_errno [0]: Error 0
si_code [1]: SEGV_MAPERR [addr: 0x0]
stackpointer=F9FBFC50
"SSLListenThread" (TID:0x3a8b58c, sys_thread_t:0x3a8b510, state:R, thread_t: t@30, threadID:0xf8d91dc8, stack_bottom:0xf8d92000, sta
ck_size:0x20000) prio=5
[1] java.net.PlainSocketImpl.socketAccept(Native Method)
[2] java.net.PlainSocketImpl.accept(PlainSocketImpl.java:406)
[3] java.net.ServerSocket.implAccept(ServerSocket.java:241)
[4] java.net.ServerSocket.accept(ServerSocket.java:224)
[5] weblogic.security.SSL.SSLServerSocket.acceptNoHandshake(SSLServerSocket.java:121)
[6] weblogic.security.SSL.SSLServerSocket.accept(SSLServerSocket.java:112)
[7] weblogic.t3.srvr.ListenThread.run(ListenThread.java:277)
"ListenThread" (TID:0x3a7b294, sys_thread_t:0x3a7b218, state:R, thread_t: t@29, threadID:0xf8e41dc8, stack_bottom:0xf8e42000, stack_
size:0x20000) prio=5
[1] java.net.PlainSocketImpl.socketAccept(Native Method)
[2] java.net.PlainSocketImpl.accept(PlainSocketImpl.java:406)
[3] java.net.ServerSocket.implAccept(ServerSocket.java:241)
[4] java.net.ServerSocket.accept(ServerSocket.java:224)
[5] weblogic.t3.srvr.ListenThread.run(ListenThread.java:277)
"ExecuteThread-14" (TID:0x54e104, sys_thread_t:0x54e088, state:MW, thread_t: t@25, threadID:0xf8eb1dc8, stack_bottom:0xf8eb2000, sta
ck_size:0x20000) prio=5
[1] weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:269)
[2] weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
[3] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
"ExecuteThread-13" (TID:0x59c504, sys_thread_t:0x59c488, state:R, thread_t: t@24, threadID:0xf8ee1dc8, stack_bottom:0xf8ee2000, stac
k_size:0x20000) prio=5
[1] weblogic.socket.PosixSocketMuxer.poll(Native Method)
[2] weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:270)
[3] weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
"ExecuteThread-12" (TID:0x5ba504, sys_thread_t:0x5ba488, state:MW, thread_t: t@23, threadID:0xf8f11dc8, stack_bottom:0xf8f12000, sta
ck_size:0x20000) prio=5
[1] weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:269)
[2] weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
[3] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
"ExecuteThread-11" (TID:0x4f62ec, sys_thread_t:0x4f6270, state:CW, thread_t: t@22, threadID:0xf8f41dc8, stack_bottom:0xf8f42000, sta
ck_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-10" (TID:0x52810c, sys_thread_t:0x528090, state:CW, thread_t: t@21, threadID:0xf8f71dc8, stack_bottom:0xf8f72000, sta
ck_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-9" (TID:0x53050c, sys_thread_t:0x530490, state:CW, thread_t: t@20, threadID:0xf9171dc8, stack_bottom:0xf9172000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-8" (TID:0x53210c, sys_thread_t:0x532090, state:CW, thread_t: t@19, threadID:0xf9e61dc8, stack_bottom:0xf9e62000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-7" (TID:0x55ed3c, sys_thread_t:0x55ecc0, state:CW, thread_t: t@18, threadID:0xf9e91dc8, stack_bottom:0xf9e92000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-6" (TID:0x5c750c, sys_thread_t:0x5c7490, state:CW, thread_t: t@17, threadID:0xf9ec1dc8, stack_bottom:0xf9ec2000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-5" (TID:0x5cc514, sys_thread_t:0x5cc498, state:CW, thread_t: t@16, threadID:0xf9ef1dc8, stack_bottom:0xf9ef2000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-4" (TID:0x5d091c, sys_thread_t:0x5d08a0, state:R, thread_t: t@15, threadID:0xf9fc1dc8, stack_bottom:0xf9fc2000, stack
_size:0x20000) prio=5 current thread
[1] weblogic.db.oci.OciCursor.exec(Native Method)
[2] weblogic.db.oci.OciCursor.oci_exec(OciCursor.java:1823)
[3] weblogic.jdbcbase.oci.Statement.executeUpdate(Statement.java:846)
[4] weblogic.jdbcbase.oci.Statement.execute(Statement.java:1361)
[5] weblogic.jdbc20.pool.PreparedStatement.execute(PreparedStatement.java:27)
[6] weblogic.jdbc20.rmi.internal.PreparedStatementImpl.execute(PreparedStatementImpl.java:288)
[7] weblogic.jdbc20.rmi.SerialPreparedStatement.execute(SerialPreparedStatement.java:401)
[8] com.ebd.oss.isp.model.ISPModel.getContactInfo(ISPModel.java:242)
[9] com.ebd.oss.isp.model.ISPModel.getISPInfoByID(ISPModel.java:634)
[10] jsp_servlet._ruUpdateContact._jspService(_ruUpdateContact.java:110)
[11] weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
[12] weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:105)
[13] weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:240)
[14] weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:161)
[15] jsp_servlet._Template._jspService(_Template.java:106)
[16] weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
[17] weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:105)
[18] weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:143)
[19] jsp_servlet._Main._jspService(_Main.java:204)
[20] weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
[21] weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:105)
[22] weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:742)
[23] weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:686)
[24] weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:247)
[25] weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:361)
[26] weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:261)
[27] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
"ExecuteThread-3" (TID:0x5c7934, sys_thread_t:0x5c78b8, state:CW, thread_t: t@14, threadID:0xf9ff1dc8, stack_bottom:0xf9ff2000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-2" (TID:0x5cb534, sys_thread_t:0x5cb4b8, state:CW, thread_t: t@13, threadID:0xfe041dc8, stack_bottom:0xfe042000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-1" (TID:0x5d1534, sys_thread_t:0x5d14b8, state:CW, thread_t: t@12, threadID:0xfe071dc8, stack_bottom:0xfe072000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-0" (TID:0x5d1a2c, sys_thread_t:0x5d19b0, state:CW, thread_t: t@11, threadID:0xfe0a1dc8, stack_bottom:0xfe0a2000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"TimeEventGenerator" (TID:0x599694, sys_thread_t:0x599618, state:CW, thread_t: t@10, threadID:0xfe0d1dc8, stack_bottom:0xfe0d2000, s
tack_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] weblogic.time.common.internal.TimeTable.snooze(TimeTable.java:252)
[3] weblogic.time.common.internal.TimeEventGenerator.run(TimeEventGenerator.java:141)
[4] java.lang.Thread.run(Thread.java:485)
"SpinnerRandomSource" (TID:0x55f2a4, sys_thread_t:0x55f228, state:CW, thread_t: t@8, threadID:0xfec41dc8, stack_bottom:0xfec42000, s
tack_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.security.SpinnerThread.stopSpinning(SpinnerRandomBitsSource.java:104)
[4] weblogic.security.SpinnerThread.run(SpinnerRandomBitsSource.java:121)
Exiting Thread (sys_thread_t:0xff2cace0) : no stack
"Finalizer" (TID:0x172e84, sys_thread_t:0x172e08, state:CW, thread_t: t@6, threadID:0xfed31dc8, stack_bottom:0xfed32000, stack_size:
0x20000) prio=8
[1] java.lang.Object.wait(Native Method)
[2] java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:113)
[3] java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:128)
[4] java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:175)
"Reference Handler" (TID:0x16ed54, sys_thread_t:0x16ecd8, state:CW, thread_t: t@5, threadID:0xfed61dc8, stack_bottom:0xfed62000, sta
ck_size:0x20000) prio=10
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115)
"Signal dispatcher" (TID:0x14e1e4, sys_thread_t:0x14e168, state:MW, thread_t: t@4, threadID:0xfed91dc8, stack_bottom:0xfed92000, sta
ck_size:0x20000) prio=10
"main" (TID:0x39974, sys_thread_t:0x398f8, state:CW, thread_t: t@1, threadID:0x24ac8, stack_bottom:0xffbf0000, stack_size:0x20000) p
rio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.t3.srvr.T3Srvr.waitForDeath(T3Srvr.java:1791)
[4] java.lang.reflect.Method.invoke(Native Method)
[5] weblogic.Server.startServerDynamically(Server.java:107)
[6] weblogic.Server.main(Server.java:65)
[7] weblogic.Server.main(Server.java:55)
Abort - core dumped

The current thread shows JVM has core dumped on a native OCI call.
Type-2 drivers need to make OCI calls to connect to the Database server and since OCI calls are in C,
there is a possibility that C code is causing JVM to crash.
I would recommend you to give it a try with type-4 driver and see if you can get rid of core dumps.
Kumar
manish wrote:
We are using WebLogic 4.5 on Solaris 7. Some times the WebLogic dumps core and exits. There is no pattern for it. I am attaching the core generated:
Could there be a solution some one knows of.
Thanks.
-manish
kghalo bad size 0x15330128
********** Internal heap ERROR KGHALO2 addr=0x0 *********
HEAP DUMP heap name="Alloc environm" desc=0x37083f4
extent sz=0x1024 alt=32 het=32767 rec=0 flg=3 opc=2
parent=0 owner=0 nex=0 xsz=0x17a0
EXTENT 0
Chunk 3daff00 sz= 6040 free " "
EXTENT 1
Chunk 4a857b8 sz= 12040 free " "
EXTENT 2
Chunk 3eaac98 sz= 6372 free " "
EXTENT 3
Chunk 3dacfe8 sz= 12040 free " "
EXTENT 4
Chunk 37567a0 sz= 4660 free " "
Chunk 37579d4 sz= 4144 recreate "Alloc statemen " latch=0
ds 3758d70 sz= 4144 ct= 1
Chunk 3758a04 sz= 1080 freeable assoc with mark prv=0 nxt=0
Chunk 3758e3c sz= 4144 recreate "Alloc statemen " latch=0
ds 375a1d8 sz= 4144 ct= 1
Chunk 3759e6c sz= 1080 freeable assoc with mark prv=0 nxt=0
Chunk 375a2a4 sz= 28 freeable assoc with mark prv=0 nxt=0
Chunk 375a2c0 sz= 5224 free " "
Chunk 375b728 sz= 20 freeable assoc with mark prv=0 nxt=0
Chunk 375b73c sz= 20 freeable assoc with mark prv=0 nxt=0
Chunk 375b750 sz= 256 freeable assoc with mark prv=0 nxt=0
EXTENT 5
Chunk 404b50 sz= 13328 freeable "Alloc server h " ds=3709408
EXTENT 6
Chunk 3708980 sz= 40 perm "perm " alo=40
Chunk 37089a8 sz= 2212 recreate "Alloc server h " latch=0
ds 3709408 sz= 15540 ct= 2
404b50 sz= 13328
Chunk 370924c sz= 104 freeable assoc with mark prv=0 nxt=0
Chunk 37092b4 sz= 444 freeable assoc with mark prv=0 nxt=0
Chunk 3709470 sz= 1308 freeable assoc with mark prv=0 nxt=0
Total heap size = 74584
FREE LISTS:
Bucket 0 size=272
Bucket 1 size=528
Bucket 2 size=1040
Chunk 37567a0 sz= 4660 free " "
Chunk 3dacfe8 sz= 12040 free " "
Chunk 3eaac98 sz= 6372 free " "
Chunk 4a857b8 sz= 12040 free " "
Chunk 3daff00 sz= 6040 free " "
Chunk 375a2c0 sz= 5224 free " "
Total free space = 46376
UNPINNED RECREATABLE CHUNKS (lru first):
PERMANENT CHUNKS:
Chunk 3708980 sz= 40 perm "perm " alo=40
Permanent space = 40
Hla: 0
kgepop: no error frame to pop to for error 0
Segmentation Fault
si_signo [11]: Segmentation Fault
si_errno [0]: Error 0
si_code [1]: SEGV_MAPERR [addr: 0x0]
stackpointer=F9FBFC50
"SSLListenThread" (TID:0x3a8b58c, sys_thread_t:0x3a8b510, state:R, thread_t: t@30, threadID:0xf8d91dc8, stack_bottom:0xf8d92000, sta
ck_size:0x20000) prio=5
[1] java.net.PlainSocketImpl.socketAccept(Native Method)
[2] java.net.PlainSocketImpl.accept(PlainSocketImpl.java:406)
[3] java.net.ServerSocket.implAccept(ServerSocket.java:241)
[4] java.net.ServerSocket.accept(ServerSocket.java:224)
[5] weblogic.security.SSL.SSLServerSocket.acceptNoHandshake(SSLServerSocket.java:121)
[6] weblogic.security.SSL.SSLServerSocket.accept(SSLServerSocket.java:112)
[7] weblogic.t3.srvr.ListenThread.run(ListenThread.java:277)
"ListenThread" (TID:0x3a7b294, sys_thread_t:0x3a7b218, state:R, thread_t: t@29, threadID:0xf8e41dc8, stack_bottom:0xf8e42000, stack_
size:0x20000) prio=5
[1] java.net.PlainSocketImpl.socketAccept(Native Method)
[2] java.net.PlainSocketImpl.accept(PlainSocketImpl.java:406)
[3] java.net.ServerSocket.implAccept(ServerSocket.java:241)
[4] java.net.ServerSocket.accept(ServerSocket.java:224)
[5] weblogic.t3.srvr.ListenThread.run(ListenThread.java:277)
"ExecuteThread-14" (TID:0x54e104, sys_thread_t:0x54e088, state:MW, thread_t: t@25, threadID:0xf8eb1dc8, stack_bottom:0xf8eb2000, sta
ck_size:0x20000) prio=5
[1] weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:269)
[2] weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
[3] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
"ExecuteThread-13" (TID:0x59c504, sys_thread_t:0x59c488, state:R, thread_t: t@24, threadID:0xf8ee1dc8, stack_bottom:0xf8ee2000, stac
k_size:0x20000) prio=5
[1] weblogic.socket.PosixSocketMuxer.poll(Native Method)
[2] weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:270)
[3] weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
"ExecuteThread-12" (TID:0x5ba504, sys_thread_t:0x5ba488, state:MW, thread_t: t@23, threadID:0xf8f11dc8, stack_bottom:0xf8f12000, sta
ck_size:0x20000) prio=5
[1] weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:269)
[2] weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
[3] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
"ExecuteThread-11" (TID:0x4f62ec, sys_thread_t:0x4f6270, state:CW, thread_t: t@22, threadID:0xf8f41dc8, stack_bottom:0xf8f42000, sta
ck_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-10" (TID:0x52810c, sys_thread_t:0x528090, state:CW, thread_t: t@21, threadID:0xf8f71dc8, stack_bottom:0xf8f72000, sta
ck_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-9" (TID:0x53050c, sys_thread_t:0x530490, state:CW, thread_t: t@20, threadID:0xf9171dc8, stack_bottom:0xf9172000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-8" (TID:0x53210c, sys_thread_t:0x532090, state:CW, thread_t: t@19, threadID:0xf9e61dc8, stack_bottom:0xf9e62000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-7" (TID:0x55ed3c, sys_thread_t:0x55ecc0, state:CW, thread_t: t@18, threadID:0xf9e91dc8, stack_bottom:0xf9e92000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-6" (TID:0x5c750c, sys_thread_t:0x5c7490, state:CW, thread_t: t@17, threadID:0xf9ec1dc8, stack_bottom:0xf9ec2000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-5" (TID:0x5cc514, sys_thread_t:0x5cc498, state:CW, thread_t: t@16, threadID:0xf9ef1dc8, stack_bottom:0xf9ef2000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-4" (TID:0x5d091c, sys_thread_t:0x5d08a0, state:R, thread_t: t@15, threadID:0xf9fc1dc8, stack_bottom:0xf9fc2000, stack
_size:0x20000) prio=5 current thread
[1] weblogic.db.oci.OciCursor.exec(Native Method)
[2] weblogic.db.oci.OciCursor.oci_exec(OciCursor.java:1823)
[3] weblogic.jdbcbase.oci.Statement.executeUpdate(Statement.java:846)
[4] weblogic.jdbcbase.oci.Statement.execute(Statement.java:1361)
[5] weblogic.jdbc20.pool.PreparedStatement.execute(PreparedStatement.java:27)
[6] weblogic.jdbc20.rmi.internal.PreparedStatementImpl.execute(PreparedStatementImpl.java:288)
[7] weblogic.jdbc20.rmi.SerialPreparedStatement.execute(SerialPreparedStatement.java:401)
[8] com.ebd.oss.isp.model.ISPModel.getContactInfo(ISPModel.java:242)
[9] com.ebd.oss.isp.model.ISPModel.getISPInfoByID(ISPModel.java:634)
[10] jsp_servlet._ruUpdateContact._jspService(_ruUpdateContact.java:110)
[11] weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
[12] weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:105)
[13] weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:240)
[14] weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:161)
[15] jsp_servlet._Template._jspService(_Template.java:106)
[16] weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
[17] weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:105)
[18] weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:143)
[19] jsp_servlet._Main._jspService(_Main.java:204)
[20] weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
[21] weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:105)
[22] weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:742)
[23] weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:686)
[24] weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:247)
[25] weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:361)
[26] weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:261)
[27] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
"ExecuteThread-3" (TID:0x5c7934, sys_thread_t:0x5c78b8, state:CW, thread_t: t@14, threadID:0xf9ff1dc8, stack_bottom:0xf9ff2000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-2" (TID:0x5cb534, sys_thread_t:0x5cb4b8, state:CW, thread_t: t@13, threadID:0xfe041dc8, stack_bottom:0xfe042000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-1" (TID:0x5d1534, sys_thread_t:0x5d14b8, state:CW, thread_t: t@12, threadID:0xfe071dc8, stack_bottom:0xfe072000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"ExecuteThread-0" (TID:0x5d1a2c, sys_thread_t:0x5d19b0, state:CW, thread_t: t@11, threadID:0xfe0a1dc8, stack_bottom:0xfe0a2000, stac
k_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:90)
[4] weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)
"TimeEventGenerator" (TID:0x599694, sys_thread_t:0x599618, state:CW, thread_t: t@10, threadID:0xfe0d1dc8, stack_bottom:0xfe0d2000, s
tack_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] weblogic.time.common.internal.TimeTable.snooze(TimeTable.java:252)
[3] weblogic.time.common.internal.TimeEventGenerator.run(TimeEventGenerator.java:141)
[4] java.lang.Thread.run(Thread.java:485)
"SpinnerRandomSource" (TID:0x55f2a4, sys_thread_t:0x55f228, state:CW, thread_t: t@8, threadID:0xfec41dc8, stack_bottom:0xfec42000, s
tack_size:0x20000) prio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.security.SpinnerThread.stopSpinning(SpinnerRandomBitsSource.java:104)
[4] weblogic.security.SpinnerThread.run(SpinnerRandomBitsSource.java:121)
Exiting Thread (sys_thread_t:0xff2cace0) : no stack
"Finalizer" (TID:0x172e84, sys_thread_t:0x172e08, state:CW, thread_t: t@6, threadID:0xfed31dc8, stack_bottom:0xfed32000, stack_size:
0x20000) prio=8
[1] java.lang.Object.wait(Native Method)
[2] java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:113)
[3] java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:128)
[4] java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:175)
"Reference Handler" (TID:0x16ed54, sys_thread_t:0x16ecd8, state:CW, thread_t: t@5, threadID:0xfed61dc8, stack_bottom:0xfed62000, sta
ck_size:0x20000) prio=10
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115)
"Signal dispatcher" (TID:0x14e1e4, sys_thread_t:0x14e168, state:MW, thread_t: t@4, threadID:0xfed91dc8, stack_bottom:0xfed92000, sta
ck_size:0x20000) prio=10
"main" (TID:0x39974, sys_thread_t:0x398f8, state:CW, thread_t: t@1, threadID:0x24ac8, stack_bottom:0xffbf0000, stack_size:0x20000) p
rio=5
[1] java.lang.Object.wait(Native Method)
[2] java.lang.Object.wait(Object.java:424)
[3] weblogic.t3.srvr.T3Srvr.waitForDeath(T3Srvr.java:1791)
[4] java.lang.reflect.Method.invoke(Native Method)
[5] weblogic.Server.startServerDynamically(Server.java:107)
[6] weblogic.Server.main(Server.java:65)
[7] weblogic.Server.main(Server.java:55)
Abort - core dumped

Core dump with stlport4 and string pointers

Hello,
I am porting from SGI Irix to Sun Solaris, using OS 8 and Sun Studio 8. The program we are porting is very very large. We've compiled all code, but now are getting core dumps on several of the executables. We have traced one of the core dumps to a function that deals with string manipulation/string pointers. We wrote a very simple test program that re-produces the problem.
#include <string>
#include <iostream>
void test(char* m)
std::cout << m << " in test before";
m[0] = 'z';
std::cout << m << " in test after";
void main(void)
char* temp = new char[10];
temp = "abcd";
std::cout << temp << " before test";
test(temp);
std::cout << temp << " after test";
We get the following output:
abcd before test
abcd in test before
Segmentation fault (core dumped)
The code compiles and runs fine on the SGI Irix system. What am I doing wrong?
Thanks,
Bob

1) The signature of "main" is wrong. It must be 'int
main(int, char **)'Not quite. The signatures
int main()
int main(void)
are also allowed. (C++ standard, section 3.6.1 Main function)
A "void" return type on main is not standard, but Sun C++ allows it with a warning. Such a version of main does not return a predictable value to the program that invoked it (usually the shell).
It seems as if the intent of the program is to
allocate a new string with the contents "abcd".
Instead, you allocate a buffer, and then overwrite the
pointer to that buffer with a pointer to a string
constant, to which you then attempt to write.Right. By default, the C++ compiler allocates string literals to read-only memory, to catch mistakes like this. The compiler has an option to store literal strings in read-write memory, but we recommend against using the option, since you should not ever want to modify a literal string.
I am curious why the compiler doesn't complain about
the assignment in main - to my eyes it looks like it
should be complaining that you are assigning a const
char * to a char *The compiler emits a warning about the assignment.
Such code is allowed but deprecated in the C++ standard, because of the deprecated conversion of "array of const char" to char* (section 4.2 Array-to-pointer conversion).

Core Dump - Code built on 2.6 and run on 2.8

Here is a few lines of my core dump:
[1] realfree(0x4f74bd20, 0xfe8c2850, 0xfe8bc004, 0x5, 0x4f000003, 0x74bd28), at 0xfe84235c
[2] freeunlocked(0xfe8c27c4, 0xfe8bc004, 0x751b70, 0xfe8bc004, 0x7253e8, 0x0), at 0xfe842bcc
[3] free(0x751b70, 0xf0024, 0x1, 0xfedfb2c4, 0x40800, 0x0), at 0xfe842b1c
[4] CORBA::String_mgr::~String_mgr(0x728fc4, 0x2, 0xfeeeb2ac, 0xfe8bc004, 0x1, 0x4d58), at 0xfedfb2c4
We have C++ code that is built on a Solaris 2.6 platform but is being run on a Solairs 2.8 platform. The core dump occurs infrequently.
I have not printed lines below line [4] but the structure below that line looks sane. How do I go about figuring out which "string"-free is causing the crash.
Can anyone help me with sorting out the arguments on "realfree"?
Thanks.
Atul

have you tried using gdb?
gdb will let you load up the core file and bring you to the point of the crash, and then let you view the random variables and pointers' actual values...
cuz this output don't say much more than... realfree takes 6 arguments, 5 of which look to be pointers, and the 4th value i'm fairly certain is the number "5"...
with gdb you could take those 5 pointers and look in them...

Tomcat 4.0.5 and JDK 1.4.2 on HP-UX 11i giving core dump

Hi,
I am using Tomcat 4.0.5 web server for a high data volume web based project. I have changed the JDK from 1.3 to 1.4.2. The os is HP-UX 11i. After changing the JDK version, I am getting core dump after every 6 to 7 hours and Tomcat fails to continue.
Pls, tell me is it due to version mismatch or anything else.
Regards
Kousik Mukherjee

Hi,
If you have not already done so .. make sure that the latest patches that are required for 1.4.2 on HP-UX are installed (requires patch PHNE_29887 for HP-UX 11.11 (11i v1) PA-RISC. The patch solves socket problems that may cause hangs.) I think there may be some others as well ...
Good luck
LSH

SunMC agent core dump but has a limit of zero and wont actually core dump

Greetings,
Before I put a call in with Sun, I thought I would find if anyone else has a similiar problem. I have SunMC 3.5.1 running on a number of platforms and generally it is quite stable. I do have a number of SunFire 1280's (Netra T-12 to SunMC) each with 3 system boards with 96 GB of RAM. These systems are worked pretty hard and about every day or so, each agent on each system crashes. The problem is that there is a limit of zero for the agent core dump and it wont produce a core dump. Other processes dump with no problems. I gather they may be some limit in one of the SunMC config files but I don't know where to look. Without a core dump, it makes life hard to work out what causes it. I am only running the basic module monitoring so nothing else is loaded. If the basic module wont stay up, then why spend money to but in advanced monitoring????
Any info would be appreciated. I have worked with the fabulous Sun team regarding SunMC and I find months waiting for an answer somewhat frustrating.
Regards
Stephen

Hi Ian,
Thanks for the info. I will have a look at the patches. I noticed 3.5.1b has been released but as per usual, Sun does not really put much effort into saying what is good about it and why we should make the effort for upgrading. I could not wait to move from version 3 to 3.5 as it was so hard to manage patchwise.
One other thing that annoys me no end is the SunRay integration (/opt/SUNWut/sbin/utsunmc) alarms that appear. Once or twice, when I try to acknowledge the alarm, it just hangs. The event log says that I am trying to acknowledge an event that does not exist.
But then again, it has to be good because it does not cost anything other than time and the millions of dollars we spend on Sun equipment so we can use SunMC. That much money is better spend on hardware then on Tivoli right?? I think I can get a base model 25k for less than implementing Tivoli.
Regards
Stephen

DSEE 6.3.1 multiple consumer and hub instances core dumped at once

We are in a transition phase, our master servers are DS5.2 systems. The masters replicate to the DSEE6.3.1 hubs which in turn replicate to DSEE6.3.1 consumers. The other day the entire DSEE6.3.1 nsslapd instance processes on each of the hub and consumer servers core dumped (so much for failover capability) at the same time.
Given that information, I was thinking there was something replicated that DSEE6.3.1 didn't like. Access and Error logs were of no assistance - showing normal operations and no shutdown messages. I looked at the audit files on the DS5.2 system and compared them to the DSEE6.3.1 system. The last change made to the DS5.2 system was a modrdn changetype. We have the referrential integrity plug-in enabled. I've been able to repeat the problem once on one of the DSEE6.3.1 consumers, but the other instances stayed operational. The process handles many modrdn's properly but when it does fail (core dumps), it seems to be failing on a modrdn. Once I start the process and database recovery is complete, replication resumes (including the modrdn operation it seemed to fail on). During development, I saw core dumps very seldomly with DSEE6.3.1; but since deploying with replication from DS5.2 masters, it seems to be happening more often. Is this a known issue?
We are using DSEE 6.3.1 as our replacement Enterprise Solution for the aging DS5.2 software. If the software is going to core dump, perhaps this is not a wise decision.

Forgot to mention platform and OS - SPARC Solaris 10.

Getting "Baseband Core dump in progress" and after that 3G doesn't work

My iPhone 4 told me several times that there is a Baseband Core dump in progress. After that my 3G connection doesn't work anymore. Only a reboot of the iPhone solves the damaged connection.
This behavior is going to make me angry. Can someone tell me how to solve this issue?
P.S: I'm not using any beta iOS Version.

It's basically dumping a bunch of information from memory about the current state of the kernel and what not, so that it has a detailed error report to send to Apple. This data is uploaded to Apple when you sync with iTunes. Essentially an execution path of "core code". This is behavior typical of beta software, yet you state you're not running beta software on your phone...are you positive? If not, I've seen this with jailbroken phones.

Core dump in _smalloc via std::valarray and __rwstd::_RW_array

Hello All,
I am developing shared libraries for Solaris 5.8 using CC v5.4 (Sun Forte 7).
These libraries are integrated with application software built with CC v5.6 (Sun Studio 9) also on Solaris 5.8.
The libraries I supply are accessed via a defined C API by the application using "dlopen".
My libraries in turn depend on other, such as libxerces, libCstd and others.
I have verified that the software libraries work correctly when run in a test harness, whether this is compiled using CC v5.4 or CC v5.6.
The application experiences the following fault:
t@4 (l@4) terminated by signal SEGV (no mapping at the fault address)
0xfeec1c98: _smalloc+0x008c: ld [%o1 + 8], %o0
The business end of the stack trace is as follows:
[5] std::valarray<double>::valarray(
[4] __rwstd::_RW_array<double>::_initial_size(
[3] operator new(0x0, ...
[2] malloc(0x1, ...
[1] _smalloc(0x8, ...
I am looking for developers with similar experiences or knowledge of this problem to try and narrow down the possible causes.
I am currently investigating the following possibilities:
Compiler patch or use -xarch=v8plus.
Inconsistent use of "-DRW_MULTI_THREAD -mt" compiler/linker options.
Incompatibility between libCstd & libstlport.
I have already referred to the following forum entries.
http://forum.java.sun.com/thread.jspa?forumID=850&threadID=5069618
http://forum.java.sun.com/thread.jspa?threadID=5071063
The code causing this core dump is in the initialisation section of the constructor of a C++ object.
class c {
public:
c(); // constructor
protected:
std:valarray m;
a::a()
// Initialisation.
: m(0) { <<<<<<<<<< The core dump occurs in the constructor of this valarray member variable.
// Constructor code.
best regards
Geoff Krechting
Edited by: Geoff.Krechting on Apr 23, 2008 5:14 AM
Edited by: Geoff.Krechting on Apr 23, 2008 7:25 AM

Both C++ 5.4 and 5.6 are End Of Life, and little support is available for them. I recommend you upgrade to Sun Studio 11, the most recent compiler that still supports Solaris 8 (which is also End Of Life). Studio 11 is free for all uses, and rebuilding your code using it should not present any problems. You can get it here:
[http://developers.sun.com/sunstudio/products/previous/11/index.jsp]
If you don't want to change compilers, you can still mix binary code from C++ 5.4 and 5.6. The rule is that you can link binaries created by an older compiler into a program or shared library built with a newer compiler, but not the other way around. That is, you need to use C++ 5.6 for all linking steps, not C++ 5.4.
The problem you are running into might be due to a compiler bug, a bug in the runtime library, or a bug in your code.
You can reduce the chances of compiler or library bugs by getting all the current patches for your compilers and libraries here:
[http://developers.sun.com/sunstudio/downloads/patches/index.jsp]
Be sure to update the C++ runtime libraries not only on the computer where you build, but on computers where the application is run.
The crash you are seeing looks like it's due to memory corruption. Memory corruption can be caused by
- using an uninitialized pointer
- using an invalid pointer:
--- points to a deleted object
--- points to an object whose lifetime has ended
- deleting an object more than once
- mis-matched new/delete operations
Using Run-Time Checking in dbx can help you find some of these problems.
% dbx myprog
% check -all
% run

Hotspot core dumping during JVM garbage collection ?

We have an application which calls a 3rd party supplied server API which has recently been upgraded to use Java 1.5
We are getting the following error reported by our client application. The application is also now running Java 1.5 but references many classes in jar files which would have quite old code in.
The supplier of the API has stated that the problem requires us to recompile all our jar files using v 1.5 ( including things like jconnect and jms ?!?!? ). This sounds like a bit of a cop-out to me, not to mention being impossible since we don't have the source for things like jconnect.
I suspect that there is a garbage collection problem at the bottom of all this, but I'm not sure how I can "prove" this, nor do I currently have any real clue as to how to fix any GC problem that may exist.
The application is supposed to wait for a message on a MQSeries queue and then transforms it via Xalan XSLT and sends it to a Server application. I've tried playing around with heap sizes etc but that just seems to make it worse. If I leave it at the settings that the previous version used then the client at least manages to process a couple of messages before core dumping. There doesn't seem to be a consistent trigger event to cause the core dump ( it's not a message arriving on a queue for example ) but it does seem to be fairly consistent timewise, i.e. after
Any ideas gratefully accepted.
Here's a logfile excerpt from my applications showing the Hotspot error message :
=====================================================================================
08-Jul-2008 10:01:05 Waiting for messages from COLT.BBFS
08-Jul-2008 10:02:05 Waiting for messages from COLT.BBFS
08-Jul-2008 10:03:05 Waiting for messages from COLT.BBFS
405.815: [GC [PSYoungGen: 17331K->9244K(37632K)] 111702K->103615K(192128K), 0.1615910 secs]
405.977: [Full GC#
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V [libjvm.so+0x141348]
# An error report file with more information is saved as hs_err_pid2600.log
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
=====================================================================================
The logfile referred to in the error message contains the following.
=====================================================================================
# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V [libjvm.so+0x141348]
--------------- T H R E A D ---------------
Current thread (0x001484d8): VMThread [id=8]
siginfo:si_signo=10, si_errno=0, si_code=1, si_addr=0x0000080f
Registers:
O0=0x00487588 O1=0xfe7d6454 O2=0x000079b0 O3=0x00007800
O4=0x00008868 O5=0x00147d48 O6=0xf8781460 O7=0xfe0f7938
G1=0xe52aaae8 G2=0x00000003 G3=0x00000003 G4=0x001484d8
G5=0xf8781d98 G6=0x00000002 G7=0xf8781d98 Y=0x805683e2
PC=0xfe141348 nPC=0xfe14134c
Top of Stack: (sp=0xf8781460)
0xf8781460: fe786000 00c6ba20 fe10013c e54bab68
0xf8781470: 0000080f e54bab6c 0000080f 00000004
0xf8781480: 00487588 00000134 e54bab6c 00000004
0xf8781490: 00000001 00000000 f87814c0 fe17aef4
0xf87814a0: fe6485b4 fe7d899c 001484d8 0011da40
0xf87814b0: 00148988 00148c10 00148d7c f8781880
0xf87814c0: 007c3389 007c3c0e 00000f87 00008868
0xf87814d0: 00008800 00487588 fe141310 fe7d6454
Instructions: (pc=0xfe141348)
0xfe141338: ec 06 c0 1a 80 a5 a0 00 22 40 00 0a ba 07 60 01
0xfe141348: f2 05 a0 00 ae 0e 60 03 80 a5 e0 03 22 40 00 05
Stack: [0xf8702000,0xf8781d98), sp=0xf8781460, free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x141348]
V [libjvm.so+0x17aefc]
V [libjvm.so+0x2d557c]
V [libjvm.so+0x300ef8]
V [libjvm.so+0x301e84]
V [libjvm.so+0x2ff950]
V [libjvm.so+0x29df30]
V [libjvm.so+0x362b44]
V [libjvm.so+0x6436f0]
VM_Operation (0xe03012b0): parallel gc system gc, mode: safepoint, requested by thread 0x0031bca0
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x00b2c028 JavaThread "Thread-4" [_thread_in_native, id=85]
0x007f5048 JavaThread "Thread-0" [_thread_blocked, id=84]
0x00c27cf0 JavaThread "Notification Delivery" [_thread_blocked, id=81]
0x0026fa08 JavaThread "RMI LeaseChecker" daemon [_thread_blocked, id=73]
0x00821048 JavaThread "RMI RenewClean-[162.11.2.32:44425]" daemon [_thread_blocked, id=70]
0x0031bca0 JavaThread "GC Daemon" daemon [_thread_blocked, id=67]
0x00cd5d28 JavaThread "RMI Reaper" [_thread_blocked, id=66]
0x003c9300 JavaThread "Timer-0" daemon [_thread_blocked, id=65]
0x00929fe0 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=64]
0x0089bf18 JavaThread "SeedGenerator Thread" daemon [_thread_blocked, id=42]
0x00c47248 JavaThread "Pool thread #7" daemon [_thread_blocked, id=38]
0x00c466a0 JavaThread "Pool thread #6" daemon [_thread_blocked, id=37]
0x00311850 JavaThread "Pool thread #5" daemon [_thread_blocked, id=36]
0x00287a40 JavaThread "Pool thread #4" daemon [_thread_blocked, id=35]
0x00286e98 JavaThread "Pool thread #3" daemon [_thread_blocked, id=34]
0x00c134b0 JavaThread "Pool thread #2" daemon [_thread_blocked, id=33]
0x00ad09e0 JavaThread "Pool thread #1" daemon [_thread_blocked, id=32]
0x00286cd8 JavaThread "PoolThreadManager" daemon [_thread_blocked, id=31]
0x00c129e0 JavaThread "Channel Reaper" daemon [_thread_blocked, id=30]
0x00c669e8 JavaThread "ORB Daemon Thread" daemon [_thread_blocked, id=29]
0x00b10170 JavaThread "Worker for ServerProtocol: (iiop) /0.0.0.0:20168" daemon [_thread_blocked, id=22]
0x008a17e0 JavaThread "Syn~ Client" daemon [_thread_blocked, id=21]
0x003dc378 JavaThread "PoolScavenger0" daemon [_thread_blocked, id=20]
0x0015a928 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=15]
0x00159880 JavaThread "CompilerThread1" daemon [_thread_blocked, id=14]
0x00158a18 JavaThread "CompilerThread0" daemon [_thread_blocked, id=13]
0x00157b98 JavaThread "AdapterThread" daemon [_thread_blocked, id=12]
0x00156dc8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11]
0x0014ccd8 JavaThread "Finalizer" daemon [_thread_blocked, id=10]
0x0014ad90 JavaThread "Reference Handler" daemon [_thread_blocked, id=9]
0x00038238 JavaThread "main" [_thread_in_native, id=1]
Other Threads:
=>0x001484d8 VMThread [id=8]
0x0015c3b0 WatcherThread [id=16]
VM state:at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x00037728/0x00037758] Threads_lock - owner thread: 0x001484d8
[0x00033650/0x00037ba8] Heap_lock - owner thread: 0x0031bca0
Heap
PSYoungGen total 37632K, used 9244K [0xf2eb0000, 0xf7ba0000, 0xf8400000)
eden space 28352K, 0% used [0xf2eb0000,0xf2eb0000,0xf4a60000)
from space 9280K, 99% used [0xf4a60000,0xf5367080,0xf5370000)
to space 25216K, 0% used [0xf6300000,0xf6300000,0xf7ba0000)
PSOldGen total 154496K, used 94371K [0xe8400000, 0xf1ae0000, 0xf2eb0000)
object space 154496K, 61% used [0xe8400000,0xee028e78,0xf1ae0000)
PSPermGen total 35584K, used 18260K [0xe4400000, 0xe66c0000, 0xe8400000)
object space 35584K, 51% used [0xe4400000,0xe55d5158,0xe66c0000)
Dynamic libraries:
0x00010000      /dsdvlp/java/jvm/jdk1.5.0_03/bin/java
0xff350000      /usr/lib/libthread.so.1
0xff340000      /usr/lib/libdl.so.1
0xff200000      /usr/lib/libc.so.1
0xff390000      /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1
0xfe000000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server/libjvm.so
0xff1e0000      /usr/lib/libsocket.so.1
0xff2d0000      /usr/lib/libsched.so.1
0xff1b0000      /usr/lib/libCrun.so.1
0xff160000      /usr/lib/libm.so.1
0xff080000      /usr/lib/libnsl.so.1
0xff060000      /usr/lib/libmp.so.2
0xff030000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/native_threads/libhpi.so
0xfdfc0000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libverify.so
0xfdf80000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libjava.so
0xfdf50000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libzip.so
0xfb7e0000      /usr/lib/locale/en_GB.ISO8859-1/en_GB.ISO8859-1.so.2
0xe4190000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libnet.so
0xe3bd0000      /dsdvlp/lib/5/libSolarisNatives.so
0xe3e90000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/librmi.so
VM Arguments:
jvm_args: -Djava.ext.dirs=/dsdvlp/java/tmijar/firs7/lib/cli:/dsdvlp/java/tmijar/firs7/lib/cli/ext:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB/ext:/dsdvlp/java/tmijar/firs7/lib/cmn:/dsdvlp/java/tmijar/firs7/lib/cmn/ext:/dsdvlp/java/tmijar/firs7/daemonlib -Duser.dir=/dsdvlp/java/tmijar/firs7 -Dopenorb.config=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB/config/SynOpenORB.xml -Dopenorb.home=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB -Dcom.coexis.syn.general.orbbinding=com.coexis.syn.general.orbbinding.openorb.OpenORBBinding_1_4 -Dsun.rmi.dgc.client.gcInterval=360000 -Dsun.rmi.dgc.server.gcInterval=360000000 -Xms32m -Xmx256m -Dcom.coexis.syn.clientcommandsconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/clientcommands.xml -Dcom.coexis.syn.clientconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/fsbbtd_client.xml -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
java_command: com.coexis.syn.mqmessaging.daemon.RunDaemon -p /dsdvlp/bin/5/lndsfsd_fsbbtd.properties start
Environment Variables:
JAVA_HOME=/dsdvlp/java/jvm/jdk150
CLASSPATH=.:/dsdvlp/java/jar/jconnect520.jar:/dsdvlp/java/jar/vbjapp340.jar:/dsdvlp/java/jar/vbjorb340.jar:/dsdvlp/java/jar/javax_jndi120.jar
PATH=/usr/local/etc:/usr/lang:/usr/openwin/bin:/usr/ucb:/bin:/usr/etc:/usr/local/5/bin:/dsdvlp/bin/5:/dsdvlp/bin/4:/home/app/sybase/5/bin:/home/app/sybase/5/localscripts:/home/app/sybase/5/sqr:/home/app/lang:/home/app/lang/SC2.0.1:/usr/ccs/bin:/usr/local/opt/Acrobat3/bin:/dsdvlp/bin:.
LD_LIBRARY_PATH=/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server:/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc:/dsdvlp/java/jvm/jdk1.5.0_03/jre/../lib/sparc:/usr/lib:/usr/openwin/lib:/usr/local/5/lib:/dsdvlp/lib/5:/dstest/lib/5:/home/app/sybase/5/lib:/dstest/cats/sun4/lib:/tmitest/Opus/opus/lib
SHELL=/bin/csh
DISPLAY=CLI00184.mfil.local:1.0
OS=5
--------------- S Y S T E M ---------------
OS: Solaris 8 2/02 s28s_u7wos_08a SPARC
Copyright 2002 Sun Microsystems, Inc. All Rights Reserved.
Assembled 18 December 2001
uname:SunOS 5.8 Generic_117350-20 sun4u (T1 libthread)
rlimit: STACK 8192k, CORE 9216k, NOFILE 4096, AS infinity
load average:2.24 2.67 2.68
CPU:total 4 has_v8, has_v9, has_vis1, has_vis2, is_ultra3
Memory: 8k page, physical 8388608k(166384k free)
vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for solaris-sparc, built on Apr 13 2005 03:31:26 by unknown with unknown Workshop:0x550

The very first suggestion I have is to move your VM to a more recent update of 1.5.0.
It looks like you are crashing with 5.0u3, and I'm pretty sure 5.0u16 is available. You
don't want to waste your time chasing a bug that's already been fixed.

Iwl3945 and Core Dump

Similar Messages

Maybe you are looking for