RWCString mutexes

Hi,
we have a large body of code that was developed mostly in the late 90s and uses RWCStrings all over the place. Someone did a performance analysis on our system a while back and reported that a large amount of time was being spent in acquiring and releasing mutexes used to protect the reference counts in the class, although the locks are always uncontested since we have a single threaded application.
Does any one know if this feature can be turned off ? (perhaps via a compile line option)
thanks in advance.
spc

One other thing. If the entire program is single-threaded, be sure you do not compile or link with the -mt option. If you are using a library other than the one that comes with the Sun C++ compiler, and if it has multiple versions, pick the single-threated version.

Similar Messages

Should I be able to see a priority change using a mutex priority ceiling

If I have a program which uses a mutex lock in solaris 9 which is set up to protect/priority ceiling of 5 and kick it off using priocntl with a priority of 11 and RT, I can look at top and see that it has priority 111. So my process is running real time. I then use a second xterm and wait till the program hits the lock portion of the code. If I do a priocntl -d pid, it is still priority 11. I know it is in the lock because there is a printf and a sleep of 20 seconds. Should I be able to see the priority go to 5? How can I prove the priority inheritance off the mutex lock is working in a test program? Thanks for any insight.

I also tried it with a priority ceiling of 50, figured out that RT priorities worked the reverse of regular priority, the higher the priority number, the higher the priority. I still however am not able to prove the priority inheritance occured. Anybody got any thoughts on how to prove it is working properly.

Should I be able to see a priority change using a mutex lock ?

If I have a program which uses a mutex lock in solaris 9 which is set up to protect/priority ceiling of 5 and kick it off using priocntl with a priority of 11 and RT, I can look at top and see that it has priority 111. So my process is running real time. I then use a second xterm and wait till the program hits the lock portion of the code. If I do a priocntl -d pid, it is still priority 11. I know it is in the lock because there is a printf and a sleep of 20 seconds. Should I be able to see the priority go to 5? How can I prove the priority inheritance off the mutex lock is working in a test program, so that I know I am using it correctly? Thanks for any insight.

I also tried it with a priority ceiling of 50, figured out that RT priorities worked the reverse of regular priority, the higher the priority number, the higher the priority. I still however am not able to prove the priority inheritance occured. Anybody got any thoughts on how to prove it is working properly.

DB Mutex Error with Outbound operation using Normal File adapter in HA env

Hi All,
I Have a simple process which picks data from a weblogic jms queue and writes it to a file. Each day this task is carried out once in a day and it writes approx 30k records to the file. the process is made singleton (singleton property on inbound JMS adapter) and used the HA file adapter to write to the file. This setup gave rise to lot of DB Mutex errors. To avoid the DB mutex issue i pointed the file adapter to use the Normal file adapter connection factory instead of the HA File adapter one used earlier. The surprising thing is even this gave rise to DB mutex errors.
1. Am i missing something here,according to my understanding using a normal file adapter conn factory even in a HA environment should not be creating multiple locks on the file write.
2. Can i change the standard DS used in the file adapter to a custom DS? will that solve the problem?
I hope the scenario is clear. Following is the error extract seen at the process and log level
Exception occured when binding was invoked. Exception occured during invocation of JCA binding: "JCA Binding execute of Reference operation 'Write' failed due to: Unable to acquire mutex for interaction. Unable to acquire mutex for interaction. Unable to acquire lock on resource for "DatabaseMutex::acquireNoSave". ". The invoked JCA adapter raised a resource exception. Please examine the above error message carefully to determine a resolution.
Thanks
Nikhil

We are getting the same error in 11.1.1.5 PS4 version also.Can you post the content of your .jca file here?
Regards,
Anuj

How to set the size of mutex region?

I am using a berkeley xml db on a CMS system.
The server's memory is 562M. When more than 80 users visited the system (without setting the environment configuration of berkeley DB), the berkeley db got the following errors: unable to allocate memory for mutex; resize mutex region.
Firstly, I set the environment configuration programmatically. I used java class EnvironmentConfig.setMutexIncrement(int) to change the region of mutex. However, the same error still happened event after EnvironmentConfig.setMutexIncrement(200) was used.
Therefore, I change the cachesize to 1M. But got the same error.
My config is
config.setCacheSize(1 * 1024 * 1024);
config.setAllowCreate(true);
config.setInitializeCache(true);
config.setInitializeLocking(true);
config.setInitializeLogging(true);
config.setThreaded(true);
Any help would by gratefully received.
Best Regards
Josie

