Mac OS-X 10.5 and "two icons bouncing in the dock" problem

[Hans-Peter Jansen-2]

[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


_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[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 Sorresso
BSD Engineering
Apple Inc.



_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Hans-Peter Jansen-2]

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
_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Quinn-9]

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;
}
_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Hans-Peter Jansen-2]

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


_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Quinn-9]

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
_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev