March 2009 - Darwin-dev - lists.apple.com

Re: confusion about memory fragmentation, vm, and blocks
by Shawn Erickson 03 Mar '09

03 Mar '09

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:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZbZwlsthyzOTux7x7GgnqbqOtoKL6jh8WxnAWMu2yyE=; b=f8JOhBQfY3JnTV3oXwKr4S/V7phVRNWaleGdQ27fZYbfSsXNIeuWZuelbP4IUKDrT3 NCciWzK+Vgaj+0pjkKMS3Cz+wQ+F9/73ykEIhNlVqD9h3zH7JtIKSRsuT0QBi46Ahd55 4Hz2UDZaAvdZRR8F0UC+l/IvcMaklFQG9sUtE= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DEBu6T0qLU0JjThTMBmSSUWP+8ji5TL2nPAkrMwIWGw6ON+NvgLSvAyoNdhacqywI7 xnjaEO26b9QkKqPlTdGpOkflW5HP4nYK0ib6HAa2f8umO13j7qJ7Nr6FzKK3Np2W+kHO DIjya145RyHEYskyjFa05Zsp47l0rbg8tEzyc= On Tue, Mar 3, 2009 at 7:57 AM, Mario Emmenlauer <mario(a)emmenlauer.de> wrote: > > Hi all, > > I have a problem understanding memory allocation, blocks and fragmentation. (at a high level with some hand waving...) Applications work with/in a virtual memory space. The VM sub-system of the operating system manages a mapping between the pages in an applications virtual memory space to pages in some physical storage device (RAM, page file on disk, etc.). The amount of memory your application can address at a given time is limited first by the size of the virtual memory space, minus reserved/invalid/guard pages, minus pages mapped for shared libraries, minus pages mapped for use by the OS, etc., minus allocations made by your code. All of these allocations carve out ranges in your virtual address space with the unused ranges between them representing "available" memory to your application. When you allocate (malloc, etc.) a buffer you get back a pointer to a contiguous virtual memory range (how the API is defined). If you attempt to allocate a buffer larger then any of the available contiguous virtual memory ranges it will fail... despite possibly having smaller contiguous ranges available that, if contiguous, would have allow the allocation to succeed. (note I side stepped "pools" of virtual memory pages that malloc maintains for small, tiny, etc. allocations to minimize fragmentation and speed re/allocations) General it is "hard" to know how much virtual memory your application has available to it at any given time... likely best to just attempt to allocate what you when you need it and if that fails back off and/or purge any data caches your application itself maintains and try again. ...not knowing exactly your situation... You could consider using a memory mapped file and slide around a "window" of contiguous mappings over that file. This would limit/bound how much virtual memory you use at a given time while giving you access to an arbitrarily large buffer. ...of course it would be far easier to switch your application to use a 64b virtual address space. Anyway try pointing vmmap at an application of your choice to get an idea about the virtual mappings that exist. -Shawn _______________________________________________ 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: GCC stack size
by Brian Mastenbrook 03 Mar '09

03 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 3, 2009, at 3:35 PM, Ryan McGann wrote: void foo(int flag) { if (flag) { largeStackUsingFunction(); } else { char buf[1000]; /* ... other code which does not call functions ... */ } } We have some sample code that shows that the temporary returned from the function doMath is allocated stack space twice, when it can only be used once. But since the function in our actual production code is pretty complex, it's hard to know hwich problem we are experiencing. However, the above examples are both well documented cases of GCC problems; I actually got the basic ideas for both examples from Linus Torvald's (sometimes long) emails regarding Linux's problems with GCC stack allocation. I've been bitten by this problem in the past as well, especially in functions that look a lot like the examples you've given (where an outer if wraps several complex code blocks). The worst of it is that in this example: The call to largeStackUsingFunction() will occur after the stack pointer is adjusted for buf's usage, which can result in non-obvious stack overflows. There is a gcc bug sitting in bugzilla to fix it, but nothing is being done on it: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474 . There are still a few options left to you that I can think of. The first is to use LLVM - but in a slightly different way. Try running the code through llvm-gcc with the C backend, and fiddling with the different LLVM optimization settings. It's possible that llvm's better analysis of local variable liveness will result in (mangled and unreadable) C output that doesn't demonstrate the problem. Another option would be to hack up a transformer using clang (assuming your code is pure C), which would perform directed partial outlining on the functions you've identified to be problematic. -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net/ _______________________________________________ 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: GCC stack size
by Ryan McGann 03 Mar '09