Hi Josie,
The solution is to allocate a bigger number of mutexes to allocate. This can be done by calling DbEnv::mutex_set_max or DbEnv::mutex_set_increment.
For more details, please check here:
C++ APIs: http://www.oracle.com/technology/documentation/berkeley-db/xml/api_cxx/mutex_set_max.html
Java APIs: http://www.oracle.com/technology/documentation/berkeley-db/db/java/com/sleepycat/db/EnvironmentConfig.html#setMaxMutexes(int)
http://www.oracle.com/technology/documentation/berkeley-db/db/java/com/sleepycat/db/EnvironmentConfig.html#setMutexIncrement(int)
Please try to apply the above suggestion, and let me know if it works.
Thanks,
Bogdan Coman

Mutex locking issue on Solaris 10

We are having a problem with mutex locking.
On one scenario we are running our application
On a v245 running Solaris 10 6/06 update 2 patch 118833-24
On our 5120 we are running Solaris 10 8/07 update 4patch 137111-05.
Our application creates several thousand simultaneous mutex inits (pthread_mutex_init). Approx 12 are locked at any one time. Our problem is after several min the application fails because the mutex destroy does not appear to destroy the mutex. This is true only on our 5120 but not on our v245. As a result our application runs fine on the v245 but fails quickly on the 5120.
Do you have any knowledge of why this might be happening?
Any help you can provide in this will be greatly appreciated.
If this is not the right group to post this messages please let me know.
Thanks!

How many threads do you have performing these mutex operations? The 5120 probably runs a lot more concurrent threads than the v245 does, so it's likely you're running into a race condition that's only apparent when the number of concurrent threads is large enough.
What kind of mutexes are they? Recursive, process-shared, "normal"? Where are they located? Dynamically-allocated heap memory, local stack variables, mmap()'d memory? If they're recursive or "normal" mutexes in heap memory, you've most likely got a race condition in your application, because the source code at opensolaris.org for pthread_mutex_destroy() is pretty much nothing but "memset( &mutex, 0, sizeof( mutex ) )" for normal mutexes. It's hard to imagine how that could fail.
You can use the race-condition tools that are part of Sun Studio 12 or another memory-checking application such as Purify to find out where your error may be. Given the timing issues apparently involved, those are probably your best options. The overhead of tools such as watchmalloc or even the run-time memory checker in Sun Studio may be too much and mask your timing issues. Assuming that's what the root cause of your problem is.
I didn't look at what's involved in destroying a process-shared mutex, though. That's a lot more complicated.
On edit: How do you know that pthread_mutex_destroy() is not destroying the mutex?
Edited by: AndrewHenle on Jun 16, 2009 3:46 PM

Core dump at ::~RWCString

I am compiling with V5.0 compiler on solaris 2.6
I am getting the following core dump. I am using RogueWave with -library=rwtools7,iostream
compiler option.
The traceback from the core file is:
signal SEGV (no mapping at the fault address) in RWReference::removeRe
ference at 0x77ba70
0x0077ba70: removeReference+0x0038: ld [%i0], %i0
(/opt/shared/sun/workshop/v5.0/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) where
current thread: t@1
=>[1] RWReference::removeReference(0x323030f4, 0x323030f4, 0xd2dc60, 0xfede36f8,
0x81010100, 0x0), at 0x77ba70
[2] RWCString::~RWCString(0x323030f4, 0x9aa2bc, 0xffbed85c, 0x638790, 0x16608,
0xd30c14), at 0x76e868
[3] StSearchEng::searchbydetail(0xffbedaf0, 0xed2b38, 0x0, 0xd30bcc, 0x986074,
0x0), at 0x6387a0
[4] StStairsSearchGuiMgr::search(0xed2a20, 0xeddcc8, 0xfffffff5, 0xffbeddfc, 0
xfed9a000, 0xeddcc8), at 0x3c5824
[5] UxCStairsSearch::activateCBsearchPB(0xed2ef8, 0xeddcc8, 0x0, 0xffbedf4c,
0xff08ec20, 0x2a5), at 0x25a36c
[6] UxCStairsSearch::WrapactivateCB_searchPB(0xeddcc8, 0x0, 0xffbedf4c, 0xfe
e72000, 0xdc5ab0, 0x0), at 0x25a5d4
[7] XtCallCallbackList(0xeddcc8, 0x0, 0xffbedf4c, 0xeddcc8, 0xe697d8, 0xeddcc8
), at 0xfee3c36c
[8] ActivateCommon(0x0, 0xffbee248, 0xff086000, 0xeddcc8, 0xfef83588, 0xfee3ef
84), at 0xfef83764
[9] HandleActions(0x0, 0xffbee248, 0xe00b88, 0xeddcc8, 0xede69c, 0xe04e80), at
0xfee3f324
[10] HandleComplexState(0xeddd00, 0xe04ee0, 0xe8bed0, 0xfee72000, 0xeddcf8, 0x
ffbee07c), at 0xfee45f94
[11] _XtTranslateEvent(0xfee78298, 0xeddcf8, 0xfee72000, 0xeddcc8, 0xedb358, 0
x8), at 0xfee3dd40
[12] XtDispatchEventToWidget(0x0, 0x1, 0x0, 0xffbee248, 0xeddcc8, 0x8), at 0xf
ee3dab0
[13] _XtDefaultDispatcher(0x8, 0xeddcc8, 0xdd0a54, 0xeddcc8, 0x0, 0x0), at 0xf
ee3d39c
[14] XtDispatchEvent(0x0, 0xfee3cff8, 0xdbb920, 0xfee72000, 0x0, 0x1), at 0xfe
e3ced0
[15] XtAppMainLoop(0xdbb920, 0xdbb920, 0x3e8, 0xde99b8, 0x36ee80, 0xfee72000),
at 0xfee3ab74
[16] main(0x1, 0xffbee724, 0xffbee72c, 0x9f0800, 0x0, 0x0), at 0x283bdc
Thanks
Mohan

I am compiling with V5.0 compiler on solaris 2.6
I am getting the following core dump. I am using RogueWave with -library=rwtools7,iostream
compiler option.
The traceback from the core file is:
signal SEGV (no mapping at the fault address) in RWReference::removeRe
ference at 0x77ba70
0x0077ba70: removeReference+0x0038: ld [%i0], %i0
(/opt/shared/sun/workshop/v5.0/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) where
current thread: t@1
=>[1] RWReference::removeReference(0x323030f4, 0x323030f4, 0xd2dc60, 0xfede36f8,
0x81010100, 0x0), at 0x77ba70
[2] RWCString::~RWCString(0x323030f4, 0x9aa2bc, 0xffbed85c, 0x638790, 0x16608,
0xd30c14), at 0x76e868
[3] StSearchEng::searchbydetail(0xffbedaf0, 0xed2b38, 0x0, 0xd30bcc, 0x986074,
0x0), at 0x6387a0
[4] StStairsSearchGuiMgr::search(0xed2a20, 0xeddcc8, 0xfffffff5, 0xffbeddfc, 0
xfed9a000, 0xeddcc8), at 0x3c5824
[5] UxCStairsSearch::activateCBsearchPB(0xed2ef8, 0xeddcc8, 0x0, 0xffbedf4c,
0xff08ec20, 0x2a5), at 0x25a36c
[6] UxCStairsSearch::WrapactivateCB_searchPB(0xeddcc8, 0x0, 0xffbedf4c, 0xfe
e72000, 0xdc5ab0, 0x0), at 0x25a5d4
[7] XtCallCallbackList(0xeddcc8, 0x0, 0xffbedf4c, 0xeddcc8, 0xe697d8, 0xeddcc8
), at 0xfee3c36c
[8] ActivateCommon(0x0, 0xffbee248, 0xff086000, 0xeddcc8, 0xfef83588, 0xfee3ef
84), at 0xfef83764
[9] HandleActions(0x0, 0xffbee248, 0xe00b88, 0xeddcc8, 0xede69c, 0xe04e80), at
0xfee3f324
[10] HandleComplexState(0xeddd00, 0xe04ee0, 0xe8bed0, 0xfee72000, 0xeddcf8, 0x
ffbee07c), at 0xfee45f94
[11] _XtTranslateEvent(0xfee78298, 0xeddcf8, 0xfee72000, 0xeddcc8, 0xedb358, 0
x8), at 0xfee3dd40
[12] XtDispatchEventToWidget(0x0, 0x1, 0x0, 0xffbee248, 0xeddcc8, 0x8), at 0xf
ee3dab0
[13] _XtDefaultDispatcher(0x8, 0xeddcc8, 0xdd0a54, 0xeddcc8, 0x0, 0x0), at 0xf
ee3d39c
[14] XtDispatchEvent(0x0, 0xfee3cff8, 0xdbb920, 0xfee72000, 0x0, 0x1), at 0xfe
e3ced0
[15] XtAppMainLoop(0xdbb920, 0xdbb920, 0x3e8, 0xde99b8, 0x36ee80, 0xfee72000),
at 0xfee3ab74
[16] main(0x1, 0xffbee724, 0xffbee72c, 0x9f0800, 0x0, 0x0), at 0x283bdc
Thanks
Mohan

Seeking runtime mutex analysis tool

