December 2007 - Darwin-dev - lists.apple.com

Re: Closing an IOUserClient
by Shaun Wexler 20 Dec '07

20 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Dec 19, 2007, at 11:22 AM, Duane Murphy wrote: SimpleUserClient works just fine when the user side closes the connection. I want to close the connect _from_ the provider. That is, the provider is tracking user clients and has determined that the user client needs to be closed, what do I do? I am having some luck with terminate() but some things still seem like they are not working correctly. In the provider, if (userClient->terminate(this, options)) ... ~HTH -- Shaun Wexler MacFOH http://www.macfoh.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 Your userclient must maintain its own state and + retain count while it's being torn down in phases. This means the user-space clients watch for their service being terminated, and close their connections immediately. The userclient should delay its teardown during didTerminate(), and call that function itself once all clients have been closed, which will then cause the stop thread to be scheduled. smime.p7s

1 0

Re: HowTo: catch a signal and get a CrashLog too (Leopard)
by Steve Checkoway 20 Dec '07

20 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Dec 19, 2007, at 3:02 PM, Andre-John Mas wrote: -- Steve Checkoway "Anyone who says that the solution is to educate the users hasn't ever met an actual user." -- Bruce Schneier _______________________________________________ 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 Is there any way for a developer to find out crashes related to their software via Apple? It would be ideal if there was service that I could sign up to as a developer or if MacOS X could send the log to the the application developer, though I realise the latter might be considered a 'security risk'. I sort of doubt it. It's probably easiest to write your own crash handler (or modify a free one, such as the one I helped write) and handle user crashes with backtracing yourself. That way you can also include other information that is useful for tracking down bugs. Easiest way we found was to catch the signal, open a pipe, fork a new process, reexec with a special argument so it knows to run the crash handler code, and write(2) the data to the child process. Then the child process can do things like look up symbols, make up a nice crash report and then inform the user who then has the choice to send it to you or not. smime.p7s

1 0

Re: HowTo: catch a signal and get a CrashLog too (Leopard)
by Andre-John Mas 19 Dec '07

19 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 19-Dec-07, at 00:30 , James Peach wrote: This works, but re-raising a signal does run the risk of producing a stack trace that CrashReporter can't walk correctly. I've seen cases where my own stack logging code and CrashReporter disagree wildly on what the real stack trace is. IMHO it's better to just let the fatal signals go straight through to CrashReporter unless you have a really food reason. Is there any way for a developer to find out crashes related to their software via Apple? It would be ideal if there was service that I could sign up to as a developer or if MacOS X could send the log to the the application developer, though I realise the latter might be considered a 'security risk'. Andre _______________________________________________ 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: Closing an IOUserClient
by Duane Murphy 19 Dec '07

19 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com --- At Wed, 19 Dec 2007 11:09:06 -0800, Garth Cummings wrote: >Hi Duane, > >On Dec 18, 2007, at 10:09 PM, Duane Murphy wrote: > >> What is the correct way to remove an IOUserClient instance from a >> provider? > >Last I tested this SimpleUserClient did the right thing: > ><http://developer.apple.com/samplecode/SimpleUserClient>. > >If the sample no longer works, please file a bug on it and I'll get it >fixed. Sorry Garth, SimpleUserClient doesn't apply here. SimpleUserClient works just fine when the user side closes the connection. I want to close the connect _from_ the provider. That is, the provider is tracking user clients and has determined that the user client needs to be closed, what do I do? I am having some luck with terminate() but some things still seem like they are not working correctly. ...Duane _______________________________________________ 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: Closing an IOUserClient
by Garth Cummings 19 Dec '07

19 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Duane, On Dec 18, 2007, at 10:09 PM, Duane Murphy wrote: Last I tested this SimpleUserClient did the right thing: <http://developer.apple.com/samplecode/SimpleUserClient>. --gc ____________________________________________________________________ Garth Cummings gcummings(a)apple.com Sr. Software Engineer Apple Developer Technical Support <http://developer.apple.com/technicalsupport> _______________________________________________ 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… What is the correct way to remove an IOUserClient instance from a provider? If the sample no longer works, please file a bug on it and I'll get it fixed. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Closing an IOUserClient
by Duane Murphy 19 Dec '07

