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

Re: pthread_cancel and C++ destructors
by Terry Lambert 30 Nov '07

30 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com It always helps to have more test cases. -- 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 Nov 29, 2007, at 8:45 PM, Ethan Tira-Thompson wrote: Any suggestions where best to complain about the cancel point issue? I have no illusion this hack I'm using is horribly unsafe — essentially I'm just recreating PTHREAD_CANCEL_ASYNCHRONOUS, which means my thread could just stop executing at any time. <http://bugreport.apple.com>, same place Per complained about this same issue last week. This email sent to site_archiver(a)lists.apple.com

1 0

Re: pthread_cancel and C++ destructors
by Ethan Tira-Thompson 30 Nov '07

30 Nov '07

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 pthread-tests.zip

1 0

Re: pthread_mutex_unlock not permitted in signal handler?
by Ethan Tira-Thompson 30 Nov '07

30 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com thanks, -ethan _______________________________________________ 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… However, when I try to call pthread_mutex_unlock from the cleanup function that results from the eventual pthread_testcancel, it returns an error "Operation not permitted". Sigh... I have to take this back — testing in a simplified piece of test code does seem to work on both 10.4 and 10.5. So I'm not sure what's going on there with my "real" code. Is there any particular reason you don't do the semi-standard unix method of using select() or equivalent on your socket together with a pipe, and then write a byte to the other end of the pipe from whoever wanted to stop the thread in the first place? No messing with signals needed. Unfortunately, I'm given an std::iostream for the input, so I can't select on that :( I suppose things could be re-engineered to pass a file descriptor (or hacked to extract the file descriptor from the iostream), but that doesn't solve the general problem for other blocking system calls which aren't socket based (e.g. wait, sigwait, pthread_join, etc) I did realize however, that read() has a EINTR error return code, so instead of trying to unlock within the signal handler itself, perhaps I could just make the handler a no-op, and then test for the error code following the read(). However, in its infinite wisdom, the system resumes the read and doesn't bat an eye at the signal coming and going, so this idea never actually interrupts the read(), nor causes the unlock and exit to occur. I've been doing some more testing and will reply to myself in my original thread with some updates/summary... This email sent to site_archiver(a)lists.apple.com

1 0

Re: pthread_mutex_unlock not permitted in signal handler?
by Lassi Tuura 29 Nov '07

29 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, Lassi _______________________________________________ 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… Is it *at all possible* to unlock a mutex following the interruption of a thread on Tiger? (I haven't tried this on Leopard yet -- since I don't need to do the signal hack there, hopefully this is moot) Basically, I'm reading from a socket, and need a way to kill the thread if there's no response. But I also need to maintain a lock on the socket while I'm waiting for a response so other tasks don't try to send their own queries. I'm polling relatively frequently, so I don't want to have to take the lock, launch a new thread, and monitor the other thread every time. (this is a real-time task with a hardware device) Is there any particular reason you don't do the semi-standard unix method of using select() or equivalent on your socket together with a pipe, and then write a byte to the other end of the pipe from whoever wanted to stop the thread in the first place? No messing with signals needed. On a related note, don't use pthread_mutex_* from a signal handler if you use the same mutex outside signals in the same thread. You may not be allowed to enter pthread_mutex_* twice in the same thread, even if the mutex is recursive. Let's say the socket reader quits at just the right time and enters pthread_mutex_*, and just then your signal arrives, and also attempts to execute pthread_mutex_*. Now your program would have entered the mutex twice in the same thread. On some systems this results in a failure or a dead-lock. This email sent to site_archiver(a)lists.apple.com

1 0

pthread_mutex_unlock not permitted in signal handler?
by Ethan Tira-Thompson 29 Nov '07

29 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thoughts? thanks -ethan _______________________________________________ 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… In trying to find a workaround to my previous message (destructors not being called on pthread_cancel), In this case, I have a set of pthread_cleanup statements which trigger a call to pthread_mutex_unlock on cancellation. The trick is that on Tiger (Darwin 8.11.1), since I can't cancel out of a read()/sleep()/etc., I use a pthread_kill() to send a signal, and then the signal handler does pthread_testcancel(). Ugly as it is, this much has been working for a while now. However, when I try to call pthread_mutex_unlock from the cleanup function that results from the eventual pthread_testcancel, it returns an error "Operation not permitted". Is it *at all possible* to unlock a mutex following the interruption of a thread on Tiger? (I haven't tried this on Leopard yet -- since I don't need to do the signal hack there, hopefully this is moot) Basically, I'm reading from a socket, and need a way to kill the thread if there's no response. But I also need to maintain a lock on the socket while I'm waiting for a response so other tasks don't try to send their own queries. I'm polling relatively frequently, so I don't want to have to take the lock, launch a new thread, and monitor the other thread every time. (this is a real-time task with a hardware device) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Missing libstdc++.dylib symbolic link in 10.4u SDK
by Terry Lambert 29 Nov '07