I am using Sun C++ 5.5 on Solaris 8, on an Ultra 10.
Does there exist a "known reliable" tool for tracking (logging, analyzing, reporting) a Solaris application's RUN TIME operationis on Solaris mutexes?
I've written such a tool, myself, but if I am to believe its current reports there are serious flaws in the Solaris mutex mechanism on Solaris 8. I conclude, instead, that my tool is broken and that I should try to find an equivalent tool that actually WORKS.
So, I would appreciate either pointers to such (a) tool(s) -- OR confirmation that there are, indeed, serious flaws in the Solaris mutex mechanism on Solaris 8 and that my homebrewed tool is truthful... ;-)
Thanks in advance,
Chris

Yes, I use the -mt option on all builds -- actually I use an "in-house standard" Makefile that sets this for me, every time.
It is not clear what luck I will have with the thread-library patches -- I am not in a position to use them myself, but must talk a separate sysadmin department into handling it for me -- but thank you, nonetheless, for the suggestion. It's also possible that the patches in question are already installed; only "they" will know.
I will also definitely try the "optional new thread library." Had not heard about that one. Is there something, somewhere, that I can read that will tell me what differences in behavior I might expect to see?
Details of my observations are ... difficult... to convey, due to sheer volume; I'll do my best to summarize here, but I apologize for the length of what follows.
First, truss of a small "test app," running for about 20 minutes (super-slow due to truss itself; equivalent to about two minutes at "normal" speed) produces over 1.5 million lines (62 Mbytes) of output. Heavy postprocessing to select just the operations associated with a single mutex produces a 47Kb file, most of which is inoccuous (sp?). Here and there, however, I observe sequences along the lines of the following (the parenthesized numbers are mine, for the sake of reference; the rest is pretty much exactly what truss puts out):
(1)   /4 -> mutex_lock(0xc68cb, ... (other args here)...)
(2)   /4 <- mutex_lock(0xc68cb, ... (other args here)...) = 0
(3)   /5 -> mutex_lock(0xc68cb, ... (other args here)...)
(4)   /5 <- mutex_lock(0xc68cb, ... (other args here)...) = 0
(5)   /5 -> mutex_unlock(0xc68cb, ... (other args here)...)
(6)   /5 <- mutex_unlock(0xc68cb, ... (other args here)...) = 0
      . (repeat thread-5 lock-unlock pairs, numerous times, here)
(7)   /4 -> mutex_unlock(0xc68cb, ... (other args here)...)
(8)   /4 <- mutex_unlock(0xc68cb, ... (other args here)...) = 0Taking this at face value, my interpretation is as follows:
- at line 1, thread 4 requests a lock on the mutex.
- at line 2, thread 4 is granted the requested lock on the mutex
- at line 3, thread 5 requests a lock on the mutex. I would expect this request to block, due to thread 4's existing lock, such that we would not see the completion of this request until after an unlock performed by thread 4. However...
- at line 4, thread 5 is granted a lock on the mutex! If truss is telling us the bald-faced truth about the sequence of operations here, this lock should not have been granted, because thread 4 already held a lock on this mutex!
- in lines 5 and 6, we see thread 5 unlocking the mutex (which it "should never have been able to lock in the first place");
- between lines 6 and 7, but omitted here for the sake of brevity, I see ten or twenty duplicates of the sequence of operations in lines 3 through 6, namely, thread 5 locking-and-unlocking the mutex, entirely successfully (return value of 0) and without blocking (no other threads doing anything in between thread 5's activities)
- finally, in lines 7 and 8,, we see thread 4 unlocking the mutex that it locked at line(s) 1 (and 2).
The only explanations I can come up with, for the observed sequence -- which is seen in several other places in the log file, for this and several other mutexes, and on every run of the test program -- are these:
1) truss is 100% truthful and accurate in its reporting of mutex operations, in particular with regard to their exact sequencing, and the mutex facility does, in fact, occasionally allow thread 5 to lock a mutex already locked by thread 4. (I know for a fact that the facility allows e.g. thread 5 to unlock a mutex held by thread 4; there's another post somewhere in this forum about this being done deliberately in a piece of questionable code. I consider it somewhat of a flaw that the mutex facility allows this at all, but other people here argue that there "may be compelling reasons" (i.e. deep in the theoretical department at Sun) for "things being the way they are" in this respect. Anybody know for sure?)
2) Multi-threading being what it is -- a complex, subtle, and oft-unwieldy beast -- truss "gets confused" in some subtle way, and ends up reporting events in a slightly different sequence than they actually occurred. In the particular case outlined here, for example, perhaps thread 4 did unlock the mutex "right after it locked it," but truss, for whatever reasons, didn't report it right away -- namely, not until after thread 5 had perfectly "legally" locked-and-unlocked the mutex a few times. (Alas, it's not clear why truss would get around to reporting thread 5's activities, before getting around to reporting thread 4's activities previously completed. It almost seems to require large amounts of latency on all threads, interacting in a complex manner. I can just manage to leave mental "elbow room" for this, because I don't know exactly how truss works.. It's harder, though, to shrug off the essentially-identical results produced by code of my own, whose inner workings I do know, and which I would have trusted implicitly if it hadn't started delivering reports like these in the first place.
So, folks, the burning question is, which, if either, of these two conclusions can we confirm? If it's the former, we have serious problems, but should face them squarely and fix them. If it's the latter, I would desperately love to hear it -- with believable supporting details -- from Someone Who Really Knows, so that I can simply shrug off the disturbing "evidence" and write off the whole issue of realtime mutex-tracing as "one of those things that can never quite be nailed down."
Thanks for listening.