19 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I've been experimenting with tracking when to close the IOUserClient. The problem is now that I don't know the proper way to close the IOUserClient from it's provider. I'm calling client->terminate( kIOServiceTerminate | kIOServiceSynchronous ). The connection to the provider is being closed, but the IOUserClient instance is not being removed. That is I cannot unload the kext because there are still instances of the IOUserClient class. What is the correct way to remove an IOUserClient instance from a provider? --- At Tue, 18 Dec 2007 18:29:26 -0800, Duane Murphy wrote: >I have an IOUserClient subclass whose provider is a file system filter. >When the file system is unloaded/unmounted the user client remains >connected. This causes Disk Utility and friends to be unhappy operating >on the disk (ie partitioning). > >I would have expected the terminate() set of calls to cause the user >client to unload. The UserClient is not being called at all during unmounting. > >Further testing shows that unmounting a file system doesn't actually >remove the kext (it's above the partition layer). My suspicion is that >unmounting a file system is much different than unloading the kext. > >More testing shows that unloading the kext does cause the IOUserClient >to be terminated and closed. > >Unfortunately, Disk Utility and friends can't operate on the disk until >the IOUserClient instance is closed. I get a "Resource Busy" error. > >How should I handle this situation? I figure I can track IOUserClient >instances, but how would I know that I need to disconnect them? > >Thanks for the tips, ...Duane _______________________________________________ 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: HowTo: catch a signal and get a CrashLog too (Leopard)
by James Peach 19 Dec '07

19 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=sXDVSvarvDjpd82OcEJB8VHVU8p+vhUKzKqgU56j0BA=; b=vQDYFT20xFzakeN9SaWQ1Tkpg/EtgMAjgMhLC3abIS4Q3nEaoJo8VmOwctg6bBYa06zxdkS/tAV0ej3Rz2oKBS20OMECRLDBZcOnEDllsStPRsqyV7E06UtsF09NVrxOHaxx+jW2AD1LWXp7G/UhXjEIKMxDTZsZisvAvnjp3QQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VqBngjjU/+1O/POYxvQh8qbeNMgg7PON7Hg/5Lx6Z3ehx6TTswpJ2MC/Bsxn83nfH3icfnz9Zaf3/Rz7NXxVaMqiKQloB/b9NwnAivzQhObam5W0a08p5NNol6Ukmt0L/88gPo78c4RLT7QcNs/RedylY7kVt+qQPt7JjTxBQ7w= On 18/12/2007, David Hoerl <dhoerl(a)mac.com> wrote: > [This for archive searchers. signal() signals CrashLog CrashReporter > OSX Darwin] > > It took me a while to get this going, thus the post. I have a C-based > command line tool (CLI) process. It writes logs, and while it could > report its own failures, crashes resulted in no log entry. So, I > started catching signals, and write my log (stderr), which worked > fine (see below). > > However, it seems that at least in Leopard, when you catch a signal, > CrashReporter will not process the crash. Hmmm. So I found that if I > raised another uncaught signal in the handler, voila, CrashReporter > creates a crash report, so now I get both. > > #include <signal.h> > > static void crashCatcher(int sig); > static char exitStr[] = "Exit due to Signal "; > static char finalStr[] = ".\n"; > > // whatever you want to catch - man 3 signal > (void)signal(SIGILL, crashCatcher); > (void)signal(SIGFPE, crashCatcher); > (void)signal(SIGBUS, crashCatcher); > (void)signal(SIGSEGV, crashCatcher); > (void)signal(SIGSYS, crashCatcher); // probably overkill > (void)signal(SIGILL, crashCatcher); > > static void > crashCatcher(int sig) > { > char c; > > // should not use buffered IO as it may use malloc and friends > // suggested by Dalrymple and Hillegass, "Advanced Mac OS Prog.", > // been very helpful to me > write(STDERR_FILENO, exitStr, strlen(exitStr)); > write(STDERR, exitStr, sizeof(exitStr)-1); > c = '0' + (sig/10); > write(STDERR, &c, 1); > c = '0' + (sig%10); > write(STDERR, &c, 1); > write(STDERR, finalStr, sizeof(finalStr)-1); > > // since we caught the signal, CrashReporter will otherwise not run > // however, this signal is uncaught, so it will crash us and > CrashReporter will run! > raise(SIGQUIT); > } This works, but re-raising a signal does run the risk of producing a stack trace that CrashReporter can't walk correctly. I've seen cases where my own stack logging code and CrashReporter disagree wildly on what the real stack trace is. IMHO it's better to just let the fatal signals go straight through to CrashReporter unless you have a really food reason. -- James Peach | jorgar(a)gmail.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