03 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Tuesday, March 03, 2009, at 12:55PM, "Shawn Erickson" <shawnce(a)gmail.com> wrote: >On Tue, Mar 3, 2009 at 12:08 AM, Ryan McGann <rmcgann(a)mac.com> wrote: > >> Just to let everybody know (and for the sake of the archives), it appears to >> be our kernel extension is running into a known limitation of GCC. Just to >> recap, we have a function in a very portable, very lightweight library, that >> for some reason is getting compiled with a 1600+ byte stack when compiled >> on/for Darwin. No matter what compiler options I tried, and what >> optimization levels I used, the stack was no smaller than 1400 bytes. > >I am curious if you could create a simple stand alone code example >that shows the issue you are seeing? > >It would be helpful for others to understand the issue and possibly avoid it. We do and we don't. We have some code that definitely shows that GCC does not re-use stack slots for variables in a different scope. For example: void foo(int a) { if (a < 100) { int array[ 32 ]; <do something> } else { int array[ 48 ]; <do something> } } (sorry the real sample is on another computer, this is a simplified version. I am working on cleaning it up for a bug submission to Apple). But we have a sample like that shows that both array variables get their own stack slots, when they can obviously share most of their stack space. But, I am not 100% certain that is our problem. There is another case where GCC can mistakenly allocate more stack than necessary, when dealing with temporary variables. For example int doMath(int b, int c); void foo(int a) { if (a + (doMath( rand(), rand() )) < 100) { <do something> } else if (a + doMath( rand(), rand() )) < 200 { <do something> } } We have some sample code that shows that the temporary returned from the function doMath is allocated stack space twice, when it can only be used once. But since the function in our actual production code is pretty complex, it's hard to know hwich problem we are experiencing. However, the above examples are both well documented cases of GCC problems; I actually got the basic ideas for both examples from Linus Torvald's (sometimes long) emails regarding Linux's problems with GCC stack allocation. The real problems in GCC are more complex than the above examples, but are easy to reproduce. Once I have the samples cleaned up and I submit my bug I can post them. Ryan >-Shawn > > _______________________________________________ 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: GCC stack size
by Eli Bach 03 Mar '09

03 Mar '09

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:from:to :in-reply-to:content-type:content-transfer-encoding:subject :mime-version:date:references:x-mailer; bh=AWaRLqGJWf7kW2C/5UF9nhw56pYFAzyDNu6ENRHAdXg=; b=gPPekiUquSG1FJ+jx0lI1APCojAxvg2KS0tDdtzVq52TynN1gxN3o5y/5BqT6BUehk vJxk/lMCuE5BYfDpVWNS86SP7EGGF+pjupOMsQp4TtjxPb2jKzw3LJwwCYwh2cugfzxQ mZbOinXLUscXTV6xRlJ574TayN3campLqt/zE= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:subject:mime-version:date:references :x-mailer; b=YzVcn8nynDOuUyCzL9HR78FswuotqBaYFjjrSZ4gVoK8B2mkOzu64NN3L8Eh1nTUUZ G34CilMP7PlssHO7rVSCIu+IgGlu3PQx+6RbzFaD8gTLh+05tOql/nEYZomjO/TdcJEH mG9CBgmEcWgdAZ6NRmCnEbgpq42g6X1KdovLA= On Mar 3, 2009, at 11:59 AM, Ryan McGann wrote: Sorry but LLVM is out of the question. We need 10.4 support and AFAIK code compiled with LLVM won't run on 10.4. Thanks for trying though. I'll look at IBM's PowerPC compiler but I won't hold my breath. Ryan, Something if you start with something like this: void TestFunc() { { CClassA * a; a = new CClassA; a->FuncA(); ... } { CClassB * b; b = new CClassB; b->FuncB(); ... } } and you do a text replacement on it to change it to: void TestFunc() { void * shared; { shared = (void *)new ClassA; ((ClassA *)shared)->FuncA(); } { shared = (void *)new ClassB; ((ClassB *)shared)->FuncB(); } } Eli _______________________________________________ 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… -- Ryan Could you 'cheat', presuming you can work out scoping yourself to make sure you don't reuse variables improperly, but you could maybe script text replacement so that the original code still uses properly scoped variables, but the batch changed code uses variables with function scope, possibly with typecasts also inserted automatically. I would create a script to do this automatically, rather than manually doing it (other than the first time), but this might help you get the stack size down to a more reasonable level. This email sent to site_archiver(a)lists.apple.com

1 0

Re: GCC stack size
by Shawn Erickson 03 Mar '09

