July 2006 - Darwin-dev - lists.apple.com

Keyboard LEDs
by Nathaniel Gray 12 Jul '06

12 Jul '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 1.5.0.4 (Macintosh/20060530) Hi, Thanks, -Nathan PS: Please CC me. -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.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… I just got a little USB KVM (Zonet KVM3122) that I'm pretty happy with except that the hotkey for switching (double-scroll-lock) doesn't work on my mac. I know that Apple keyboards don't have scroll lock, but my logitech keyboard does have one, and I've learned that the KVM actually detects the hotkey combo by detecting the signal to toggle the scroll lock *LED*, not the keypresses themselves. Under Linux, I can write a one-line script to switch the KVM using 'xset led', but after some searching I've not been able to find any info on how one might do something similar in OS X. Is it even possible to modify the keyboard LEDs programmatically on a USB keyboard? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Global destructors called for invalid objects on Darwin x86, but nowhere else.
by Steve Checkoway 12 Jul '06

12 Jul '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Thunderbird 1.5.0.4 (X11/20060516) I'll try to provide as many details as I can below, but for a quick summary, I have two C++ files within a library where if there are any non-trivial global constructors called within them, they will abort at cleanup. This included any global data that is constructed but never accessed, and does not seem to be dependent on the name of the object or namespace that it is declared within (I've tried lots of combinations). Several hours of peeking and poking through the debugger (I'll admit that I don't track down these kinds of failures very often) led me to two files that are having problems: src/cimom/common/OW_CIMOMEnvironment.cpp and src/cimom/common/OW_AuthorizerManager.cpp The problem is most easy to locate when running the unit tests on OW_ProviderManager and OW_ProviderMuxLoader (both of which call functions that play with the CIMOMEnvironment global class). Removing any objects with non-trivial global constructors from these two files in the cimom common library seems to fix things. I don't believe there is a problem with the code, as this functions properly with several compilers on many platforms and only breaks on the x86 version of Darwin. The PPC version, with a much older xcode and gcc3.3, seems to work fine, so it could be a gcc4 issue. The PPC version also runs correctly with rosetta. If anyone has any suggestions for things to check/fix, or could actually apply their uber Mac debugging skills, I would really appreciate it. // In GlobalData.h class GlobalData { static GlobalData *sharedData; int count; // Other private members here. GlobalData() {} ~GlobalData() {} public: GlobalData *AcquireGlobalData(); void ReleaseGlobalData(); // Other public members here. }; // In GlobalData.cpp GlobalData *GlobalData::sharedData = NULL; GlobalData *GlobalData::AcquireGlobalData() { if( sharedData == NULL ) sharedData = new GlobalData; ++sharedData->count; return sharedData; } void GlobalData::ReleaseGlobalData() { assert( sharedData ); if( sharedData.count ) return; delete sharedData; sharedData = NULL; } -- Steve Checkoway _______________________________________________ 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… Kevin Harris wrote: [...] C++ makes no guarantees as to the order that dtors are called. My guess is that the CIMOMEnvironment has some global (probably singleton) class and its dtor is being called before whatever is crashing. If this is the case, you'll need to restructure your code in such a way as to avoid this ordering dependency. I seem to recall reading of other issues of this nature before. I think that the x86 version calls the dtors in a different order than the ppc version of g++. One idea is to reference count the global object and not to destroy it until no other object is using it. Something like: Note, this was written in Thunderbird without testing and this isn't thread safe. This email sent to site_archiver(a)lists.apple.com

1 0

Global destructors called for invalid objects on Darwin x86, but nowhere else.
by Kevin Harris 11 Jul '06

11 Jul '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hUXHxg6TBMiUc6JbbiB8Ti/PoRnipJibxiHYmIBFSKz42IFZNHc+yQ61Z18uGqhxYsaSOLu8nsfECmfyU1VLajy12xidrWmqTkEAW52l3lf4n+n1nRDyeYDbVOOkTFWpnx57BsW+wZr+RIkoYxjsH/CqMSom5VJaVHlsHxwg3KA= I have been trying to make the OpenWBEM project (www.openwbem.org) run natively on Darwin i386. It already runs on the latest PPC version, as well as many other platforms. I have run into issues with global constructors and destructors. I apologize in advance for the length of this message, and you can just read the next paragraph to get an idea of what is going on. Any assistance would be greatly appreciated. I'll try to provide as many details as I can below, but for a quick summary, I have two C++ files within a library where if there are any non-trivial global constructors called within them, they will abort at cleanup. This included any global data that is constructed but never accessed, and does not seem to be dependent on the name of the object or namespace that it is declared within (I've tried lots of combinations). Machine configuration: Kernel: Darwin Kernel Version 8.7.1 Mac OS X: 10.4.7 Build 8J2135 xcode: 2.2.1 (also just upgraded to 2.3 and tried it) I would like to create an example of how it breaks, but this project is so large, and the error only occurs in one library (specifically two files within that library), so it would take a lot of effort to duplicate it in some simple code. If anyone would like to assist (or just doesn't believe me), the OpenWBEM module is at cvs.openwbem.org:/cvsroot/openwbem on branch BRANCH_SECURITY. Basically, everything seems to run correctly. When things exit (or libraries get unloaded), the global destructors get called for that library. These destructors start executing on what appears to be invalid data. The strange part of this is that this happens to everything within a file (including unused/untouched items added for testing) if any of the global data in that file is accessed. I first suspected that some form of stack smashing was occuring, but I ran everything with the malloc debugging with the stack logging (and every other runtime memory debugging option I could find) turned on, and nothing showed up. Several hours of peeking and poking through the debugger (I'll admit that I don't track down these kinds of failures very often) led me to two files that are having problems: src/cimom/common/OW_CIMOMEnvironment.cpp and src/cimom/common/OW_AuthorizerManager.cpp The problem is most easy to locate when running the unit tests on OW_ProviderManager and OW_ProviderMuxLoader (both of which call functions that play with the CIMOMEnvironment global class). Removing any objects with non-trivial global constructors from these two files in the cimom common library seems to fix things. Here's a sample stack trace from running test/unit/unitMain with OW_ProviderManager as the sole argument, showing the destructors calling functions on invalid objects: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000005 0x00132630 in OpenWBEM6::AtomicDecAndTest (v=@0x5) at ../../src/common/OW_AtomicOps.hpp:79 79 :"m" (v.val) : "memory"); (gdb) where #0 0x00132630 in OpenWBEM6::AtomicDecAndTest (v=@0x5) at ../../src/common/OW_AtomicOps.hpp:79 #1 0x00132695 in OpenWBEM6::RefCount::decAndTest (this=0x5) at ../../src/common/OW_RefCount.hpp:64 #2 0x0013e2a0 in OpenWBEM6::COWIntrusiveReferenceRelease (p=0x1) at ../../src/common/OW_COWIntrusiveCountableBase.hpp:102 #3 0x05b3dd2c in OpenWBEM6::COWIntrusiveReference<OpenWBEM6::String::ByteBuf>::~COWIntrusiveReference (this=0x3eccaa8) at OW_COWIntrusiveReference.hpp:100 #4 0x05a5d171 in OpenWBEM6::String::~String (this=0x3eccaa8) at OW_String.cpp:328 #5 0x03e022ed in OpenWBEM6::(anonymous namespace)::Node::~Node (this=0x3eccaa8) at OW_CIMOMEnvironment.cpp:1264 #6 0x03dd9648 in __tcf_1 () at OW_CIMOMEnvironment.cpp:1287 #7 0x03dc8525 in cxa_atexit_wrapper () #8 0x90010cc1 in __cxa_finalize () #9 0x90010bc8 in exit () #10 0x00002a2a in _start (argc=2, argv=0xbfffd298, envp=0xbfffd2a4) at /SourceCache/Csu/Csu-58.1.1/crt.c:272 #11 0x0000293d in start () Your stack trace (if you build/run this) will likely show a different failure point in the same file, as my copy of that file has been altered to remove all but the one non-trivial global constructor. I don't believe there is a problem with the code, as this functions properly with several compilers on many platforms and only breaks on the x86 version of Darwin. The PPC version, with a much older xcode and gcc3.3, seems to work fine, so it could be a gcc4 issue. The PPC version also runs correctly with rosetta. If anyone has any suggestions for things to check/fix, or could actually apply their uber Mac debugging skills, I would really appreciate it. Thank you for your time. -Kevin- _______________________________________________ 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: Resolving a Mach-O symbol address into a variable address at runtime
by Damien Sorresso 11 Jul '06

11 Jul '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Damien Sorresso Macintosh Developer Computer Infrastructure Support Services Illinois State University damien.sorresso(a)ilstu.edu void *mainHandle = dlopen(NULL, RTLD_LAZY); if( !mainHandle ) { printf("dlopen() failed.\n"); } int *debug_addr = (int *)dlsym(mainHandle, "__debug_level"); printf("debug_addr = 0x%x->0x%x\n", debug_addr, *debug_addr); dlclose(mainHandle); -- Damien Sorresso Macintosh Developer Computer Infrastructure Support Services Illinois State University damien.sorresso(a)ilstu.edu Now, I can grab the symbol's address using nlist(...), but I want to in turn take this address and find the location of the variable in memory at runtime. I've already tried CFBundleGetDataPointerForName (...); it doesn't work. Don't ask me why. I've been pouring over the Mach-O documentation, and I'm thinking that the best way to go about it would be to grab the `vmaddr' member of the `segment_command' structure to determine the VM address of the __DATA segment and then work from there, but I'm not sure how to specifically go about doing this. Use dlopen/dlsym, see the manpages. _______________________________________________ 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/dsorres%40ilstu.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 Nevermind. I'm a retard. Got my pointers confused. Everything's working; thanks for the help! :) -- On 11 Jul, 2006, at 11:35 AM, Damien Sorresso wrote: dlsym(...) gives me the information I already have: the symbol address in the Mach-O file. I need the address of the variable the symbol corresponds to at runtime. Or am I doing something wrong here? This is what I'm doing. On 11 Jul, 2006, at 10:52 AM, Peter O'Gorman wrote: On Tue, 2006-07-11 at 10:34 -0500, Damien Sorresso wrote: I've got a loadable bundle in a Cocoa application, and I'd like this bundle to grab the value of a global symbol from the main application after it's been loaded, specifically a global debugging level. Peter This email sent to dsorres(a)ilstu.edu smime.p7s

1 0

Re: How to do a blocking read from a serial device?
by Steve Checkoway 11 Jul '06

11 Jul '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jul 11, 2006, at 12:11 PM, Michael Smith wrote: Read(2) will block if there is no data so there's no need to sleep. Using select(2) is one way to go about it but with only one file descriptor/socket, it seems pointless to me. Shouldn't that return -1 or 0? -- Steve Checkoway _______________________________________________ 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 On Jul 11, 2006, at 12:04 PM, darwin-dev-request(a)lists.apple.com wrote: Select(2) makes timeout handling (mandatory for disconnectable devices such as those attached by USB or serial interfaces) much simpler. I note in your example that you don't test for ret == 0, which in the case of a blocking read means that if the fd is closed for some reason (e.g. the device is destroyed due to removal) you will spin forever. You're right. That's what happens when I write code in mail right after waking up. =) IMO, select with a non-blocking fd is a much cleaner way to implement this; it also has the advantage of making additions to the code over time much simpler, as it's an architectural stepping stone to a state-machine. I agree with the latter statement. For the former, I'm not sure. It tends to lead to a long while loop consisting of checking if you can read from each of the fds, reading from them, handling whatever that was supposed to do, then doing the same for writing. When dealing with multiple streams, this is the way to go. If there is only one and will only ever be one, I think it's the wrong way to go unless it's required for the timeout handling. smime.p7s

1 0

Re: How to do a blocking read from a serial device?
by Steve Checkoway 11 Jul '06

11 Jul '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com unsigned char buffer[15]; size_t len = 0; int fd = /* something to get your descriptor */ do { ssize_t ret = read( fd, &buffer[0] + len, sizeof(buffer) - len ); if( ret == -1 ) break; len += ret; } while( len < sizeof(buffer) ); Now you've read len bytes of data. -- Steve Checkoway _______________________________________________ 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 On Jul 10, 2006, at 10:34 AM, Sean McBride wrote: The read() man page says "The system guarantees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of-file, but in no other case." Indeed with my serial device, if I say to read 15 bytes it sometimes returns after reading 10 bytes. Is there anyway to have read() block until the requested length is ready? Is my only other choice some kind of loop that calls read() and usleep() over and over? If so, how do I choose a sleep duration? Read(2) will block if there is no data so there's no need to sleep. Using select(2) is one way to go about it but with only one file descriptor/socket, it seems pointless to me. smime.p7s

1 0

Re: How to do a blocking read from a serial device?
by Michael Smith 11 Jul '06

11 Jul '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jul 10, 2006, at 12:02 PM, darwin-dev-request(a)lists.apple.com wrote: Welcome to Unix. Please see the select(2) manpage, and Have a Nice Day! = Mike _______________________________________________ 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 writing some code to work with an RS-232 serial device (via USB adapter). It basically works. All the IOKit parts are fine, and I end up with a file descriptor and then use the posix read() and write() APIs. The read() man page says "The system guarantees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of-file, but in no other case." Indeed with my serial device, if I say to read 15 bytes it sometimes returns after reading 10 bytes. Is there anyway to have read() block until the requested length is ready? Is my only other choice some kind of loop that calls read() and usleep() over and over? If so, how do I choose a sleep duration? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Resolving a Mach-O symbol address into a variable address at runtime
by Damien Sorresso 11 Jul '06

11 Jul '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com void *mainHandle = dlopen(NULL, RTLD_LAZY); if( !mainHandle ) { printf("dlopen() failed.\n"); } int *debug_addr = (int *)dlsym(mainHandle, "__debug_level"); printf("debug_addr = 0x%x->0x%x\n", debug_addr, *debug_addr); dlclose(mainHandle); -- Damien Sorresso Macintosh Developer Computer Infrastructure Support Services Illinois State University damien.sorresso(a)ilstu.edu I've got a loadable bundle in a Cocoa application, and I'd like this bundle to grab the value of a global symbol from the main application after it's been loaded, specifically a global debugging level. Now, I can grab the symbol's address using nlist(...), but I want to in turn take this address and find the location of the variable in memory at runtime. I've already tried CFBundleGetDataPointerForName (...); it doesn't work. Don't ask me why. I've been pouring over the Mach-O documentation, and I'm thinking that the best way to go about it would be to grab the `vmaddr' member of the `segment_command' structure to determine the VM address of the __DATA segment and then work from there, but I'm not sure how to specifically go about doing this. Use dlopen/dlsym, see the manpages. _______________________________________________ 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 dlsym(...) gives me the information I already have: the symbol address in the Mach-O file. I need the address of the variable the symbol corresponds to at runtime. Or am I doing something wrong here? This is what I'm doing. On 11 Jul, 2006, at 10:52 AM, Peter O'Gorman wrote: On Tue, 2006-07-11 at 10:34 -0500, Damien Sorresso wrote: Peter smime.p7s PGP.sig

1 0

Re: Resolving a Mach-O symbol address into a variable address at runtime
by Peter O'Gorman 11 Jul '06

11 Jul '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Tue, 2006-07-11 at 10:34 -0500, Damien Sorresso wrote: > I've got a loadable bundle in a Cocoa application, and I'd like this > bundle to grab the value of a global symbol from the main application > after it's been loaded, specifically a global debugging level. > > Now, I can grab the symbol's address using nlist(...), but I want to > in turn take this address and find the location of the variable in > memory at runtime. I've already tried CFBundleGetDataPointerForName > (...); it doesn't work. Don't ask me why. I've been pouring over the > Mach-O documentation, and I'm thinking that the best way to go about > it would be to grab the `vmaddr' member of the `segment_command' > structure to determine the VM address of the __DATA segment and then > work from there, but I'm not sure how to specifically go about doing > this. Use dlopen/dlsym, see the manpages. Peter _______________________________________________ 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 signature.asc

1 0

Resolving a Mach-O symbol address into a variable address at runtime
by Damien Sorresso 11 Jul '06

11 Jul '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Damien Sorresso Macintosh Developer Computer Infrastructure Support Services Illinois State University damien.sorresso(a)ilstu.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 I've got a loadable bundle in a Cocoa application, and I'd like this bundle to grab the value of a global symbol from the main application after it's been loaded, specifically a global debugging level. Now, I can grab the symbol's address using nlist(...), but I want to in turn take this address and find the location of the variable in memory at runtime. I've already tried CFBundleGetDataPointerForName (...); it doesn't work. Don't ask me why. I've been pouring over the Mach-O documentation, and I'm thinking that the best way to go about it would be to grab the `vmaddr' member of the `segment_command' structure to determine the VM address of the __DATA segment and then work from there, but I'm not sure how to specifically go about doing this. -- smime.p7s

1 0