Hello
I have spent a bit of time with gdb and pd latest cvs, and I can now report that the problem with fork() and exec'ing causing CoreFoundation errors in mac os x is not, as Miller suspected, in t_tkcmd.c (circa line 423), but actually in s_inter.c, beginning line 1013, where:
#ifdef UNISTD childpid = fork();
...is called but execl() is not called until 1103.
I can't quite tell why it's complaining (since we -do- call execl), but of course there is a whole lot of sprintf going on between the two, so...
Any suggestions, anyone?
David
On 25 Jan 2008, at 09:44, David Plans Casal wrote:
On 18 Jan 2008, at 17:55, Miller Puckette wrote:
ouch. The offending code is probably between the fork and exec in t_tkcmd.c (circa line 423). The only function call between them is a sprintf, wouldn't you know. Perhaps it will fix the problem if I do the sprintf before forking? I don't have 10.5.1 to test this on, so if it's easy for you to try that, I'd be grateful.
Moving this thread to pd-dev, as I guess it belongs there.
David
cheers Miller
On Fri, Jan 18, 2008 at 05:28:20PM +0000, David Plans Casal wrote:
Hey
Has anyone noticed yet that trying to build CVS version on 10.5.1 and running gives:
18/01/2008 11:23:23 [0x0-0x96096].org.puredata[17406] The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). 18/01/2008 11:23:23 [0x0-0x96096].org.puredata[17406] Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ () to debug.
Then pd crashes after about 5 minutes.
Actually, pd-extended seems to crash also, as well as Miller releases (stable and test).
Anyone else?
David
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
David Plans Casal wrote:
I can't quite tell why it's complaining (since we -do- call execl), but of course there is a whole lot of sprintf going on between the two, so...
It's extremely unlikely that any of the string handling is the problem. However, there are also a bunch of calls to stat() as well as a call to seteuid() which are more likely.
Any suggestions, anyone?
Try the attached patch to see if moving building the sys_guicmd to before the fork fixes it. If it doesn't, try commenting out the call to seteuid(). Between those two, you should be able to find out what it's complaining about.
On a sidenote, the string handling here is not safe. It will crash if the path to your home directory is a lot longer than usual ...
-- Russell Bryant
Index: s_inter.c =================================================================== RCS file: /cvsroot/pure-data/pd/src/s_inter.c,v retrieving revision 1.22 diff -u -r1.22 s_inter.c --- s_inter.c 16 Jan 2008 21:54:11 -0000 1.22 +++ s_inter.c 1 Feb 2008 14:43:37 -0000 @@ -1018,6 +1018,73 @@
#ifdef UNISTD + if (!sys_guicmd) { +#ifdef __APPLE__ + char *homedir = getenv("HOME"), filename[250]; + struct stat statbuf; + /* first look for Wish bundled with and renamed "Pd" */ + sprintf(filename, "%s/../../MacOS/Pd", guidir); + if (stat(filename, &statbuf) >= 0) + goto foundit; + if (!homedir || strlen(homedir) > 150) + goto nohomedir; + /* Look for Wish in user's Applications. Might or might + not be names "Wish Shell", and might or might not be + in "Utilities" subdir. */ + sprintf(filename, + "%s/Applications/Utilities/Wish shell.app/Contents/MacOS/Wish Shell", + homedir); + if (stat(filename, &statbuf) >= 0) + goto foundit; + sprintf(filename, + "%s/Applications/Utilities/Wish.app/Contents/MacOS/Wish", + homedir); + if (stat(filename, &statbuf) >= 0) + goto foundit; + sprintf(filename, + "%s/Applications/Wish shell.app/Contents/MacOS/Wish Shell", + homedir); + if (stat(filename, &statbuf) >= 0) + goto foundit; + sprintf(filename, + "%s/Applications/Wish.app/Contents/MacOS/Wish", + homedir); + if (stat(filename, &statbuf) >= 0) + goto foundit; + nohomedir: + /* Perform the same search among system applications. */ + strcpy(filename, + "/usr/bin/wish"); + if (stat(filename, &statbuf) >= 0) + goto foundit; + strcpy(filename, + "/Applications/Utilities/Wish Shell.app/Contents/MacOS/Wish Shell"); + if (stat(filename, &statbuf) >= 0) + goto foundit; + strcpy(filename, + "/Applications/Utilities/Wish.app/Contents/MacOS/Wish"); + if (stat(filename, &statbuf) >= 0) + goto foundit; + strcpy(filename, + "/Applications/Wish Shell.app/Contents/MacOS/Wish Shell"); + if (stat(filename, &statbuf) >= 0) + goto foundit; + strcpy(filename, + "/Applications/Wish.app/Contents/MacOS/Wish"); + foundit: + sprintf(cmdbuf, ""%s" %s/pd.tk %d\n", filename, guidir, portno); +#else + sprintf(cmdbuf, + "TCL_LIBRARY="%s/tcl/library" TK_LIBRARY="%s/tk/library" \ + "%s/pd-gui" %d\n", + sys_libdir->s_name, sys_libdir->s_name, guidir, portno); +#endif + sys_guicmd = cmdbuf; + } + + if (sys_verbose) + fprintf(stderr, "%s", sys_guicmd); + childpid = fork(); if (childpid < 0) { @@ -1045,75 +1112,10 @@ } } #endif - if (!sys_guicmd) - { -#ifdef __APPLE__ - char *homedir = getenv("HOME"), filename[250]; - struct stat statbuf; - /* first look for Wish bundled with and renamed "Pd" */ - sprintf(filename, "%s/../../MacOS/Pd", guidir); - if (stat(filename, &statbuf) >= 0) - goto foundit; - if (!homedir || strlen(homedir) > 150) - goto nohomedir; - /* Look for Wish in user's Applications. Might or might - not be names "Wish Shell", and might or might not be - in "Utilities" subdir. */ - sprintf(filename, - "%s/Applications/Utilities/Wish shell.app/Contents/MacOS/Wish Shell", - homedir); - if (stat(filename, &statbuf) >= 0) - goto foundit; - sprintf(filename, - "%s/Applications/Utilities/Wish.app/Contents/MacOS/Wish", - homedir); - if (stat(filename, &statbuf) >= 0) - goto foundit; - sprintf(filename, - "%s/Applications/Wish shell.app/Contents/MacOS/Wish Shell", - homedir); - if (stat(filename, &statbuf) >= 0) - goto foundit; - sprintf(filename, - "%s/Applications/Wish.app/Contents/MacOS/Wish", - homedir); - if (stat(filename, &statbuf) >= 0) - goto foundit; - nohomedir: - /* Perform the same search among system applications. */ - strcpy(filename, - "/usr/bin/wish"); - if (stat(filename, &statbuf) >= 0) - goto foundit; - strcpy(filename, - "/Applications/Utilities/Wish Shell.app/Contents/MacOS/Wish Shell"); - if (stat(filename, &statbuf) >= 0) - goto foundit; - strcpy(filename, - "/Applications/Utilities/Wish.app/Contents/MacOS/Wish"); - if (stat(filename, &statbuf) >= 0) - goto foundit; - strcpy(filename, - "/Applications/Wish Shell.app/Contents/MacOS/Wish Shell"); - if (stat(filename, &statbuf) >= 0) - goto foundit; - strcpy(filename, - "/Applications/Wish.app/Contents/MacOS/Wish"); - foundit: - sprintf(cmdbuf, ""%s" %s/pd.tk %d\n", filename, guidir, portno); -#else - sprintf(cmdbuf, -"TCL_LIBRARY="%s/tcl/library" TK_LIBRARY="%s/tk/library" \ - "%s/pd-gui" %d\n", - sys_libdir->s_name, sys_libdir->s_name, guidir, portno); -#endif - sys_guicmd = cmdbuf; - } - if (sys_verbose) fprintf(stderr, "%s", sys_guicmd); execl("/bin/sh", "sh", "-c", sys_guicmd, (char*)0); perror("pd: exec"); _exit(1); - } + } #endif /* UNISTD */
#ifdef MSW
Aha, somehow I had persuaded myself that teh problem was when starting from the "App" (in which case Tcl/TK fork/execs pd) but now I gather it's when you start Pd from a shell so that it starts Tcl/Tk instead. I'll go try that and see if I can make it fail for me :)
M
On Fri, Feb 01, 2008 at 08:54:17AM -0600, Russell Bryant wrote:
David Plans Casal wrote:
I can't quite tell why it's complaining (since we -do- call execl), but of course there is a whole lot of sprintf going on between the two, so...
It's extremely unlikely that any of the string handling is the problem. However, there are also a bunch of calls to stat() as well as a call to seteuid() which are more likely.
Any suggestions, anyone?
Try the attached patch to see if moving building the sys_guicmd to before the fork fixes it. If it doesn't, try commenting out the call to seteuid(). Between those two, you should be able to find out what it's complaining about.
On a sidenote, the string handling here is not safe. It will crash if the path to your home directory is a lot longer than usual ...
-- Russell Bryant
Index: s_inter.c
RCS file: /cvsroot/pure-data/pd/src/s_inter.c,v retrieving revision 1.22 diff -u -r1.22 s_inter.c --- s_inter.c 16 Jan 2008 21:54:11 -0000 1.22 +++ s_inter.c 1 Feb 2008 14:43:37 -0000 @@ -1018,6 +1018,73 @@
#ifdef UNISTD
if (!sys_guicmd) {
+#ifdef __APPLE__
char *homedir = getenv("HOME"), filename[250];
struct stat statbuf;
/* first look for Wish bundled with and renamed "Pd" */
sprintf(filename, "%s/../../MacOS/Pd", guidir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
if (!homedir || strlen(homedir) > 150)
goto nohomedir;
/* Look for Wish in user's Applications. Might or might
not be names "Wish Shell", and might or might not be
in "Utilities" subdir. */
sprintf(filename,
"%s/Applications/Utilities/Wish shell.app/Contents/MacOS/Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Utilities/Wish.app/Contents/MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish shell.app/Contents/MacOS/Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish.app/Contents/MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
nohomedir:
/* Perform the same search among system applications. */
strcpy(filename,
"/usr/bin/wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish Shell.app/Contents/MacOS/Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish.app/Contents/MacOS/Wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish Shell.app/Contents/MacOS/Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish.app/Contents/MacOS/Wish");
foundit:
sprintf(cmdbuf, "\"%s\" %s/pd.tk %d\n", filename, guidir, portno);
+#else
sprintf(cmdbuf,
"TCL_LIBRARY=\"%s/tcl/library\" TK_LIBRARY=\"%s/tk/library\" \
\"%s/pd-gui\" %d\n",
sys_libdir->s_name, sys_libdir->s_name, guidir, portno);
+#endif
sys_guicmd = cmdbuf;
}
if (sys_verbose)
fprintf(stderr, "%s", sys_guicmd);
childpid = fork(); if (childpid < 0) {
@@ -1045,75 +1112,10 @@ } } #endif
if (!sys_guicmd)
{
-#ifdef __APPLE__
char *homedir = getenv("HOME"), filename[250];
struct stat statbuf;
/* first look for Wish bundled with and renamed "Pd" */
sprintf(filename, "%s/../../MacOS/Pd", guidir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
if (!homedir || strlen(homedir) > 150)
goto nohomedir;
/* Look for Wish in user's Applications. Might or might
not be names "Wish Shell", and might or might not be
in "Utilities" subdir. */
sprintf(filename,
"%s/Applications/Utilities/Wish shell.app/Contents/MacOS/Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Utilities/Wish.app/Contents/MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish shell.app/Contents/MacOS/Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish.app/Contents/MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
nohomedir:
/* Perform the same search among system applications. */
strcpy(filename,
"/usr/bin/wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish Shell.app/Contents/MacOS/Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish.app/Contents/MacOS/Wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish Shell.app/Contents/MacOS/Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish.app/Contents/MacOS/Wish");
foundit:
sprintf(cmdbuf, "\"%s\" %s/pd.tk %d\n", filename, guidir, portno);
-#else
sprintf(cmdbuf,
-"TCL_LIBRARY="%s/tcl/library" TK_LIBRARY="%s/tk/library" \
- "%s/pd-gui" %d\n",
sys_libdir->s_name, sys_libdir->s_name, guidir, portno);
-#endif
sys_guicmd = cmdbuf;
}
if (sys_verbose) fprintf(stderr, "%s", sys_guicmd); execl("/bin/sh", "sh", "-c", sys_guicmd, (char*)0); perror("pd: exec"); _exit(1);
}
}
#endif /* UNISTD */
#ifdef MSW
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Just to confirm, this is happening for in app and terminal stars, I was using terminal because I was starting the process from within gdb...
Will try Russell's patch now and look at seteuid()
David Plans
On 1 Feb 2008, at 17:03, Miller Puckette wrote:
Aha, somehow I had persuaded myself that teh problem was when starting from the "App" (in which case Tcl/TK fork/execs pd) but now I gather it's when you start Pd from a shell so that it starts Tcl/Tk instead. I'll go try that and see if I can make it fail for me :)
M
On Fri, Feb 01, 2008 at 08:54:17AM -0600, Russell Bryant wrote:
David Plans Casal wrote:
I can't quite tell why it's complaining (since we -do- call execl), but of course there is a whole lot of sprintf going on between the two, so...
It's extremely unlikely that any of the string handling is the problem. However, there are also a bunch of calls to stat() as well as a call to seteuid() which are more likely.
Any suggestions, anyone?
Try the attached patch to see if moving building the sys_guicmd to before the fork fixes it. If it doesn't, try commenting out the call to seteuid(). Between those two, you should be able to find out what it's complaining about.
On a sidenote, the string handling here is not safe. It will crash if the path to your home directory is a lot longer than usual ...
-- Russell Bryant
Index: s_inter.c
RCS file: /cvsroot/pure-data/pd/src/s_inter.c,v retrieving revision 1.22 diff -u -r1.22 s_inter.c --- s_inter.c 16 Jan 2008 21:54:11 -0000 1.22 +++ s_inter.c 1 Feb 2008 14:43:37 -0000 @@ -1018,6 +1018,73 @@
#ifdef UNISTD
if (!sys_guicmd) {
+#ifdef __APPLE__
char *homedir = getenv("HOME"), filename[250];
struct stat statbuf;
/* first look for Wish bundled with and renamed
"Pd" */
sprintf(filename, "%s/../../MacOS/Pd", guidir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
if (!homedir || strlen(homedir) > 150)
goto nohomedir;
/* Look for Wish in user's Applications. Might or
might
not be names "Wish Shell", and might or might not be
in "Utilities" subdir. */
sprintf(filename,
"%s/Applications/Utilities/Wish shell.app/Contents/
MacOS/Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Utilities/Wish.app/Contents/MacOS/
Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish shell.app/Contents/MacOS/
Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish.app/Contents/MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
nohomedir:
/* Perform the same search among system
applications. */
strcpy(filename,
"/usr/bin/wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish Shell.app/Contents/
MacOS/Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish.app/Contents/MacOS/
Wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish Shell.app/Contents/MacOS/Wish
Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish.app/Contents/MacOS/Wish");
foundit:
sprintf(cmdbuf, "\"%s\" %s/pd.tk %d\n", filename,
guidir, portno); +#else
sprintf(cmdbuf,
"TCL_LIBRARY=\"%s/tcl/library\" TK_LIBRARY=\"%s/tk/
library" \
\"%s/pd-gui\" %d\n",
sys_libdir->s_name, sys_libdir->s_name, guidir,
portno); +#endif
sys_guicmd = cmdbuf;
}
if (sys_verbose)
fprintf(stderr, "%s", sys_guicmd);
childpid = fork(); if (childpid < 0) {
@@ -1045,75 +1112,10 @@ } } #endif
if (!sys_guicmd)
{
-#ifdef __APPLE__
char *homedir = getenv("HOME"), filename[250];
struct stat statbuf;
/* first look for Wish bundled with and
renamed "Pd" */
sprintf(filename, "%s/../../MacOS/Pd", guidir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
if (!homedir || strlen(homedir) > 150)
goto nohomedir;
/* Look for Wish in user's Applications.
Might or might
not be names "Wish Shell", and might or might
not be
in "Utilities" subdir. */
sprintf(filename,
"%s/Applications/Utilities/Wish shell.app/
Contents/MacOS/Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Utilities/Wish.app/Contents/
MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish shell.app/Contents/MacOS/
Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish.app/Contents/MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
nohomedir:
/* Perform the same search among system
applications. */
strcpy(filename,
"/usr/bin/wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish Shell.app/
Contents/MacOS/Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish.app/Contents/
MacOS/Wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish Shell.app/Contents/MacOS/
Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish.app/Contents/MacOS/Wish");
foundit:
sprintf(cmdbuf, "\"%s\" %s/pd.tk %d\n", filename,
guidir, portno); -#else
sprintf(cmdbuf,
-"TCL_LIBRARY="%s/tcl/library" TK_LIBRARY="%s/tk/library" \
- "%s/pd-gui" %d\n",
sys_libdir->s_name, sys_libdir->s_name,
guidir, portno); -#endif
sys_guicmd = cmdbuf;
}
if (sys_verbose) fprintf(stderr, "%s", sys_guicmd); execl("/bin/sh", "sh", "-c", sys_guicmd, (char*)0); perror("pd: exec"); _exit(1);
}
}
#endif /* UNISTD */
#ifdef MSW
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hi
Russell was right and the sys_guicmd seems to have been the culprit, causing all the (you must exec!) os x framework errors.
His patch places that call _before_ the fork, and pd 0.41's s_inter.c seems happier now. I've just tested through gdb and I see no errors.
I've now filed a patch (# 1890705) on the tracker which fixes it.
David
On 1 Feb 2008, at 17:03, Miller Puckette wrote:
Aha, somehow I had persuaded myself that teh problem was when starting from the "App" (in which case Tcl/TK fork/execs pd) but now I gather it's when you start Pd from a shell so that it starts Tcl/Tk instead. I'll go try that and see if I can make it fail for me :)
M
On Fri, Feb 01, 2008 at 08:54:17AM -0600, Russell Bryant wrote:
David Plans Casal wrote:
I can't quite tell why it's complaining (since we -do- call execl), but of course there is a whole lot of sprintf going on between the two, so...
It's extremely unlikely that any of the string handling is the problem. However, there are also a bunch of calls to stat() as well as a call to seteuid() which are more likely.
Any suggestions, anyone?
Try the attached patch to see if moving building the sys_guicmd to before the fork fixes it. If it doesn't, try commenting out the call to seteuid(). Between those two, you should be able to find out what it's complaining about.
On a sidenote, the string handling here is not safe. It will crash if the path to your home directory is a lot longer than usual ...
-- Russell Bryant
Index: s_inter.c
RCS file: /cvsroot/pure-data/pd/src/s_inter.c,v retrieving revision 1.22 diff -u -r1.22 s_inter.c --- s_inter.c 16 Jan 2008 21:54:11 -0000 1.22 +++ s_inter.c 1 Feb 2008 14:43:37 -0000 @@ -1018,6 +1018,73 @@
#ifdef UNISTD
if (!sys_guicmd) {
+#ifdef __APPLE__
char *homedir = getenv("HOME"), filename[250];
struct stat statbuf;
/* first look for Wish bundled with and renamed
"Pd" */
sprintf(filename, "%s/../../MacOS/Pd", guidir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
if (!homedir || strlen(homedir) > 150)
goto nohomedir;
/* Look for Wish in user's Applications. Might or
might
not be names "Wish Shell", and might or might not be
in "Utilities" subdir. */
sprintf(filename,
"%s/Applications/Utilities/Wish shell.app/Contents/
MacOS/Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Utilities/Wish.app/Contents/MacOS/
Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish shell.app/Contents/MacOS/
Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish.app/Contents/MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
nohomedir:
/* Perform the same search among system
applications. */
strcpy(filename,
"/usr/bin/wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish Shell.app/Contents/
MacOS/Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish.app/Contents/MacOS/
Wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish Shell.app/Contents/MacOS/Wish
Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish.app/Contents/MacOS/Wish");
foundit:
sprintf(cmdbuf, "\"%s\" %s/pd.tk %d\n", filename,
guidir, portno); +#else
sprintf(cmdbuf,
"TCL_LIBRARY=\"%s/tcl/library\" TK_LIBRARY=\"%s/tk/
library" \
\"%s/pd-gui\" %d\n",
sys_libdir->s_name, sys_libdir->s_name, guidir,
portno); +#endif
sys_guicmd = cmdbuf;
}
if (sys_verbose)
fprintf(stderr, "%s", sys_guicmd);
childpid = fork(); if (childpid < 0) {
@@ -1045,75 +1112,10 @@ } } #endif
if (!sys_guicmd)
{
-#ifdef __APPLE__
char *homedir = getenv("HOME"), filename[250];
struct stat statbuf;
/* first look for Wish bundled with and
renamed "Pd" */
sprintf(filename, "%s/../../MacOS/Pd", guidir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
if (!homedir || strlen(homedir) > 150)
goto nohomedir;
/* Look for Wish in user's Applications.
Might or might
not be names "Wish Shell", and might or might
not be
in "Utilities" subdir. */
sprintf(filename,
"%s/Applications/Utilities/Wish shell.app/
Contents/MacOS/Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Utilities/Wish.app/Contents/
MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish shell.app/Contents/MacOS/
Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish.app/Contents/MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
nohomedir:
/* Perform the same search among system
applications. */
strcpy(filename,
"/usr/bin/wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish Shell.app/
Contents/MacOS/Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish.app/Contents/
MacOS/Wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish Shell.app/Contents/MacOS/
Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish.app/Contents/MacOS/Wish");
foundit:
sprintf(cmdbuf, "\"%s\" %s/pd.tk %d\n", filename,
guidir, portno); -#else
sprintf(cmdbuf,
-"TCL_LIBRARY="%s/tcl/library" TK_LIBRARY="%s/tk/library" \
- "%s/pd-gui" %d\n",
sys_libdir->s_name, sys_libdir->s_name,
guidir, portno); -#endif
sys_guicmd = cmdbuf;
}
if (sys_verbose) fprintf(stderr, "%s", sys_guicmd); execl("/bin/sh", "sh", "-c", sys_guicmd, (char*)0); perror("pd: exec"); _exit(1);
}
}
#endif /* UNISTD */
#ifdef MSW
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hey
Now that we have a nice clean SVN repo, can I just use svn diff and apply this patch myself?
And if so, what's the appropriate branch? branches/pd? branches / pd / pd-0.40-3?
David
On 10 Feb 2008, at 18:19, David Plans Casal wrote:
Hi
Russell was right and the sys_guicmd seems to have been the culprit, causing all the (you must exec!) os x framework errors.
His patch places that call _before_ the fork, and pd 0.41's s_inter.c seems happier now. I've just tested through gdb and I see no errors.
I've now filed a patch (# 1890705) on the tracker which fixes it.
David
On 1 Feb 2008, at 17:03, Miller Puckette wrote:
Aha, somehow I had persuaded myself that teh problem was when starting from the "App" (in which case Tcl/TK fork/execs pd) but now I gather it's when you start Pd from a shell so that it starts Tcl/Tk instead. I'll go try that and see if I can make it fail for me :)
M
On Fri, Feb 01, 2008 at 08:54:17AM -0600, Russell Bryant wrote:
David Plans Casal wrote:
I can't quite tell why it's complaining (since we -do- call execl), but of course there is a whole lot of sprintf going on between the two, so...
It's extremely unlikely that any of the string handling is the problem. However, there are also a bunch of calls to stat() as well as a call to seteuid() which are more likely.
Any suggestions, anyone?
Try the attached patch to see if moving building the sys_guicmd to before the fork fixes it. If it doesn't, try commenting out the call to seteuid(). Between those two, you should be able to find out what it's complaining about.
On a sidenote, the string handling here is not safe. It will crash if the path to your home directory is a lot longer than usual ...
-- Russell Bryant
Index: s_inter.c
RCS file: /cvsroot/pure-data/pd/src/s_inter.c,v retrieving revision 1.22 diff -u -r1.22 s_inter.c --- s_inter.c 16 Jan 2008 21:54:11 -0000 1.22 +++ s_inter.c 1 Feb 2008 14:43:37 -0000 @@ -1018,6 +1018,73 @@
#ifdef UNISTD
if (!sys_guicmd) {
+#ifdef __APPLE__
char *homedir = getenv("HOME"), filename[250];
struct stat statbuf;
/* first look for Wish bundled with and renamed
"Pd" */
sprintf(filename, "%s/../../MacOS/Pd", guidir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
if (!homedir || strlen(homedir) > 150)
goto nohomedir;
/* Look for Wish in user's Applications. Might or
might
not be names "Wish Shell", and might or might not
be
in "Utilities" subdir. */
sprintf(filename,
"%s/Applications/Utilities/Wish shell.app/Contents/
MacOS/Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Utilities/Wish.app/Contents/MacOS/
Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish shell.app/Contents/MacOS/
Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish.app/Contents/MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
nohomedir:
/* Perform the same search among system
applications. */
strcpy(filename,
"/usr/bin/wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish Shell.app/Contents/
MacOS/Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish.app/Contents/MacOS/
Wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish Shell.app/Contents/MacOS/Wish
Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish.app/Contents/MacOS/Wish");
foundit:
sprintf(cmdbuf, "\"%s\" %s/pd.tk %d\n", filename,
guidir, portno); +#else
sprintf(cmdbuf,
"TCL_LIBRARY=\"%s/tcl/library\" TK_LIBRARY=\"%s/tk/
library" \
\"%s/pd-gui\" %d\n",
sys_libdir->s_name, sys_libdir->s_name, guidir,
portno); +#endif
sys_guicmd = cmdbuf;
}
if (sys_verbose)
fprintf(stderr, "%s", sys_guicmd);
childpid = fork(); if (childpid < 0) {
@@ -1045,75 +1112,10 @@ } } #endif
if (!sys_guicmd)
{
-#ifdef __APPLE__
char *homedir = getenv("HOME"), filename[250];
struct stat statbuf;
/* first look for Wish bundled with and
renamed "Pd" */
sprintf(filename, "%s/../../MacOS/Pd", guidir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
if (!homedir || strlen(homedir) > 150)
goto nohomedir;
/* Look for Wish in user's Applications.
Might or might
not be names "Wish Shell", and might or might
not be
in "Utilities" subdir. */
sprintf(filename,
"%s/Applications/Utilities/Wish shell.app/
Contents/MacOS/Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Utilities/Wish.app/Contents/
MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish shell.app/Contents/MacOS/
Wish Shell",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
sprintf(filename,
"%s/Applications/Wish.app/Contents/MacOS/Wish",
homedir);
if (stat(filename, &statbuf) >= 0)
goto foundit;
nohomedir:
/* Perform the same search among system
applications. */
strcpy(filename,
"/usr/bin/wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish Shell.app/
Contents/MacOS/Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Utilities/Wish.app/Contents/
MacOS/Wish");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish Shell.app/Contents/MacOS/
Wish Shell");
if (stat(filename, &statbuf) >= 0)
goto foundit;
strcpy(filename,
"/Applications/Wish.app/Contents/MacOS/Wish");
foundit:
sprintf(cmdbuf, "\"%s\" %s/pd.tk %d\n", filename,
guidir, portno); -#else
sprintf(cmdbuf,
-"TCL_LIBRARY="%s/tcl/library" TK_LIBRARY="%s/tk/library" \
- "%s/pd-gui" %d\n",
sys_libdir->s_name, sys_libdir->s_name,
guidir, portno); -#endif
sys_guicmd = cmdbuf;
}
if (sys_verbose) fprintf(stderr, "%s", sys_guicmd); execl("/bin/sh", "sh", "-c", sys_guicmd, (char*)0); perror("pd: exec"); _exit(1);
}
}
#endif /* UNISTD */
#ifdef MSW
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hallo, David Plans Casal hat gesagt: // David Plans Casal wrote:
Now that we have a nice clean SVN repo, can I just use svn diff and apply this patch myself?
And if so, what's the appropriate branch? branches/pd? branches / pd / pd-0.40-3?
I'd say, that as we now have no ACL anymore, care should be taken when working on the Pd sources itself. So far, Miller had his own section that was read-only for others. I think, as the mechanism to protect Miller's part is gone now, we need a policy instead how to achieve a similar kind of protection, and we probably need it soon. My suggestion would be to agree that only Miller commits to the "trunk" of "pd" and to create some similarily protected area for Miller's release branches.
Ciao
On Feb 10, 2008, at 5:58 PM, Frank Barknecht wrote:
Hallo, David Plans Casal hat gesagt: // David Plans Casal wrote:
Now that we have a nice clean SVN repo, can I just use svn diff and apply this patch myself?
And if so, what's the appropriate branch? branches/pd? branches / pd / pd-0.40-3?
I'd say, that as we now have no ACL anymore, care should be taken when working on the Pd sources itself. So far, Miller had his own section that was read-only for others. I think, as the mechanism to protect Miller's part is gone now, we need a policy instead how to achieve a similar kind of protection, and we probably need it soon. My suggestion would be to agree that only Miller commits to the "trunk" of "pd" and to create some similarily protected area for Miller's release branches.
Yeah, we just need to enforce the social rule about always asking permission before committing to someone else's area, on this list or directly. There isn't really a big threat to Miller's code since he maintains it in his own git repository. Changes committed to trunk/ pd would just be overwritten. And of course, we can always reverse the changes...
.hc
------------------------------------------------------------------------ ----
All information should be free. - the hacker ethic
Hi
On 10 Feb 2008, at 22:58, Frank Barknecht wrote:
And if so, what's the appropriate branch? branches/pd? branches / pd / pd-0.40-3?
I'd say, that as we now have no ACL anymore, care should be taken when working on the Pd sources itself. So far, Miller had his own section that was read-only for others. I think, as the mechanism to protect Miller's part is gone now, we need a policy instead how to achieve a similar kind of protection, and we probably need it soon. My suggestion would be to agree that only Miller commits to the "trunk" of "pd" and to create some similarily protected area for Miller's release branches.
I don't have a problem with the pumpkin holder approach at all (which is why I didn't just commit this to trunk)
I would like to see tiny (but important) patches go to latest unprotected branch, wherefrom miller can just cherry pick changes from branches to trunk, so:
[someDeveloper]:
svn checkout branches/buggyBranch [edits s_inter.c] svn commit -m "I fixed bug 37654" revision 20
[miller]:
svn diff -rHEAD s_inter.c [oooh yummy change] svn merge -r 20:HEAD svn://puredata/branches/buggyBranch [slurp]
In the meantime, what branch do people think bugfixes like this one should go into?
David
In the CVS days, my process was to test my latest source tree on the three major platforms, then put the sources both on my website and in the repository. (for minor changes that didn't warrant a "test release" number I'd just upload to CVS but not before verifying everything.) So both the repository and my site are essentially copies of what I had last time everything worked.
I think that, in this model, it helps me more to have patches I can apply locally than entire branches upstairs in CVS.
This does mean I should be as quick as I can to adopt urgent patches such as Casals's. I'm not always able to test and deal with patches immediately, and am sometimes out of commission for weeks (for instance, while trying to deal with font sizes I was out of sync with the uploaded code). This time around I hope to get this patch tested and uploaded within a couple of days, depending on how long it takes me to figure out how to manage my internal version headaches (already worknig on 0.42...)
cheers Miller
On Mon, Feb 11, 2008 at 09:29:19AM +0000, David Plans Casal wrote:
Hi
On 10 Feb 2008, at 22:58, Frank Barknecht wrote:
And if so, what's the appropriate branch? branches/pd? branches / pd / pd-0.40-3?
I'd say, that as we now have no ACL anymore, care should be taken when working on the Pd sources itself. So far, Miller had his own section that was read-only for others. I think, as the mechanism to protect Miller's part is gone now, we need a policy instead how to achieve a similar kind of protection, and we probably need it soon. My suggestion would be to agree that only Miller commits to the "trunk" of "pd" and to create some similarily protected area for Miller's release branches.
I don't have a problem with the pumpkin holder approach at all (which is why I didn't just commit this to trunk)
I would like to see tiny (but important) patches go to latest unprotected branch, wherefrom miller can just cherry pick changes from branches to trunk, so:
[someDeveloper]:
svn checkout branches/buggyBranch [edits s_inter.c] svn commit -m "I fixed bug 37654" revision 20
[miller]:
svn diff -rHEAD s_inter.c [oooh yummy change] svn merge -r 20:HEAD svn://puredata/branches/buggyBranch [slurp]
In the meantime, what branch do people think bugfixes like this one should go into?
David
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
By "it helps me more to have patches", do you mean something different than how we are doing it now? Or do you mean keep on submitting patches to the tracker?
.hc
On Feb 11, 2008, at 1:44 PM, Miller Puckette wrote:
In the CVS days, my process was to test my latest source tree on the three major platforms, then put the sources both on my website and in the repository. (for minor changes that didn't warrant a "test release" number I'd just upload to CVS but not before verifying everything.) So both the repository and my site are essentially copies of what I had last time everything worked.
I think that, in this model, it helps me more to have patches I can apply locally than entire branches upstairs in CVS.
This does mean I should be as quick as I can to adopt urgent patches such as Casals's. I'm not always able to test and deal with patches immediately, and am sometimes out of commission for weeks (for instance, while trying to deal with font sizes I was out of sync with the uploaded code). This time around I hope to get this patch tested and uploaded within a couple of days, depending on how long it takes me to figure out how to manage my internal version headaches (already worknig on 0.42...)
cheers Miller
On Mon, Feb 11, 2008 at 09:29:19AM +0000, David Plans Casal wrote:
Hi
On 10 Feb 2008, at 22:58, Frank Barknecht wrote:
And if so, what's the appropriate branch? branches/pd? branches / pd / pd-0.40-3?
I'd say, that as we now have no ACL anymore, care should be taken when working on the Pd sources itself. So far, Miller had his own section that was read-only for others. I think, as the mechanism to protect Miller's part is gone now, we need a policy instead how to achieve a similar kind of protection, and we probably need it soon. My suggestion would be to agree that only Miller commits to the "trunk" of "pd" and to create some similarily protected area for Miller's release branches.
I don't have a problem with the pumpkin holder approach at all (which is why I didn't just commit this to trunk)
I would like to see tiny (but important) patches go to latest unprotected branch, wherefrom miller can just cherry pick changes from branches to trunk, so:
[someDeveloper]:
svn checkout branches/buggyBranch [edits s_inter.c] svn commit -m "I fixed bug 37654" revision 20
[miller]:
svn diff -rHEAD s_inter.c [oooh yummy change] svn merge -r 20:HEAD svn://puredata/branches/buggyBranch [slurp]
In the meantime, what branch do people think bugfixes like this one should go into?
David
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
I think I mean keep on submitting patches to the tracker.
M
On Mon, Feb 11, 2008 at 07:47:19PM -0500, Hans-Christoph Steiner wrote:
By "it helps me more to have patches", do you mean something different than how we are doing it now? Or do you mean keep on submitting patches to the tracker?
.hc
On Sun, 10 Feb 2008, Frank Barknecht wrote:
I'd say, that as we now have no ACL anymore,
So, what is it with the ACL ? Is it that SVN doesn't have support for that, or just that the ACL config has to be rewritten for SVN because of incompatible formats?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard wrote:
On Sun, 10 Feb 2008, Frank Barknecht wrote:
I'd say, that as we now have no ACL anymore,
So, what is it with the ACL ? Is it that SVN doesn't have support for that, or just that the ACL config has to be rewritten for SVN because of incompatible formats?
sourceforge does not (yet?) support ACLs on SVN-repositories.
gfmdr IOhannes
On Tue, 12 Feb 2008, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Sun, 10 Feb 2008, Frank Barknecht wrote:
I'd say, that as we now have no ACL anymore,
So, what is it with the ACL ? Is it that SVN doesn't have support for that, or just that the ACL config has to be rewritten for SVN because of incompatible formats?
sourceforge does not (yet?) support ACLs on SVN-repositories.
Ah, how is that something that SF has to setup themselves?... I have never been admin on a SF.net project, so, I don't know, but wouldn't that only be about whether a web interface is available for handling the ACL ? What's the SVN equivalent of the CVSROOT directory?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Ah, how is that something that SF has to setup themselves?... I have never been admin on a SF.net project, so, I don't know, but wouldn't that only be about whether a web interface is available for handling the ACL ? What's the SVN equivalent of the CVSROOT directory?
Read http://tinyurl.com/2hhcay Section: Permissions
Ciao
Mathieu Bouchard wrote:
Ah, how is that something that SF has to setup themselves?... I have never been admin on a SF.net project, so, I don't know, but wouldn't that only be about whether a web interface is available for handling the ACL ?
basically yes.
What's the SVN equivalent of the CVSROOT directory?
but in practice no. there is no CVSROOT equivalent in subversion. subversion itself does no nothing about authentication and authorisation: this is left for a frontend. the usual frontend (the one sourceforge is using) is via http/webdav; an ACL needs to made available to the frontend; for apache, this is usually done via a special file on the filesystem (which is read by the apache-server); more info under [1]. sourceforge would need to provide a means to write this special file; in my privat svn-setups, i haven't found a way to split this configuration into a per-repository file (instead of per-webserver) - but that might be just my personal failure; this might be the reason why sourceforge does not provide any means of ACLs for svn (yet).
fmgasd,r IOhannes
[1] http://svnbook.red-bean.com/en/1.4/svn.serverconfig.httpd.html#svn.servercon...
(btw, i think the svnbook is a good read anyhow)
On Wed, 13 Feb 2008, IOhannes m zmoelnig wrote:
What's the SVN equivalent of the CVSROOT directory?
there is no CVSROOT equivalent in subversion.
Ok, I thought that there could be either a hidden folder or some metadata that does not count as part of the repository itself, but is still under the repository of SVN... but anyway.
subversion itself does no nothing about authentication and authorisation: this is left for a frontend. the usual frontend (the one sourceforge is using) is via http/webdav; an ACL needs to made available to the frontend; for apache, this is usually done via a special file on the filesystem (which is read by the apache-server); more info under [1]. sourceforge would need to provide a means to write this special file; in my privat svn-setups, i haven't found a way to split this configuration into a per-repository file (instead of per-webserver) - but that might be just my personal failure; this might be the reason why sourceforge does not provide any means of ACLs for svn (yet).
Is SVN ACL on SF's TODO list? if it is not, could we make a request to have this feature?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Feb 13, 2008, at 3:15 AM, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
Ah, how is that something that SF has to setup themselves?... I have never been admin on a SF.net project, so, I don't know, but wouldn't that only be about whether a web interface is available for handling the ACL ?
basically yes.
What's the SVN equivalent of the CVSROOT directory?
but in practice no. there is no CVSROOT equivalent in subversion. subversion itself does no nothing about authentication and authorisation: this is left for a frontend. the usual frontend (the one sourceforge is using) is via http/webdav; an ACL needs to made available to the frontend; for apache, this is usually done via a special file on the filesystem (which is read by the apache-server); more info under [1]. sourceforge would need to provide a means to write this special file; in my privat svn-setups, i haven't found a way to split this configuration into a per-repository file (instead of per-webserver) - but that might be just my personal failure; this might be the reason why sourceforge does not provide any means of ACLs for svn (yet).
I think Matju is talking about the CVSROOT section of CVS, where things like 'avail', 'cvsignore', and things like that.
.hc
fmgasd,r IOhannes
[1] http://svnbook.red-bean.com/en/1.4/ svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz
(btw, i think the svnbook is a good read anyhow)
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
kill your television
On Wed, 13 Feb 2008, Hans-Christoph Steiner wrote:
I think Matju is talking about the CVSROOT section of CVS, where things like 'avail', 'cvsignore', and things like that.
Yes, I'm thinking about that, but I confused pserver (which has an ACL in CVSROOT) and the ssh access method, which only uses UNIX perms... We weren't using pserver's ACL, I guess, because we were using SSH access.
I suspect that "svn+ssh" is completely different from CVS's ssh access, as in, no difference with using http/https, except encryption, but I don't really know.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Quoting Mathieu Bouchard matju@artengine.ca:
On Wed, 13 Feb 2008, Hans-Christoph Steiner wrote:
I think Matju is talking about the CVSROOT section of CVS, where things like 'avail', 'cvsignore', and things like that.
yes, this is what i had in mind when i answered.
I suspect that "svn+ssh" is completely different from CVS's ssh access, as in, no difference with using http/https, except encryption, but I don't really know.
exactly. as said, svn stores its revisions in a database: no unix perms on that level.
fgmads.r IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Wed, 13 Feb 2008, zmoelnig@iem.at wrote:
as said, svn stores its revisions in a database: no unix perms on that level.
"database" doesn't say anything about the implementation of a database on the filesystem, and it doesn't even say whether the database is the filesystem itself. I could call a whole CVS repository a database, easily. There's no requirement that a database shields itself from the filesystem on which it is stored nor that it refrains from using perms and other OS features.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sun, 10 Feb 2008, Frank Barknecht wrote:
I'd say, that as we now have no ACL anymore,
So, what is it with the ACL ? Is it that SVN doesn't have support for that, or just that the ACL config has to be rewritten for SVN because of incompatible formats?
AFAIK it's not ACL enabled on Sourceforge's SVN servers. But I last checked several months ago.
Ciao
Hello
On 1 Feb 2008, at 14:54, Russell Bryant wrote:
Try the attached patch to see if moving building the sys_guicmd to before the fork fixes it. If it doesn't, try commenting out the call to seteuid(). Between those two, you should be able to find out what it's complaining about.
So, you may have heard 0.40.1 was the bugfix that never was (my fault...)
I've now come to grips with packages/darwin_app and I'm building successfully on 10.5.1, so can test patches to resolve the fork() issue easily enough.
However, both setting the sys_guicmd call before the fork _and_ commenting out the call to setuid() fail to get rid of the messages:
14/02/2008 18:13:02 [0x0-0x185185].org.puredata.pd.wish[66305] Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ () to debug.
coming up in /var/log/syslog when starting pd
Below are the offending bits of s_inter.c as they stand right now; can anyone see what's wrong with this picture?
#endif sys_guicmd = cmdbuf; }
if (sys_verbose) fprintf(stderr, "%s", sys_guicmd);
childpid = fork(); if (childpid < 0) { if (errno) perror("sys_startgui"); else fprintf(stderr, "sys_startgui failed\n"); return (1); } else if (!childpid) /* we're the child */ { /*seteuid(getuid());*/ /* commented out to see if that's what causes exec errors /* /* lose setuid priveliges */
#ifndef __APPLE__ /* the wish process in Unix will make a wish shell and read/write standard in and out unless we close the file descriptors. Somehow this doesn't make the MAC OSX version of Wish happy...*/ if (pipe(stdinpipe) < 0) sys_sockerror("pipe"); else { if (stdinpipe[0] != 0) { close (0); dup2(stdinpipe[0], 0); close(stdinpipe[0]); } } #endif execl("/bin/sh", "sh", "-c", sys_guicmd, (char*)0); perror("pd: exec"); _exit(1); }
David Plans Casal wrote:
However, both setting the sys_guicmd call before the fork _and_ commenting out the call to setuid() fail to get rid of the messages:
14/02/2008 18:13:02 [0x0-0x185185].org.puredata.pd.wish[66305] Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
coming up in /var/log/syslog when starting pd
Below are the offending bits of s_inter.c as they stand right now; can anyone see what's wrong with this picture?
*punt*
When __APPLE__ is defined, there is _nothing_ happening between fork() and execl(). So, I give up. It must be something going on inside if wish ...
-- Russell
Hi all,
I don't get any of these symptoms on 10.5.2, but don't have a 10.5.1 machine handy.
And I agree, there's simply no code between the fork and the exec anymore, either in the case that Pd starts the Gui or vice versa (the normal way, in which the GUI starts Pd.)
Am I right that Pd 0.41-0 and 0.41-1 currently don't start up in 10.5.1, when you "open" the App in the normal way? I don't get that either in 10.5.0 or in 10.5.2.
thanks Miller
On Fri, Feb 15, 2008 at 11:06:51AM -0500, Russell Bryant wrote:
David Plans Casal wrote:
However, both setting the sys_guicmd call before the fork _and_ commenting out the call to setuid() fail to get rid of the messages:
14/02/2008 18:13:02 [0x0-0x185185].org.puredata.pd.wish[66305] Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
coming up in /var/log/syslog when starting pd
Below are the offending bits of s_inter.c as they stand right now; can anyone see what's wrong with this picture?
*punt*
When __APPLE__ is defined, there is _nothing_ happening between fork() and execl(). So, I give up. It must be something going on inside if wish ...
-- Russell
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hi
On 15 Feb 2008, at 20:45, Miller Puckette wrote:
I don't get any of these symptoms on 10.5.2, but don't have a 10.5.1 machine handy.
Ok upgrading to 10.5.2 tomorrow, so will see if these go away then (perhaps apple devs fault?)
And I agree, there's simply no code between the fork and the exec anymore, either in the case that Pd starts the Gui or vice versa (the normal way, in which the GUI starts Pd.)
Well, I'm glad I'm not the only thinking this is very weird. I thought I was going nuts.
Am I right that Pd 0.41-0 and 0.41-1 currently don't start up in 10.5.1, when you "open" the App in the normal way? I don't get that either in 10.5.0 or in 10.5.2.
No, they _do_ start, it's just if you watch /var/log/syslog, they start with all the exec() warnings and crash sporadically with memory errors (undecipherable). GDB then reports 1081 in s_inter.c or thereabouts to be the problem.
Well maybe it'll all go away with 10.5.2; otherwise, I'm stumped. Leopard is one buggy cat.
David