May 2008 - Darwin-dev - lists.apple.com

Details on: "malloc: *** mmap(size=16883712) failed (error code=12)"
by Sean McBride 09 May '08

09 May '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: Rogue Research Hi all, Sometimes I see messages like: malloc: *** mmap(size=16883712) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug I'm trying to find more details about this message. Specifically, what is error code 12? In my case, it is a 32 bit process using 60 MB of 'real memory' and 1.2 GB of 'virtual memory' (says Activity Monitor). I'm trying to determine if 1) the process' virtual memory is just really fragmented and it really can't allocate 16.8 MB, or 2) I have some kind of memory smasher or other bug. Thanks, -- ____________________________________________________________ Sean McBride, B. Eng sean(a)rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Diskarbitration callback
by Kevin Elliott 09 May '08

09 May '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com However all my 'real' work in the cocoa app, including the call in question, is already done in a background thread, so I get the impression I'm safe to use the same runloop construct within the library. I'm about to try it anyway... On May 9, 2008, at 3:42 AM, Andy Green wrote: That was exactly my concern: I don't mind pauses in a console app, but I didn't want to tie up the gui. My library does 'things' with disks, I need to perform the DAUnmount/eject right in the middle, and I just wanted the same library call to work whether called from console or GUI. Is your background thread already calling CFRunLoopRun or is just running to completion? My personal preference is to have all the DA callbacks on an thread that's handling it's own events- either in their own thread, or attached to the main thread (in a GUI App). If your having to structure your code to call RunLoopRun just so you can let your callbacks fire it's been my experience that I'm working to hard and need to rethink what I'm doing. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Diskarbitration callback
by Kevin Elliott 09 May '08

09 May '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 9, 2008, at 5:44 AM, Axel Luttgens wrote: Le 9 mai 08 à 12:42, Andy Green a écrit : Hi Kevin, Thanks for your comments; a couple of responses inline below [...] That was exactly my concern: I don't mind pauses in a console app, but I didn't want to tie up the gui. That's one of the reasons that led me to suggest CFRunLoopRunInMode(); in fact, as it has been used, the call to CFRunLoopStop() could even be removed from AndygDiskArbCallback(). (unless, of course, I'm terribly wrong; as I already noticed, I'm not a guru...) Ahh... Not sure what your goal was, but CFRunLoopRunInMode basically means "Only process events that are in the following set (mode)". Everything else will be queued, which could obviously cause hickups, etc. Now, of course, if your already in your own thread it's a non- issue. The main thread has it's own runloop which will happily continue on it's own. Generally speaking, I don't think CFRunLoopRunInMode is something for "normal" use. It's primary purpose is for things like creating old fashioned modal dialogs and the like. If your calling it directly you are either doing something sneaky and clever, or your using it wrong. One of those is a lot more common than the other ;-) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Diskarbitration callback
by Axel Luttgens 09 May '08

09 May '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Le 9 mai 08 à 12:42, Andy Green a écrit : Axel _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Hi Kevin, Thanks for your comments; a couple of responses inline below [...] That was exactly my concern: I don't mind pauses in a console app, but I didn't want to tie up the gui. That's one of the reasons that led me to suggest CFRunLoopRunInMode(); in fact, as it has been used, the call to CFRunLoopStop() could even be removed from AndygDiskArbCallback(). (unless, of course, I'm terribly wrong; as I already noticed, I'm not a guru...) This email sent to site_archiver(a)lists.apple.com

1 0

RE: Diskarbitration callback
by Andy Green 09 May '08

