Mac OS-X 10.5 and "two icons bouncing in the dock" problem
[Probably, this is the wrong list, but launchd is definitely involved; Any pointer to more appropriate lists are welcome] Hi, attached PyQt script demonstrates an ugly issue, I'm fighting with since a couple of days :-(. Issue: when starting the app via double click or single click on dock icon or dropping a plain/text file on dock or application icon, all actions lead to two bouncing icons. The one with the blue spot is the good one, that stops bouncing after start-up. The bad one will stop bouncing eventually, and shows "Application not responding" in its context menu then. As long as the bad one exists, dropping files on the good one will be ignored. After killing (and sometimes removing from the dock is necessary) all is well - one can drop files one the good one and on the app icon, all behaves well, up to the point of being terminated, then this ugly game starts again. The issue is not depending on the arch, but on OS-X 10.5. It does not happen with 10.4. It may be related to pyinstaller, but since I need to deploy the app on arbitrary 10.4 and later systems, omitting it is not an option. Termination of this process is accompanied with these syslog messages: Aug 13 19:01:26 g5 com.apple.launchd[124] ([0x0-0x130130]..local.LaunchProb[9611]): Stray process with PGID equal to this dead job: PID 9612 PPID 1 LaunchProb Aug 13 19:01:26 g5 com.apple.launchd[124] ([0x0-0x130130]..local.LaunchProb[9611]): Exited: Terminated BTW: pyinstaller does a fork in start up, see pyinstaller/source/linux/main.c around line 120; #ifdef __APPLE__ /* add workpath to DYLD_LIBRARY_PATH */ exportWorkpath(workpath, "DYLD_LIBRARY_PATH"); #endif pid = fork(); if (pid == 0) execvp(thisfile, argv); wait(&rc); rc = WEXITSTATUS(rc); VS("Back to parent...\n"); if (strcmp(workpath, homepath) != 0) clear(workpath); It seems to be the culprit, what what could be done to get this working nicely with 10.5, too? Should I set the same pgid on both processes? Any pointer to examples? Pre conditions: OS-X 10.5(.7/.8) with ppc or x86 arch Xcode 3.1.3 Python-2.6.2 Qt-4.5.2 sip-4.8.2 PyQt-4.5.4 Build it this way: tar xvzf launchprob.tar.gz && cd launchprob && ./build.sh -debug This command will fetch pyinstaller's SVN trunk, build pyinstaller, generate the app itself: LaunchProb.app. It can be moved to any system, as long as all required packages are cleanly built for both archs(*) and the minimum OS-X release is 10.4. Any ideas how to solve this issue are greatly appreciated. Thanks, Pete (*) I can provide more details for this on request
On Aug 14, 2009, at 1:31 AM, Hans-Peter Jansen wrote:
[Probably, this is the wrong list, but launchd is definitely involved; Any pointer to more appropriate lists are welcome]
Hi,
attached PyQt script demonstrates an ugly issue, I'm fighting with since a couple of days :-(.
Issue: when starting the app via double click or single click on dock icon or dropping a plain/text file on dock or application icon, all actions lead to two bouncing icons.
The one with the blue spot is the good one, that stops bouncing after start-up. The bad one will stop bouncing eventually, and shows "Application not responding" in its context menu then. As long as the bad one exists, dropping files on the good one will be ignored. After killing (and sometimes removing from the dock is necessary) all is well - one can drop files one the good one and on the app icon, all behaves well, up to the point of being terminated, then this ugly game starts again.
The issue is not depending on the arch, but on OS-X 10.5. It does not happen with 10.4. It may be related to pyinstaller, but since I need to deploy the app on arbitrary 10.4 and later systems, omitting it is not an option.
Termination of this process is accompanied with these syslog messages: Aug 13 19:01:26 g5 com.apple.launchd[124] ([0x0-0x130130]..local.LaunchProb[9611]): Stray process with PGID equal to this dead job: PID 9612 PPID 1 LaunchProb Aug 13 19:01:26 g5 com.apple.launchd[124] ([0x0-0x130130]..local.LaunchProb[9611]): Exited: Terminated
BTW: pyinstaller does a fork in start up, see pyinstaller/source/linux/main.c around line 120;
#ifdef __APPLE__ /* add workpath to DYLD_LIBRARY_PATH */ exportWorkpath(workpath, "DYLD_LIBRARY_PATH"); #endif pid = fork(); if (pid == 0) execvp(thisfile, argv); wait(&rc); rc = WEXITSTATUS(rc);
VS("Back to parent...\n"); if (strcmp(workpath, homepath) != 0) clear(workpath);
It seems to be the culprit, what what could be done to get this working nicely with 10.5, too? Should I set the same pgid on both processes? Any pointer to examples?
Pre conditions: OS-X 10.5(.7/.8) with ppc or x86 arch Xcode 3.1.3 Python-2.6.2 Qt-4.5.2 sip-4.8.2 PyQt-4.5.4
Build it this way:
tar xvzf launchprob.tar.gz && cd launchprob && ./build.sh -debug
This command will fetch pyinstaller's SVN trunk, build pyinstaller, generate the app itself: LaunchProb.app. It can be moved to any system, as long as all required packages are cleanly built for both archs(*) and the minimum OS-X release is 10.4.
Any ideas how to solve this issue are greatly appreciated.
Thanks, Pete
(*) I can provide more details for this on request
Why is it fork(2)ing and then exiting right away? This really isn't a supported way to build applications on Mac OS X. Please use Xcode. -- Damien Sorresso BSD Engineering Apple Inc.
Am Freitag, 14. August 2009 schrieb Damien Sorresso:
On Aug 14, 2009, at 1:31 AM, Hans-Peter Jansen wrote:
[Probably, this is the wrong list, but launchd is definitely involved; Any pointer to more appropriate lists are welcome]
Hi,
attached PyQt script demonstrates an ugly issue, I'm fighting with since a couple of days :-(.
Issue: when starting the app via double click or single click on dock icon or dropping a plain/text file on dock or application icon, all actions lead to two bouncing icons.
The one with the blue spot is the good one, that stops bouncing after start-up. The bad one will stop bouncing eventually, and shows "Application not responding" in its context menu then. As long as the bad one exists, dropping files on the good one will be ignored. After killing (and sometimes removing from the dock is necessary) all is well - one can drop files one the good one and on the app icon, all behaves well, up to the point of being terminated, then this ugly game starts again.
The issue is not depending on the arch, but on OS-X 10.5. It does not happen with 10.4. It may be related to pyinstaller, but since I need to deploy the app on arbitrary 10.4 and later systems, omitting it is not an option.
Termination of this process is accompanied with these syslog messages: Aug 13 19:01:26 g5 com.apple.launchd[124] ([0x0-0x130130]..local.LaunchProb[9611]): Stray process with PGID equal to this dead job: PID 9612 PPID 1 LaunchProb Aug 13 19:01:26 g5 com.apple.launchd[124] ([0x0-0x130130]..local.LaunchProb[9611]): Exited: Terminated
BTW: pyinstaller does a fork in start up, see pyinstaller/source/linux/main.c around line 120;
#ifdef __APPLE__ /* add workpath to DYLD_LIBRARY_PATH */ exportWorkpath(workpath, "DYLD_LIBRARY_PATH"); #endif pid = fork(); if (pid == 0) execvp(thisfile, argv); wait(&rc); rc = WEXITSTATUS(rc);
VS("Back to parent...\n"); if (strcmp(workpath, homepath) != 0) clear(workpath);
It seems to be the culprit, what what could be done to get this working nicely with 10.5, too? Should I set the same pgid on both processes? Any pointer to examples?
Pre conditions: OS-X 10.5(.7/.8) with ppc or x86 arch Xcode 3.1.3 Python-2.6.2 Qt-4.5.2 sip-4.8.2 PyQt-4.5.4
Build it this way:
tar xvzf launchprob.tar.gz && cd launchprob && ./build.sh -debug
This command will fetch pyinstaller's SVN trunk, build pyinstaller, generate the app itself: LaunchProb.app. It can be moved to any system, as long as all required packages are cleanly built for both archs(*) and the minimum OS-X release is 10.4.
Any ideas how to solve this issue are greatly appreciated.
Thanks, Pete
(*) I can provide more details for this on request
Why is it fork(2)ing and then exiting right away? This really isn't a supported way to build applications on Mac OS X. Please use Xcode.
Damien, yes, this looks fishy, and I eliminated the fork completely already. Unfortunately, it doesn't change its behavior. If you have any more ideas, let me know. Anyway, thanks. Pete
At 23:21 +0200 14/8/09, Hans-Peter Jansen wrote:
Damien, yes, this looks fishy, and I eliminated the fork completely already. Unfortunately, it doesn't change its behavior.
Either you didn't eliminate the fork, or there is more than one fork happening and you've only eliminated one of them. The symptom you're seeing (two icons in the dock) only occurs when two different processes both check in to the application-level process management system. In situations like this I find the following DTrace script to be useful. It shows you exactly which processes get launched, with enough information to work out their parent/child relationships. IMPORTANT: Sort the output by the timestamp. On multi-core machines, DTrace can report things out of order. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware #! /usr/sbin/dtrace -q -s /* File: QProcSnoop.d Contains: Logs process start and stop. Written by: DTS Copyright: Copyright (c) 2008 Apple Inc. All Rights Reserved. Disclaimer: IMPORTANT: This Apple software is supplied to you by Apple Inc. ("Apple") in consideration of your agreement to the following terms, and your use, installation, modification or redistribution of this Apple software constitutes acceptance of these terms. If you do not agree with these terms, please do not use, install, modify or redistribute this Apple software. In consideration of your agreement to abide by the following terms, and subject to these terms, Apple grants you a personal, non-exclusive license, under Apple's copyrights in this original Apple software (the "Apple Software"), to use, reproduce, modify and redistribute the Apple Software, with or without modifications, in source and/or binary forms; provided that if you redistribute the Apple Software in its entirety and without modifications, you must retain this notice and the following text and disclaimers in all such redistributions of the Apple Software. Neither the name, trademarks, service marks or logos of Apple Inc. may be used to endorse or promote products derived from the Apple Software without specific prior written permission from Apple. Except as expressly stated in this notice, no other rights or licenses, express or implied, are granted by Apple herein, including but not limited to any patent rights that may be infringed by your derivative works or by other works in which the Apple Software may be incorporated. The Apple Software is provided by Apple on an "AS IS" basis. APPLE MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, REGARDING THE APPLE SOFTWARE OR ITS USE AND OPERATION ALONE OR IN COMBINATION WITH YOUR PRODUCTS. IN NO EVENT SHALL APPLE BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) ARISING IN ANY WAY OUT OF THE USE, REPRODUCTION, MODIFICATION AND/OR DISTRIBUTION OF THE APPLE SOFTWARE, HOWEVER CAUSED AND WHETHER UNDER THEORY OF CONTRACT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY OR OTHERWISE, EVEN IF APPLE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ /* IMPORTANT: To get an accurate timeline of events, you must sort the output of this script by the leading timestamp. Without this some event will be displayed out of order on machines with more than one core (due to the way DTrace is implemented within the kernel). */ /* ***** fork/vfork/spawn ***** */ /* Check for the successful case. */ proc:::create { printf("%u %20s %5d fork %d\n", timestamp, execname, pid, args[0]->pr_pid); } /* Check for the unsuccessful case. */ syscall::fork:return, syscall::vfork:return, syscall::posix_spawn:return / arg0 < 0 / { printf("%u %20s %5d %s FAILED %d\n", timestamp, execname, pid, probefunc, errno); } /* ***** exec ***** */ /* This is a pretty standard sequence for capture execs that allows us to show the old and new names of the process. */ proc:::exec { self->oldName = execname; self->newName = args[0]; } proc:::exec-success / self->oldName != 0 / { printf("%u %20s %5d exec %s\n", timestamp, self->oldName, pid, self->newName); self->oldName = 0; self->newName = 0; } proc:::exec-failure / self->oldName != 0 / { printf("%u %20s %5d exec %s FAILED %d\n", timestamp, self->oldName, pid, self->newName, arg0); self->oldName = 0; self->newName = 0; } /* ***** exit ***** */ /* proc_exit doesn't get the exit status as an argument (it's argument is always CLD_EXITED == 1 on Mac OS X). So we capture the exit status by watching for the process calling exit. We communicate that to the proc_exit by way of gExitStatus. This ensures that we only print a single line of exit information. We need gExitStatusValid because an exit status of 0 is valid. */ int gExitStatusValid[int]; int gExitStatus[int]; syscall::exit:entry { gExitStatusValid[pid] = 1; gExitStatus[pid] = arg0; } proc:::exit / gExitStatusValid[pid] == 0 / { printf("%u %20s %5d exit ?\n", timestamp, execname, pid); } proc:::exit / gExitStatusValid[pid] != 0 / { printf("%u %20s %5d exit %d\n", timestamp, execname, pid, gExitStatus[pid]); gExitStatusValid[pid] = 0; gExitStatus[pid] = 0; }
Dear Quinn, that was the first really useful reply I got, thank you very much. Am Montag, 17. August 2009 schrieb Quinn:
At 23:21 +0200 14/8/09, Hans-Peter Jansen wrote:
Damien, yes, this looks fishy, and I eliminated the fork completely already. Unfortunately, it doesn't change its behavior.
Either you didn't eliminate the fork, or there is more than one fork happening and you've only eliminated one of them. The symptom you're seeing (two icons in the dock) only occurs when two different processes both check in to the application-level process management system.
You are right - while I did eliminate the fork, I tested a wrong build. Oh well... What I don't understand is, how both processes could check into process management? The code in question should lead to one process waiting for the "main" process finishing. The reason is because pyinstaller does have another build mode, where everything is included in one file. That's being expanded to a temporary folder on runtime, and the fork is necessary to being able to clean up afterwards. That mode isn't useful on the Mac anyway, thus we're not loosing much ;-)..
In situations like this I find the following DTrace script to be useful. It shows you exactly which processes get launched, with enough information to work out their parent/child relationships.
Now that's just great. I'm sure, I will find opportunities, where this will prove usefulness. Thanks.
IMPORTANT: Sort the output by the timestamp. On multi-core machines, DTrace can report things out of order.
S+E
Thanks again, Pete
At 17:46 +0200 17/8/09, Hans-Peter Jansen wrote:
Oh well... What I don't understand is, how both processes could check into process management?
This may tell you... <http://developer.apple.com/technotes/tn2004/tn2124.html#SECPROCESSMANAGER> S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
participants (3)
-
Damien Sorresso
-
Hans-Peter Jansen
-
Quinn