Is there any known issue about mutex lock used in JNI on Solaris 10?

Dear Oracle,
I'm facing a strange behavior when running a JNI application that use the mutex lock. The application hanged after running for a while on one of our Solaris 10 machines. After investigating the stack trace of the application, it shows that one of all the application's threads that access the JNI hold the mutex lock forever, and that cause the other threads cannot access the JNI. The same application works fine on other Solaris 10 machines.
The mutex function I used as show below:
mutex_lock(&mutex)
The application hanged at this line:
0xff2cc940 ___lwp_mutex_timedlock + 0x8
The Kernel version is SunOS 5.10 Generic_142900-14
Since this issue occurrs on only one Solaris 10 machine in our environment, we are wondering if there is any known issue regarding the mutex lock used in JNI on Solaris 10. We tried to search the Internet and the Java Bug database but found nothing related to this issue.
Best regards,
Krit K.

876587 wrote:
... and that cause the other threads cannot access the JNI. The same application works fine on other Solaris 10 machines.
Different environments mean just that. So something could be causing it outside java.
Additionally if anything at all is different in the execution data, such as even a name having a different size, then it would change the execution path.
Which would cause a problem in the JNI code to manifest itself on only one box. Probably isn't a pointer bug but all sorts of odd behavior can result from that.

Mutex/Spinlock Panic Report, System Crash