09 May '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcixMydKzhdkPHeFTb6rJM4fC5RnfgAjVhkg Thread-topic: Diskarbitration callback Hi Kevin, Thanks for your comments; a couple of responses inline below > > > > And an awkward question: my 'real' code will be in a library, called > > from both command line tools, and from a cocoa app. Is this run-loop > > hocus pocus safe in both environments? > > Basically it depends on how you expect your code to be used. > > A RunLoop is basically a generic construct for waiting on > callbacks. > They're created on demand (whenever you call and RunLoop function), > and map to threads so each thread has one runloop, unless the thread > doesn't make any runloop related calls. > [...] > > Now, to using it in a library, it depends on what your trying > to to. > If your trying to create a disk arb wrapper, my suggestion > would be to > create your own thread, file your callbacks against that threads > runloop, and then have your API provide hooks to modify what ever > behavior you need to modify (with appropriate locks, etc.). If your > trying to do something else, well, I'd need to know more about what > your trying to do. > > I will say that calling CFRunLoopRun or any of it's similar ilk is > almost certainly a bad idea unless your in your own thread. > Certainly > for GUI apps it's VERY unusual for a run loop to be run directly and > will probably result in all sorts of oddities. It's not against the > "rules", but it's something you'd need to be very careful > about doing- > GUI apps generally have lots of things hooked up to the run loop and > your running it directly is either going to cause unexpected > pauses as > other events are delayed, or possibly reentry problems depending on > what exactly you do. > That was exactly my concern: I don't mind pauses in a console app, but I didn't want to tie up the gui. My library does 'things' with disks, I need to perform the DAUnmount/eject right in the middle, and I just wanted the same library call to work whether called from console or GUI. However all my 'real' work in the cocoa app, including the call in question, is already done in a background thread, so I get the impression I'm safe to use the same runloop construct within the library. I'm about to try it anyway... Cheers, Andy _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Diagnosing a sporadically non-responsive Mac?
by Jack Repenning 08 May '08

08 May '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 7, 2008, at 5:21 PM, Andre-John Mas wrote: Hi, -==- Jack Repenning jackrepenning(a)tigris.org Project Owner SCPlugin http://scplugin.tigris.org "Subversion for the rest of OS X" _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I have a Mac that I use that has started to sporadically not respond. What I mean by that is that it can be running for a day or so and then quit accepting network requests or will accept a mouse click to launch an application on the dock, but the application will bounce for ever. Is there anything I could install that could help me diagnose the issue? Maybe something that will get triggered on a CPU spike or something of the sort. Your Mac already comes with quite a good collection of tools that might be useful here. One trick to try: add "Activity Monitor" to your log in items (hidden). When things to sour, maybe you'll be able to cmd-tab it to the front and learn something useful. For example, if some application is consuming all the CPU, you can see who it is -- and also, you can "sample" it, which may help the program's author find and fix the problem. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Trying again: Question concerning Tiger->Leopard changes for unformatted BSD disk device.
by Chris Sarcone 08 May '08

08 May '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

RE: Trying again: Question concerning Tiger->Leopard changes for unformatted BSD disk device.
by kkikuchi＠rite-solutions.com 08 May '08

08 May '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Importance: Normal _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Diskarbitration callback
by Kevin Elliott 08 May '08

08 May '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Wow - works like a charm! When I say that, I mean it works, but I have no idea how! I'll have to go read up on run loops: in the meantime here's the working code for posterity - is this what you meant? And an awkward question: my 'real' code will be in a library, called from both command line tools, and from a cocoa app. Is this run-loop hocus pocus safe in both environments? Basically it depends on how you expect your code to be used. On May 8, 2008, at 9:58 AM, Andy Green wrote: A RunLoop is basically a generic construct for waiting on callbacks. They're created on demand (whenever you call and RunLoop function), and map to threads so each thread has one runloop, unless the thread doesn't make any runloop related calls. I don't have your code in front of me, but I've I'm understanding the flow of emails, I can make a few comments. The core problem with your original code was that you were firing off a number of events (DADiskUnmount, DADiskEject), then calling CFRunLoopRun, then wondering why your callback never fired. Your call back never fired because nothing happened- the unmount/eject completed before you were waiting in your runloop. The code Axel sents works because he's looping against the runloop which means he's back waiting in it before the eject call get to diskarbitrationd starts processing your event. As a mental "image" it's worth thinking of the "DADiskEject/DADiskUnmount" as basically sending a message to diskarbitrationd which will respond to that message in the future. I believe the custom run mode that Axel is using- CFSTR("drvHostBaseDA") is unnecessary. His code should work just as well with kCFRunLoopDefaultMode. Now, to using it in a library, it depends on what your trying to to. If your trying to create a disk arb wrapper, my suggestion would be to create your own thread, file your callbacks against that threads runloop, and then have your API provide hooks to modify what ever behavior you need to modify (with appropriate locks, etc.). If your trying to do something else, well, I'd need to know more about what your trying to do. I will say that calling CFRunLoopRun or any of it's similar ilk is almost certainly a bad idea unless your in your own thread. Certainly for GUI apps it's VERY unusual for a run loop to be run directly and will probably result in all sorts of oddities. It's not against the "rules", but it's something you'd need to be very careful about doing- GUI apps generally have lots of things hooked up to the run loop and your running it directly is either going to cause unexpected pauses as other events are delayed, or possibly reentry problems depending on what exactly you do. I'd encourage you to explain more about what exactly your trying to do before you continue... _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