03 Mar '09

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:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1rZ6w/MUuM6XGAjojgKtSnIWE5h4k/eICCNmHkroTXI=; b=YhtrJNLTGOwHeqRvkLmPwXF99bEPoXgIoit+BtNqR/Zful3FgZbPFyKf0erVqmeMj/ kT/KJn40ZpsNmUBo6aW6SuZj+wHNcPVd1XRCPl46pnREM7CypN7SQFSNaqOmOfPQ7tuk jP8bR5fNWyewLL4kP46/ykyVunim1v/TU5XWQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YUEjiwsu7THOyX+STcDTAHOOLRjnaQuwBlz69X6u9i+57z8wKz38FAkrTguqKFyxXT eey6XJUaMy8zSVkR/WcEdOg/jT89HbIboflzb9O6lqyf4JpeeTED1lF4GgTSlAgjj0Li spuEJqnwSt7k9whGTlTLwPBjb8Wz6cvAtppN0= On Tue, Mar 3, 2009 at 12:08 AM, Ryan McGann <rmcgann(a)mac.com> wrote: > Just to let everybody know (and for the sake of the archives), it appears to > be our kernel extension is running into a known limitation of GCC. Just to > recap, we have a function in a very portable, very lightweight library, that > for some reason is getting compiled with a 1600+ byte stack when compiled > on/for Darwin. No matter what compiler options I tried, and what > optimization levels I used, the stack was no smaller than 1400 bytes. I am curious if you could create a simple stand alone code example that shows the issue you are seeing? It would be helpful for others to understand the issue and possibly avoid it. -Shawn _______________________________________________ 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: GCC stack size
by Ryan McGann 03 Mar '09

03 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Sorry but LLVM is out of the question. We need 10.4 support and AFAIK code compiled with LLVM won't run on 10.4. Thanks for trying though. I'll look at IBM's PowerPC compiler but I won't hold my breath. -- Ryan On Tuesday, March 03, 2009, at 11:56AM, "Ryan McGann" <rmcgann(a)mac.com> wrote: >Sorry but LLVM is out of the question. We need 10.4 support and AFAIK >code compiled with LLVM won't run on 10.4. Thanks for trying though. > >I'll look at IBM's PowerPC compiler but I won't hold my breath. > >-- Ryan > >On Mar 3, 2009, at 6:53 AM, Boyd Waters <waters.boyd(a)gmail.com> wrote: > >> Use LLVM! Version 2.5 has just been released, and the previous >> release is part of XCode 3.1. >> >> What happens of you use the LLVM back-end (code generation) with the >> GCC front-end? Try that by using "llvm-2.4-gcc" >> >> What happens when you use the llvm front-end? Try that using "ccc". >> >> Sent from my iPhone >> >> On Mar 3, 2009, at 1:08 AM, Ryan McGann <rmcgann(a)mac.com> wrote: >> >>> Just to let everybody know (and for the sake of the archives), it >>> appears to be our kernel extension is running into a known >>> limitation of GCC. Just to recap, we have a function in a very >>> portable, very lightweight library, that for some reason is getting >>> compiled with a 1600+ byte stack when compiled on/for Darwin. No >>> matter what compiler options I tried, and what optimization levels >>> I used, the stack was no smaller than 1400 bytes . Since it's in >>> the kernel that stack size is much too large, and is causing a >>> "machine check" panic in pretty reproducible (but not frequent) >>> situations. >>> >>> After a lot of searching on the Web, learning some i386 assembly >>> and talking to some people who are much better at assembly, I have >>> learned that GCC is somewhat notorious for having horrid stack >>> allocation. Sure enough, Visual Studio C++ compiles this the exact >>> same code with absolutely no modifications or macro trickery, and >>> the function is given a 96 byte stack (which is exactly what we >>> wrote it to have). >>> >>> Apparently this is gcc's dirty little secret, except it's not much >>> of a secret to some--Linus Torvalds has complained several times on >>> various lists about the gcc stack allocation (search lkml.org for >>> "gcc stack usage"). Once I knew what to search for, there was >>> plenty of griping about gcc's subpar allocation of stack variables, >>> and in particular, it's inability to re-use stack space for >>> variables in different scopes. >>> >>> Unfortunately none of this helps me find an actual solution. The >>> library is too portable, and too complex, to hand-code in assembly >>> for 3 different architectures. So for now we are shopping around >>> for different compilers. I am trying the Intel compiler tomorrow to >>> see what its output is like, but the PowerPC code still has the >>> same problem. Unless anybody knows of an alternative PowerPC- >>> capable compiler that runs on Mac OS X, our PowerPC users might >>> have to live with a much more limited featureset (I don't think I >>> can convince anybody to live with a "rare but reproducible panic"). >>> >>> Thanks, >>> Ryan >>> >>>> A couple weeks ago I asked about a machine-check panic I was >>>> getting. As it turns out, my suspicions were right about stack >>>> corruption. I disassembled a function in our kext and saw that for >>>> some reason, GCC's function prologue was allocating around 1660 >>>> bytes of stack (in release, debug was slightly better at 1140 >>>> bytes). On other platforms compiled with GCC (FreeBSD and many >>>> different Linux distros) the stack usage is near 110 bytes, but >>>> for some reason gcc on Mac OS X is allocating almost 4K. >>>> >>>> We are currently using -O3 because the code is pretty compute- >>>> bound, and on other platforms -O3 has a nice 5% boost compared to - >>>> O2. But changing it to -O2 doesn't even help, we have to go all >>>> the way to -O1 to get a usable stack of 400 bytes (still 4x larger >>>> than our Linux driver). >>>> >>>> The code is vanilla C++ without anything fancy—no virtual functi >>>> ons even. There are no warnings about temporarys being used, so >>>> I have no clue what is causing the stack usage. It's a huge func >>>> tion with a lot ofswitch statements and for loops, but not a lot >>>> of function calls, mostly just computes on arrays of data. My b >>>> est guess is that GCC is trying to optimize the intermediate ope >>>> rations and temporary results by placing them on the stack. >>>> >>>> Anybody have ideas on how to show where GCC is allocating things >>>> in the frame, and how to reduce the stack usage? It's hard to >>>> distill this to a single issue because the function is so large, >>>> but I am tempted to file a bug since GCC 4 optimizes things quite >>>> nicely on other platforms. >>> _______________________________________________ >>> 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/bwaters%40nrao.edu >>> >>> This email sent to bwaters(a)nrao.edu > > _______________________________________________ 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