Closing an IOUserClient
by Duane Murphy 19 Dec '07

19 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I have an IOUserClient subclass whose provider is a file system filter. When the file system is unloaded/unmounted the user client remains connected. This causes Disk Utility and friends to be unhappy operating on the disk (ie partitioning). I would have expected the terminate() set of calls to cause the user client to unload. The UserClient is not being called at all during unmounting. Further testing shows that unmounting a file system doesn't actually remove the kext (it's above the partition layer). My suspicion is that unmounting a file system is much different than unloading the kext. More testing shows that unloading the kext does cause the IOUserClient to be terminated and closed. Unfortunately, Disk Utility and friends can't operate on the disk until the IOUserClient instance is closed. I get a "Resource Busy" error. How should I handle this situation? I figure I can track IOUserClient instances, but how would I know that I need to disconnect them? Thanks for the tips, ...Duane _______________________________________________ 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

HowTo: catch a signal and get a CrashLog too (Leopard)
by David Hoerl 18 Dec '07

18 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com #include <signal.h> static void crashCatcher(int sig); static char exitStr[] = "Exit due to Signal "; static char finalStr[] = ".\n"; // whatever you want to catch - man 3 signal (void)signal(SIGILL, crashCatcher); (void)signal(SIGFPE, crashCatcher); (void)signal(SIGBUS, crashCatcher); (void)signal(SIGSEGV, crashCatcher); (void)signal(SIGSYS, crashCatcher); // probably overkill (void)signal(SIGILL, crashCatcher); static void crashCatcher(int sig) { char c; // should not use buffered IO as it may use malloc and friends // suggested by Dalrymple and Hillegass, "Advanced Mac OS Prog.", // been very helpful to me write(STDERR_FILENO, exitStr, strlen(exitStr)); write(STDERR, exitStr, sizeof(exitStr)-1); c = '0' + (sig/10); write(STDERR, &c, 1); c = '0' + (sig%10); write(STDERR, &c, 1); write(STDERR, finalStr, sizeof(finalStr)-1); Could be there is a better way, but my googling found nothing. _______________________________________________ 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 for archive searchers. signal() signals CrashLog CrashReporter OSX Darwin] It took me a while to get this going, thus the post. I have a C-based command line tool (CLI) process. It writes logs, and while it could report its own failures, crashes resulted in no log entry. So, I started catching signals, and write my log (stderr), which worked fine (see below). However, it seems that at least in Leopard, when you catch a signal, CrashReporter will not process the crash. Hmmm. So I found that if I raised another uncaught signal in the handler, voila, CrashReporter creates a crash report, so now I get both. // since we caught the signal, CrashReporter will otherwise not run // however, this signal is uncaught, so it will crash us and CrashReporter will run! raise(SIGQUIT); } This email sent to site_archiver(a)lists.apple.com

1 0

Re: How does 'Finder' open an application and bring the window to the front?
by Terry Lambert 18 Dec '07

18 Dec '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, there, -- Terry _______________________________________________ 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… On Dec 18, 2007, at 8:06 AM, Calvin Liu wrote: On Mac, if I run a command in terminal and start a GUI application, the new window is always hide behind the current window. So does start apps from other application like firefox. But noticed that double click an icon in "Finder" can start it correctly. So I did some test and found that if I wrap the command into a fake ".app" folder and use "open -a fake.app", it'll show the new window in the front. It's not good solution and I'm sure I haven't got the root reason. I suppose there is an option in the configuration file of window manager for MacOS to control this behavior. Am I right? Anyone has any idea on what that option is and how to change it? I'm going mad with this problem. It is an effect of using LaunchServices, rather than vanilla fork/exec or posix_spawn to start the process. If you want this behaviour, use LaunchServices (which is what the command line tool "open" does). This will have the side effect of running the correct slice of the application, for example if you checked the "Run under Rosetta" checkbox in finder for Safari to ensure you will be able to continue to use your PPC plugins on an Intel machine. This email sent to site_archiver(a)lists.apple.com

1 0