29 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com If that doesn't help, then <http://bugreporte.apple.com>. -- 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 Nov 29, 2007, at 11:18 AM, Pierre Baillargeon wrote: I'm doing development work on 10.5 using the 10.4u SDK (/Developer/ SDKs/MacOSX10.4u.sdk) and I've come accross a problem where the linker tries to link with libstdc++.dylib (which should be under usr/ lib/gcc/i686-apple-darwin9/4.0.1, under the SDK) but that symbolic link is missing. I've checked on a 10.4 system, and under the /usr/...etc.../4.0.1/ there is indeed a symbolic link back to the proper dylib three levels up. Is this an oversight? I've fixed the problem temporarily by creating the symlink by hand, but it's annoying to have to hack an SDK. I think you broke something on your machine; this works for me (it's a copy, not a symlink on my machine). Are you sure you installed cross-compilation for older versions when you installed XCode? This email sent to site_archiver(a)lists.apple.com

1 0

Leo prebinding...
by Jeshua Lacock 29 Nov '07

29 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Greetings, ...on the 10.5 system, and does not hang on the same message on 10.4. Thanks, Jeshua Lacock, Owner <http://OpenOSX.com> phone: 877.240.1364 _______________________________________________ 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… Our build of AbiWord launches in about 2 seconds on Mac OS X 10.4, while it takes about 60 seconds on Mac OS X 10.5 (on the same machine), with similar results for our other applications built on the same GNOME stack including Gnumeric, Gnucash, etc. I set the "DYLD_PREBIND_DEBUG" variable, and the same list of files stating the image is not prebound is presented on both systems. The only difference is that it hangs on the message: dyld: image not prebound, so could not use prebinding in /tmp/ OpenOSX/office/bin/AbiWord-2.4 Can any recommend something to try or point me towards some documentation? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Compile in Leopard, use in Tiger (again)
by Pierre Baillargeon 29 Nov '07

29 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I'm also using the intel compiler. Here's what I've found: 1. Define the proper symbols to use the proper functions: -DMAC_OS_X_VERSION_MAX_ALLOWED=1040 -DMAC_OS_X_VERSION_MIN_REQUIRED=1040 -D__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__=1040 2. Tell the compiler top use the proper SDK framework: -F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks 3. Tell the linker to use the proper SDK: -Wl,-syslibroot -Wl,/Developer/SDKs/MacOSX10.4u.sdk/ -- Pierre Baillargeon _______________________________________________ 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… That should set you on course. I've had other problem with the generated object files crashing on load due to bad init function pointers, but that is a different thing... This email sent to site_archiver(a)lists.apple.com

1 0

Missing libstdc++.dylib symbolic link in 10.4u SDK
by Pierre Baillargeon 29 Nov '07

29 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -- Pierre Baillargeon _______________________________________________ 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'm doing development work on 10.5 using the 10.4u SDK (/Developer/ SDKs/MacOSX10.4u.sdk) and I've come accross a problem where the linker tries to link with libstdc++.dylib (which should be under usr/lib/gcc/ i686-apple-darwin9/4.0.1, under the SDK) but that symbolic link is missing. I've checked on a 10.4 system, and under the /usr/...etc.../4.0.1/ there is indeed a symbolic link back to the proper dylib three levels up. Is this an oversight? I've fixed the problem temporarily by creating the symlink by hand, but it's annoying to have to hack an SDK. This email sent to site_archiver(a)lists.apple.com

1 0

Crash in loader due to bad initialization functions pointers
by Pierre Baillargeon 29 Nov '07

29 Nov '07

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Is this known? Is there a work-around? -- Pierre Baillargeon _______________________________________________ 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… 'm doing development work on Leopard (10.5) using the Intel C++ compiler and I've come accross the following problem when building dynamic library (dylib): The loader (dyld) crashes at runtime when starting a test program suign the built dylib when it runs initialization function for static variables, in ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int). I've been able to diagnose the problem by using a combination of DYLD_PRINT_INITIALIZERS and otool -s __DATA __mod_init_func. The problem is that this dylib section contains pointers that are invalid (Usually things like 0x4d000000 or 0x75000000). Now it might very well be the intel compiler that is causing the problem, but the same compiler on 10.4 works. I suspect a bad interaction between the linker (ld) and the object files generated by the Intel compiler. (I've try as a last-ditch effort to use the 10.4 ld on 10.5, but the format of the system libraries changed (there are new section types) so the 10.4 ld cannot be used on 10.5.) This email sent to site_archiver(a)lists.apple.com

1 0