confusion about memory fragmentation, vm, and blocks
by Mario Emmenlauer 03 Mar '09

03 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.18 (Macintosh/20081105) Hi all, I have a problem understanding memory allocation, blocks and fragmentation. According to what I have read, memory allocation can only allocate as much as the largest contiguous free block is in size. What I fail to understand is whether that is true only for the operating system, or if its the same from an applications point of view. What actually confuses me is that I assumed from the applications point of view all memory is virtual memory? Since the OS has to map application addresses to pages and a backing store, I would assume that blocking happens invisible to the application? On a side note, what I'm trying to achieve is knowing how much free memory my app can access. If blocking is not invisible to the application, then do I need to probe for blocks of decreasing size repeatedly? If it is invisible, then the largest successful allocation should give me all free memory? Best, Mario _______________________________________________ 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: GCC stack size
by Ryan McGann 03 Mar '09

03 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thanks, Ryan _______________________________________________ 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… Just to let everybody know (and for the sake of the archives), it appears to be our kernel extension is running into a known limitation of GCC. Just to recap, we have a function in a very portable, very lightweight library, that for some reason is getting compiled with a 1600+ byte stack when compiled on/for Darwin. No matter what compiler options I tried, and what optimization levels I used, the stack was no smaller than 1400 bytes . Since it's in the kernel that stack size is much too large, and is causing a "machine check" panic in pretty reproducible (but not frequent) situations. After a lot of searching on the Web, learning some i386 assembly and talking to some people who are much better at assembly, I have learned that GCC is somewhat notorious for having horrid stack allocation. Sure enough, Visual Studio C++ compiles this the exact same code with absolutely no modifications or macro trickery, and the function is given a 96 byte stack (which is exactly what we wrote it to have). Apparently this is gcc's dirty little secret, except it's not much of a secret to some--Linus Torvalds has complained several times on various lists about the gcc stack allocation (search lkml.org for "gcc stack usage"). Once I knew what to search for, there was plenty of griping about gcc's subpar allocation of stack variables, and in particular, it's inability to re-use stack space for variables in different scopes. Unfortunately none of this helps me find an actual solution. The library is too portable, and too complex, to hand-code in assembly for 3 different architectures. So for now we are shopping around for different compilers. I am trying the Intel compiler tomorrow to see what its output is like, but the PowerPC code still has the same problem. Unless anybody knows of an alternative PowerPC-capable compiler that runs on Mac OS X, our PowerPC users might have to live with a much more limited featureset (I don't think I can convince anybody to live with a "rare but reproducible panic"). A couple weeks ago I asked about a machine-check panic I was getting. As it turns out, my suspicions were right about stack corruption. I disassembled a function in our kext and saw that for some reason, GCC's function prologue was allocating around 1660 bytes of stack (in release, debug was slightly better at 1140 bytes). On other platforms compiled with GCC (FreeBSD and many different Linux distros) the stack usage is near 110 bytes, but for some reason gcc on Mac OS X is allocating almost 4K. We are currently using -O3 because the code is pretty compute-bound, and on other platforms -O3 has a nice 5% boost compared to -O2. But changing it to -O2 doesn't even help, we have to go all the way to - O1 to get a usable stack of 400 bytes (still 4x larger than our Linux driver). The code is vanilla C++ without anything fancy—no virtual functions even. There are no warnings about temporarys being used, so I have no clue what is causing the stack usage. It's a huge function with a lot ofswitch statements and for loops, but not a lot of function calls, mostly just computes on arrays of data. My best guess is that GCC is trying to optimize the intermediate operations and temporary results by placing them on the stack. Anybody have ideas on how to show where GCC is allocating things in the frame, and how to reduce the stack usage? It's hard to distill this to a single issue because the function is so large, but I am tempted to file a bug since GCC 4 optimizes things quite nicely on other platforms. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Get executable name & path
by Terry Lambert 02 Mar '09