Please help. Sometimes I can go on for days without this happen, other times i crash multiple times within a period of few hours.
Interval Since Last Panic Report: 310933 sec
Panics Since Last Report: 2
Anonymous UUID: 720BBC73-EC12-4624-B548-B9581501A974
Wed Jan 5 03:34:19 2011
panic(cpu 5 caller 0x2269f0): "thread_invoke: preemption_level -1, possible cause: unlocking an unlocked mutex or spinlock"@/SourceCache/xnu/xnu-1504.7.4/osfmk/kern/sched_prim.c:1476
Backtrace (CPU 5), Frame : Return Address (4 potential args on stack)
0x84c2be18 : 0x21b455 (0x5cf328 0x84c2be4c 0x2238b1 0x0)
0x84c2be68 : 0x2269f0 (0x58712c 0xffffffff 0x5870c4 0x2263b2)
0x84c2bee8 : 0x2270f6 (0xef043f0 0x0 0x6cbc4000 0x1)
0x84c2bf58 : 0x227161 (0x22fa9b 0x863ea0 0x0 0x2a1591)
0x84c2bf78 : 0x22fc35 (0x22fa9b 0x863ea0 0x0 0x0)
0x84c2bfc8 : 0x29e6cc (0x863ea0 0x0 0x10 0xd66d480)
BSD process name corresponding to current thread: kernel_task
Mac OS version:
10F569
Kernel version:
Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386
System model name: iMac11,1 (Mac-F2268DAE)
System uptime in nanoseconds: 6029447861053
unloaded kexts:
com.apple.driver.AppleFileSystemDriver 2.0 (addr 0xe18000, size 0x12288) - last unloaded 190863574351
loaded kexts:
com.vmware.kext.vmnet 3.0.0
com.vmware.kext.vmioplug 3.0.0
com.vmware.kext.vmci 3.0.0
com.vmware.kext.vmx86 3.0.0
com.belkin.driver.n52te 1.0.2
com.Logitech.Control Center.HID Driver 3.2.0
com.apple.filesystems.udf 2.1 - last loaded 28445044689
com.apple.filesystems.autofs 2.1.0
com.apple.driver.AGPM 100.12.12
com.apple.driver.AppleHWSensor 1.9.3d0
com.apple.driver.AppleMikeyHIDDriver 1.2.0
com.apple.driver.AppleUpstreamUserClient 3.3.2
com.apple.driver.AppleHDA 1.8.7f1
com.apple.kext.ATIFramebuffer 6.1.8
com.apple.driver.AppleMikeyDriver 1.8.7f1
com.apple.driver.AudioAUUC 1.4
com.apple.ATIRadeonX2000 6.1.8
com.apple.DontSteal_Mac_OSX 7.0.0
com.apple.driver.AudioIPCDriver 1.1.2
com.apple.driver.AirPort.Atheros21 423.9.9
com.apple.driver.ACPISMCPlatformPlugin 4.1.2b1
com.apple.driver.AppleLPC 1.4.12
com.apple.driver.AppleBacklight 170.0.24
com.apple.driver.AppleUSBCardReader 2.5.4
com.apple.driver.AppleIRController 303.8
com.apple.iokit.SCSITaskUserClient 2.6.5
com.apple.BootCache 31
com.apple.AppleFSCompression.AppleFSCompressionTypeZlib 1.0.0d1
com.apple.iokit.IOAHCIBlockStorage 1.6.2
com.apple.driver.AppleFWOHCI 4.7.1
com.apple.driver.AppleUSBHub 4.0.0
com.apple.iokit.AppleBCM5701Ethernet 2.3.8b2
com.apple.driver.AppleEFINVRAM 1.3.0
com.apple.driver.AppleUSBEHCI 4.0.2
com.apple.driver.AppleUSBUHCI 4.0.2
com.apple.driver.AppleAHCIPort 2.1.2
com.apple.driver.AppleACPIButtons 1.3.2
com.apple.driver.AppleRTC 1.3.1
com.apple.driver.AppleHPET 1.5
com.apple.driver.AppleSMBIOS 1.6
com.apple.driver.AppleACPIEC 1.3.2
com.apple.driver.AppleAPIC 1.4
com.apple.driver.AppleIntelCPUPowerManagementClient 105.10.0
com.apple.security.sandbox 0
com.apple.security.quarantine 0
com.apple.nke.applicationfirewall 2.1.11
com.apple.driver.AppleIntelCPUPowerManagement 105.10.0
com.apple.driver.AppleProfileReadCounterAction 17
com.apple.driver.DspFuncLib 1.8.7f1
com.apple.driver.AppleProfileTimestampAction 10
com.apple.driver.AppleProfileThreadInfoAction 14
com.apple.driver.AppleProfileRegisterStateAction 10
com.apple.driver.AppleProfileKEventAction 10
com.apple.driver.AppleProfileCallstackAction 20
com.apple.driver.AppleSMBusController 1.0.8d0
com.apple.kext.ATI4800Controller 6.1.8
com.apple.kext.ATISupport 6.1.8
com.apple.iokit.IOFireWireIP 2.0.3
com.apple.driver.AppleUSBAudio 2.7.3f1
com.apple.iokit.IOSurface 74.0
com.apple.iokit.IOBluetoothSerialManager 2.3.3f8
com.apple.iokit.IOSerialFamily 10.0.3
com.apple.iokit.IOAudioFamily 1.7.6fc2
com.apple.kext.OSvKernDSPLib 1.3
com.apple.driver.AppleHDAController 1.8.7f1
com.apple.iokit.IOHDAFamily 1.8.7f1
com.apple.iokit.IO80211Family 311.1
com.apple.iokit.AppleProfileFamily 41
com.apple.driver.AppleSMC 3.0.1d2
com.apple.driver.IOPlatformPluginFamily 4.1.2b1
com.apple.driver.AppleSMBusPCI 1.0.8d0
com.apple.iokit.IONDRVSupport 2.1
com.apple.iokit.IOGraphicsFamily 2.1
com.apple.driver.AppleUSBHIDKeyboard 1.2.0a3
com.apple.driver.AppleHIDKeyboard 1.2.0a3
com.apple.driver.BroadcomUSBBluetoothHCIController 2.3.3f8
com.apple.driver.AppleUSBBluetoothHCIController 2.3.3f8
com.apple.iokit.IOBluetoothFamily 2.3.3f8
com.apple.iokit.IOSCSIBlockCommandsDevice 2.6.5
com.apple.iokit.IOUSBMassStorageClass 2.6.1
com.apple.iokit.IOUSBHIDDriver 4.0.2
com.apple.driver.AppleUSBMergeNub 4.0.0
com.apple.driver.AppleUSBComposite 3.9.0
com.apple.iokit.IOSCSIMultimediaCommandsDevice 2.6.5
com.apple.iokit.IOBDStorageFamily 1.6
com.apple.iokit.IODVDStorageFamily 1.6
com.apple.iokit.IOCDStorageFamily 1.6
com.apple.driver.XsanFilter 402.1
com.apple.iokit.IOAHCISerialATAPI 1.2.4
com.apple.iokit.IOSCSIArchitectureModelFamily 2.6.5
com.apple.iokit.IOFireWireFamily 4.2.6
com.apple.iokit.IOUSBUserClient 4.0.0
com.apple.iokit.IONetworkingFamily 1.9
com.apple.iokit.IOUSBFamily 4.0.2
com.apple.iokit.IOAHCIFamily 2.0.4
com.apple.driver.AppleEFIRuntime 1.3.0
com.apple.iokit.IOHIDFamily 1.6.4
com.apple.iokit.IOSMBusFamily 1.1
com.apple.kext.AppleMatch 1.0.0d1
com.apple.security.TMSafetyNet 6
com.apple.driver.DiskImages 283
com.apple.iokit.IOStorageFamily 1.6.1
com.apple.driver.AppleACPIPlatform 1.3.2
com.apple.iokit.IOPCIFamily 2.6
com.apple.iokit.IOACPIFamily 1.3.0
Model: iMac11,1, BootROM IM111.0034.B02, 4 processors, Intel Core i7, 2.8 GHz, 8 GB, SMC 1.54f36
Graphics: ATI Radeon HD 4850, ATI Radeon HD 4850, PCIe, 512 MB
Memory Module: global_name
AirPort: spairportwireless_card_type_airportextreme (0x168C, 0x8F), Atheros 9280: 2.1.9.8.1
Bluetooth: Version 2.3.3f8, 2 service, 19 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Serial ATA Device: ST31000528ASQ, 931.51 GB
Serial ATA Device: OPTIARC DVD RW AD-5680H, 7.82 GB
USB Device: Hub, 0x0424 (SMSC), 0x2514, 0xfd100000
USB Device: Turtle Beach USB Audio, 0x10f5, 0x0211, 0xfd140000
USB Device: Belkin n52te, 0x050d (Belkin Corporation), 0x0200, 0xfd130000
USB Device: Built-in iSight, 0x05ac (Apple Inc.), 0x8502, 0xfd110000
USB Device: IR Receiver, 0x05ac (Apple Inc.), 0x8242, 0xfd120000
USB Device: Hub, 0x0424 (SMSC), 0x2514, 0xfa100000
USB Device: USB Receiver, 0x046d (Logitech Inc.), 0xc525, 0xfa130000
USB Device: Keyboard Hub, 0x05ac (Apple Inc.), 0x1006, 0xfa140000
USB Device: Apple Keyboard, 0x05ac (Apple Inc.), 0x0220, 0xfa142000
USB Device: Internal Memory Card Reader, 0x05ac (Apple Inc.), 0x8403, 0xfa120000
USB Device: BRCM2046 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0xfa110000
USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0x8215, 0xfa111000

