Am Donnerstag, 13. August 2009 schrieb Hans-Peter Jansen: > Dear Giovanni, > > Am Donnerstag, 13. August 2009 schrieb Hans-Peter Jansen: > > [Sorry for cross-posting] > > > > Hi, > > > > attached script demonstrates an ugly issue, I'm fighting with since a > > couple of days. > > > > Issue: > > when starting the app via double click, single click on dock icon, > > dropping a plain/text file on dock or application icon, all actions > > lead to two icons bouncing. 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 it > > behaves well, up to the point of being terminated, then the game starts > > again. > > > > It's not depending on the arch, but on OS-X 10.5. It does not happen > > with 10.4. It is 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. > > I think, this issue is due to this fork: > pid = fork(); > if (pid == 0) > execvp(thisfile, argv); > wait(&rc); > > Since termination of the bad 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 > > I suppose, it's due to the fork. Could you briefly explain, why this > fork() is necessary, since it forks into the same binary already running. > > Thanks, > Pete
Update: No, it's not the fork, since disabling it with a patch similar to the attached one does produce the exact same behavior. Giovanni, the question about the necessity of this fork persists. Would you be so kind to elaborate on this a bit, please? BTW, the same test script with py2app does behave properly(*), thus it's definitely an pyinstaller issue. Since I would like to stay with pyinstaller, this issue needs to be resolved. I will try as hard as I can, but any help is much appreciated. Thanks, Pete *: tar xvzf launchprob-py2app.tar.gz && cd launchprob-py2app && ./build.sh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "PyInstaller" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/PyInstaller?hl=en -~----------~----~----~----~------~----~------~--~---
--- pyinstaller/source/common/launch.c~ 2009-08-13 12:00:56.341840092 +0200
+++ pyinstaller/source/common/launch.c 2009-08-14 14:27:30.949838842 +0200
@@ -1039,7 +1039,7 @@ int runScripts()
PI_PyObject_SetAttrString(__main__, "__file__", __file__);
Py_DECREF(__file__);
/* Run it */
- rc = PI_PyRun_SimpleString(data);
+ rc = PI_PyRun_SimpleString((char *)data);
/* log errors and abort */
if (rc != 0) {
VS("RC: %d from %s\n", rc, ptoc->name);
--- pyinstaller/source/linux/main.c~ 2009-08-13 12:00:55.769843197 +0200
+++ pyinstaller/source/linux/main.c 2009-08-14 23:15:38.853870358 +0200
@@ -120,12 +120,14 @@ int main(int argc, char* argv[])
#ifdef __APPLE__
/* add workpath to DYLD_LIBRARY_PATH */
exportWorkpath(workpath, "DYLD_LIBRARY_PATH");
-#endif
+ rc = doIt(argc, argv);
+#else
pid = fork();
if (pid == 0)
execvp(thisfile, argv);
wait(&rc);
rc = WEXITSTATUS(rc);
+#endif
VS("Back to parent...\n");
if (strcmp(workpath, homepath) != 0)
launchprob-py2app.tar.gz
Description: application/tgz