02 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -- Terry _NSGetExecutablePath See: http://developer.apple.com/samplecode/MoreIsBetter/ Mike On Mar 2, 2009, at 9:20 AM, Rohitash Panda wrote: Thanks. -- Rohitash Panda | Database Platform Specific Development Server Technologies _______________________________________________ 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… Which will get you the path saved on the stack base for use in getting the bundle ID. This is the path that was used to start the executable. And of course there is no guarantee it dies not contain symbolic links as path components, nor that the filesystem geomentry has remained constant since the program was started, so it's entirely possible to substitute something else in its place, if permissions were not set to prevent that. This is the problem with after the fact use of paths. Hopefully the reason he wanted to "skip if it's a link" was not related to security. On Mar 2, 2009, at 6:43 AM, Mike Tegtmeyer <tegtmeye(a)eecis.udel.edu> wrote: Folks, Is there a portable way to get the name of the current executable including the path ? I need to get the absolute path and also skip if its a link. This email sent to site_archiver(a)lists.apple.com

1 0

Re: problem in launching the daemons
by Eli Bach 02 Mar '09

02 Mar '09

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:from:to :in-reply-to:content-type:content-transfer-encoding:subject :mime-version:date:references:x-mailer; bh=RahVKUCPeFIPS2jTzPA4iHCgu/AB5MQus5N3WZTpMjk=; b=Uni1zpz/LKdA0QHEo93HWyQ5Y0+ooULaAupHcEnMbhcDXXAzZdKVV1nZf2oWY4/fSC SbubKht3xeQknw0cF+2okL2j60AEjZYWTxlOAGRzavHTp7jRgfFMGuyUA0jJNX/qi1hX Ka8qd2ENr6MiOZ1k0K81VRUR6hpcVONPTveFg= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:subject:mime-version:date:references :x-mailer; b=Ooin/+LabeM19hZ4VEGlcqejBQuPYS+6UJMhfrf7wKPGmWnizqTqjKhVxmGmV274UI WrZ6kW2hGI0qEvZyLV3fUwoAsVMUVSfh3+ffwWIHzPjn8bqSi80DRfdiGV6j05HzB3pJ RFb6JjCNKuTjMl953UejX3Yv1WwnaAou0AaPE= On Mar 2, 2009, at 5:11 AM, sandeep chaudhary wrote: Hi all, But I am not able to run the daemons.Here is my plist file - Thanks -sandeep Also, you can try: sudo launchctl load <path to plist file> Eli _______________________________________________ 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 am working on launching the daemons,which will run on background continously. I have created a plist and put it into the /Library/ LaunchedDaemons. I have set the owner- root and group- wheel to the plist.The plist will run application which is located on the following locaton - "/library/Applications". <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd "> <plist version="1.0"> <dict> <key>Label</key> <string>CXComServiceApp</string> <key>OnDemand</key> <true/> <key>RunAtLoad</key> <true/> <key>ProgramArguments</key> <array> <string>/Applications/Cxtra/CXComServiceApp.app/Contents/MacOS/ CXComServiceApp</string> </array> </dict> </plist> Here CXComServiceApp is the application which i want to run as a daemons. What i am doing wrong? Could you tell me how can i run the daemons in details. What are the terms and conditions which i am not follwings. Use Console.app to look at the system log. That should give you some idea of why it's failing. launchctl should tell you why it decided not to load your daemon if it fails. And the path you listed in the plist doesn't match the path you mention in your description. This email sent to site_archiver(a)lists.apple.com

1 0