Hi
I have the same kernel panics with the possible cause being reported as "unlocking an unlocked mutex or spinlock". I reported this here:
http://discussions.apple.com/thread.jspa?messageID=13204058#13204058

Run time error about RWCString

Dear all:
I meet a problem when I use RWCString
I write an function as follow:
int process_priority(const RWCString & priorityline)
     RWCString priority(priorityline[15]);
     int i=atoi(priority);
     return i;
}I call this function in a loop, when calling it the first time,it;s ok. but the second time calling it, it cores dump. I use dbx to trace it, the error messages are as follow:
t@1 (l@1) signal BUS (invalid address alignment) in t_splay at 0xfd8c79c0
0xfd8c79c0: t_splay+0x0014: ld [%o2 + 16], %o4
Current function is RWCString::RWCString
233 RWCString(char c) {initChar(c);}
I'm not sure why the constructor of RWCString failed. who know it? and how to solve this problem?Thank you very much!!

dear clamage45:
you are always of great help!!
I trace the code here, dbx shows that when calling RWCString(char c) {initChar(c) , it cores dump. I print the variable "c", it shows "1", this is the character that I want to change to an int.
Also, I print the parameter priorityline and it has exactly 16character :
Priority      :1
the last one is "1".
I'm so confused now.

Multi processor Solaris 2.6 and mutex locks

hi,
is anyone aware of any documented issues with Solaris 2.6 running
on dual-SPARC processors (multi-processor environment) where the
programs using "mutex locks" (multi-threaded applications), require
some special handling, in terms of compiling and linking, to some
special libraries.
as far as i remember, in some OS book, maybe Peterson's, it was said
that the mechanism for implementing mutex-locks on multi-processor
systems is to use low-level spin-locks. this brings down performance
on a single-processor system, making the processor doing busy-wait,
but this happens to be the only way of mutex-locking in a multi-processor
system. if this is so, then where is such behaviour documented in case
of Solaris 2.6.
i have had problems with my applications crashing (rathing hanging up)
in a vfork() on such a system, but same application works fine, with
100% reproducability, on a single-processor system.
thanks for any inputs or suggestions and/or information.
regards,
banibrata dutta

I am also facing similar problem. Application which written using Mulit-Threaded using Posix Mutexes. When i run on SINGLE processor manchine, i.e.
SunOS sund4 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-5_10
It works perfectly.
But when try to run on dual processor machine, i.e.
SunOS sund2 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-250
It is blocking in the one of mutexes.
Please inform us what is problem. Mr. B. Datta, you comes to know
any channel, please inform me also at [email protected]
Thanx & regards,
-venkat

Max mutexes problem where it shouldn't happen

Hi -
I am getting this error:
java.lang.OutOfMemoryError: Cannot allocate memory: unable to allocate memory for mutex; resize mutex region
at com.sleepycat.db.internal.db_javaJNI.DbEnv_open(Native Method)
bdb java 5.1.19 using DPL on Ubuntu. Here is the code for setting up the environment:
env.setAllowCreate(true);
env.setInitializeCache(true);
env.setInitializeLocking(true);
env.setInitializeLogging(true);
env.setTransactional(true);
env.setMaxMutexes(10000);
I have one object in the database. If it is really the case that this is a problem with not enough mutexes, how many should I set?
Garey Mills

I just wanted to say that I wouldn't have posted this if I thought that increasing the number of mutexes would help. I have read the other posts on the matter and I don't think that this is the same problem. Because:
- bdb in this case is part of a web app running in Jetty. This error happens on startup.
- I only have three entity types, none is larger than a kilobyte, if that, and there is only one entity in the database at the moment
I will gladly supply more details if that helps anyone to diagnose what's going on.
Garey Mills

Failed to create Process mutex

When trying to start the FMS services using FMSMaster.exe -console using the command promt I am repeatedly getting the "Failed to create process mutex"
Please help.

Hi Asa
Thanks for your answer.
Bad news are good news - at least I know what is going on.
But I am pretty sure it is a bug. Probably, in the passing parameters into the CreateMutex function.
The funny thing, FMSHttpd works under DOMAIN account, but FMS does not.
I hope you can raise an issue for the next version of FMS.
The problem is that in the Enterprise network we have to store data files on the Network Access Storage. In this case we will be able not worry where to install FMS.
For now, we have to put all files onto the server, where FMS is installed. Not good....
Anyway, Thanks for you answer. And hope your team will fix this issue.

Unable to allocate memory for mutex; resize mutex region

I have BDB on linux. I am trying to run my app, but I am getting this when it tries to set up the environment. Do I need to set any environment variable or something?
Here is my setting.
<property name="allowCreate" value="true"/>
<property name="cacheSize" value="65535000"/>
<property name="cacheCount" value="30"/>
<property name="initializeCache" value="true"/>
<property name="initializeLocking" value="true"/>
<property name="transactional" value="true"/>
Thanks.
------------- Standard Error -----------------
unable to allocate memory for mutex; resize mutex region
Testcase: testRunService took 1.842 sec
Caused an ERROR
Cannot allocate memory
java.lang.OutOfMemoryError: Cannot allocate memory
at com.sleepycat.db.internal.db_javaJNI.DbEnv_open(Native Method)
at com.sleepycat.db.internal.DbEnv.open(DbEnv.java:262)
at com.sleepycat.db.EnvironmentConfig.openEnvironment(EnvironmentConfig.java:908)
at com.sleepycat.db.Environment.<init>(Environment.java:30)
Edited by: user635741 on Oct 23, 2008 9:19 AM

Hello,
Based on the error, unable to allocate memory for mutex; resize mutex region,
have you tried increasing the mutex region?
The documentation on the setMaxMutexes method is at:
http://www.oracle.com/technology/documentation/berkeley-db/db/java/com/sleepycat/db/EnvironmentConfig.html#setMaxMutexes(int)
You can run db_stat -x
to display the mutex subsystem statistics.
You'll see the information for statistics like:
Mutex region size
The number of region locks that required waiting (0%)
Mutex alignment
Mutex test-and-set spins
If that does not look to be the problem, just let me know.
Thanks,
Sandra

RWCString mutexes

Similar Messages

Maybe you are looking for