RE: Diskarbitration callback
by Andy Green 08 May '08

08 May '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcixDK5OFD303bvnSfWpoo07qb/QWQAH4G6Q Thread-topic: Diskarbitration callback > > > I've written some code which uses the diskArbitration framework to > > unmount (and eject) a disk. > > It works, in that the disk gets unmounted, but my callback isn't > > being called, even though the operation is successful. Any > chance of > > spotting the mistake in this code fragment? :- > > I think you'll have to schedule the session with a run loop > to get any > callback actions. > > Wow - works like a charm! When I say that, I mean it works, but I have no idea how! I'll have to go read up on run loops: in the meantime here's the working code for posterity - is this what you meant? And an awkward question: my 'real' code will be in a library, called from both command line tools, and from a cocoa app. Is this run-loop hocus pocus safe in both environments? struct Nothing { bool dummy; }; static void AndygDiskArbCallback( DADiskRef disk, DADissenterRef dissenter, void * context) { TRACE("callback..."); if (dissenter) { DAReturn status = DADissenterGetStatus( dissenter ); TRACE("DENIED (0x%x)!...", status); } else { TRACE("granted..."); Nothing * n = (Nothing *)context; assert(n); n->dummy = true; } // unlock the main thread CFRunLoopStop(CFRunLoopGetCurrent()); } int main(int argc, const char *argv[]) { const char * cStr = "disk3s10"; Nothing * n = new Nothing; n->dummy = false; DASessionRef diskArbSession = DASessionCreate(kCFAllocatorDefault); assert(diskArbSession); DASessionScheduleWithRunLoop(diskArbSession, CFRunLoopGetCurrent(), kCFRunLoopDefaultMode); DADiskRef disk = DADiskCreateFromBSDName( kCFAllocatorDefault, diskArbSession, cStr ); assert(disk); TRACE("confirming %s == %s??\n", DADiskGetBSDName(disk), cStr); DADiskRef whole = DADiskCopyWholeDisk( disk ); if ( whole ) { TRACE("wholedisk == %s\n", DADiskGetBSDName(whole)); DADiskUnmount(whole, kDADiskUnmountOptionWhole | kDADiskUnmountOptionForce, AndygDiskArbCallback, n); TRACE("------Wait1..."); CFRunLoopRun(); TRACE("Ping!\n"); if (n->dummy) { TRACE("UNMOUNT successful\n"); n->dummy = false; DADiskEject( whole, kDADiskEjectOptionDefault, AndygDiskArbCallback, n ); TRACE("------Wait2..."); CFRunLoopRun(); TRACE("Ping!\n"); if (n->dummy) { TRACE("EJECT SUCCESSFUL\n"); } } CFRelease(whole); } CFRelease(disk); DASessionUnscheduleFromRunLoop(diskArbSession, CFRunLoopGetCurrent(), kCFRunLoopDefaultMode); CFRelease(diskArbSession); TRACE("AT THE END OF IT ALL, n=%d\n", n->dummy); delete(n); } _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0