Re: [PATCH] pagealign_alloc: don't loop endlessly
I've attached a revised version of my earlier patch that preserves more information and avoids problems when the exit handlers call error() after error() calls exit(). Regards, Derek Index: src/ChangeLog === RCS file: /cvs/ccvs/src/ChangeLog,v retrieving revision 1.3186 diff -u -p -r1.3186 ChangeLog --- src/ChangeLog 4 May 2005 02:48:16 - 1.3186 +++ src/ChangeLog 4 May 2005 20:14:40 - @@ -1,3 +1,7 @@ +2005-05-04 Derek Price <[EMAIL PROTECTED]> + + * error.c (error): Avoid recursion and syslog the problem. + 2005-05-03 Derek Price <[EMAIL PROTECTED]> * tag.c (is_in_val_tags): Remove unnecessary existance checking for the Index: src/error.c === RCS file: /cvs/ccvs/src/error.c,v retrieving revision 1.42 diff -u -p -r1.42 error.c --- src/error.c 18 Mar 2005 16:41:24 - 1.42 +++ src/error.c 4 May 2005 20:14:40 - @@ -120,16 +120,26 @@ error (int status, int errnum, const cha char *cmdbuf; char *emptybuf = ""; +static const char *last_message = NULL; +static va_list last_args; +static int last_status; +static int last_errnum; + +if (last_message) goto recursion_error; +last_message = message; +va_start (args, message); +last_args = args; +last_status = status; +last_errnum = errnum; + /* Initialize these to avoid a lot of special case error handling. */ buf = statbuf; buf2 = statbuf2; cmdbuf = emptybuf; /* Expand the message the user passed us. */ -va_start (args, message); length = sizeof (statbuf); buf = vasnprintf (statbuf, &length, message, args); -va_end (args); if (!buf) goto memerror; /* Expand the cvs commmand name to or [ aborted]. @@ -161,6 +171,12 @@ error (int status, int errnum, const cha /* Send the final message to the client or log it. */ cvs_outerr (buf2, length); +/* Reset our recursion lock. This needs to be done before the call to + * exit() to allow the exit handlers to make calls to error(). + */ +last_message = NULL; +va_end (args); + /* Done, if we're exiting. */ if (status) exit (EXIT_FAILURE); @@ -194,6 +210,37 @@ memerror: syslog (LOG_DAEMON | LOG_EMERG, "Memory exhausted. Aborting."); #endif /* HAVE_SYSLOG_H */ +goto sidestep_done; + +recursion_error: +#if HAVE_SYSLOG_H +/* Syslog the problem since recursion probably means that we encountered an + * error while attempting to send the last error message to the client. + */ + +syslog (LOG_DAEMON | LOG_EMERG, + "error (%d, %d) called recursively. Original message was:", + last_status, last_errnum); +vsyslog (LOG_DAEMON | LOG_EMERG, last_message, last_args); + + +syslog (LOG_DAEMON | LOG_EMERG, +"error (%d, %d) called recursively. Second message was:", + status, errnum); +va_start (args, message); +vsyslog (LOG_DAEMON | LOG_EMERG, message, args); +va_end (args); + +syslog (LOG_DAEMON | LOG_EMERG, "Aborting."); +#endif /* HAVE_SYSLOG_H */ + +sidestep_done: +/* Reset our recursion lock. This needs to be done before the call to + * exit() to allow the exit handlers to make calls to error(). + */ +last_message = NULL; +va_end (last_args); + exit (EXIT_FAILURE); } signature.asc Description: OpenPGP digital signature ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: MacOS X 10.3.7 Build Problem After CVS CheckOut
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino <[EMAIL PROTECTED]> writes: > I'm seeing the same build problem on both stable & feature: > > Titanium:~/projects/cvs-1.12.12 conradtpino$ make > make all-recursive > Making all in lib > make all-am > make[3]: Nothing to be done for `all-am'. > Making all in zlib > make[2]: Nothing to be done for `all'. > Making all in diff > make[2]: Nothing to be done for `all'. > Making all in src > rm: cvs: is a directory > make[2]: *** [cvs] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > Titanium:~/projects/cvs-1.12.12 conradtpino$ > > The problem occurs because the MacOS file system appears to > be case insensitive with respect to file names i.e. both of > the following do the same thing: > > ls CVS > ls cvs > > I'm seeing the error for the first time because I checked > out with a revision tag instead of downloading a tar ball. > > I can work around the problem by using "export" instead of > "checkout" command. > > The question becomes: Is it worthwhile fixing the build > to deal with case insensitive UNIX file systems? The typicaly way that I build on case-insensitive filesystems is like this: cvs checkout ccvs cd ccvs mkdir objdir cd objdir ../configure && make && make check this means that all of the derrived files are in the ccvs/objdir subdirectory. If I am going to build for multiple architectures out of the same set of sources, I have been known to use the following directory names: obj.macosx2 # MacOS 10.2 obj.macosx3 # MacOS 10.3 obj.solsparc9 # Solaris 9 on Sparc hardware obj.solsparc8 # Solaris 8 on Sparc hardware obj.solsparc7 # Solaris 7 on Sparc hardware obj.aix43 # AIX 4.3 obj.fbsd42 # FreeBSD 4.2-RELEASE obj.fbsd410 # FreeBSD 4.10-RELEASE obj.nbsd16 # NetBSD 1.6 obj.nbsd299 # NetBSD 2.99.15 obj.rh73# Redhat 7.3 i386 GNU/Linux obj.fc3 # Fedora Core 3 i386 GNU/Linux obj.unicos # Unicos 9.0 Cray Y-MP EL instead of 'objdir' as the place where I build and test out of one checkout of the sources... Your experience may be different. I almost never actually build directly in the 'ccvs' directory as it was checked out (I try it once per release as we are getting close to make sure it still works). Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCeGT03x41pRYZE/gRAvOQAKDKvElDg9X4RFPYGc5vtK2q1F0xGwCgxBov +hBA43zL1skrlMklP/GJtf0= =U12V -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [PATCH] pagealign_alloc: don't loop endlessly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thorsten Glaser wrote: >Derek Price dixit: > >>Does the attached, more general, patch do the trick for you? > > >It does, but I do not get a diagnostic, neither on stderr >(CVS output) nor in syslog on server or client. This is >probably because the CVS server is running in a chroot. > >I suggest a diagnostics on stderr, plus - in this case - the >actual solution is to add a device node into the chroot, and >from a "recursion error" nobody would get the idea. My patch logs the actual error message to the syslog too (via the vsyslog() call), but if your chroot is preventing access to the syslog, that wouldn't help anyhow. Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCeN8FLD1OTBfyMaQRAiHfAKDcLW4aGk+Ek9JHVeTSVbUqERJiqQCguXyo Xcovfa0jOnzz+159lb0oJNw= =RGRl -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [PATCH] pagealign_alloc: don't loop endlessly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thorsten Glaser wrote: >Derek Price dixit: > >>>Yes, that's why I was suggesting to print the error message to stderr >>>so at least the client gets an idea about what happened and can slap >>>the server administrator. CVS does this for quite some occasions, for >>>example no space available in the server's temporary directory. >> >>Could you point me at the code that does this? > > >Not out of the blue, I had to check. But it happens frequently >when e.g. the OpenBSD anoncvs servers are overloaded. And where is the code that does this? >>How much good would sending the message to stderr really do? This >>problem can only occur on the server, where sending to stderr, at best, >>can only be reported to the client as an unrecognized protocol response, >>if reported at all, once the network buffers are disabled (the network >>buffer code is what is calling pagealign_alloc() here). > > >No, it's actually displayed by the client (with my first diff). I'm fairly certain it shouldn't be consistently displayed this way. It might ocassionally appear in the context of "Unrecognized response from server: `some message on stderr'". Can you provide me with a test case that reproduces this behavior? Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCeQxpLD1OTBfyMaQRAgrVAJ9ZeNqHtuhH3dTjgZjAMLLpvr53qQCdFOWC 2Ccd7RA08CDF3ceEpfpmFtc= =bics -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [PATCH] pagealign_alloc: don't loop endlessly
Does the attached, more general, patch do the trick for you? I think the problem is deeper - error() really needs a way to bypass the memory allocation of the buffer routines, but this should work around the problem for now. Cheers, Derek Thorsten Glaser wrote: >Hello! > >Please apply the following patch. It prevents GNU CVS 1.12.12 >from looping endlessly and dumping core due to lack of stack >(recursion depth) when /dev/zero cannot be found, for example >in a chroot(2) environment. > >I have copyright assignments for CVS filed with the FSF. > >//mirabile > > Index: src/error.c === RCS file: /cvs/ccvs/src/error.c,v retrieving revision 1.42 diff -u -p -r1.42 error.c --- src/error.c 18 Mar 2005 16:41:24 - 1.42 +++ src/error.c 4 May 2005 14:14:29 - @@ -119,6 +119,10 @@ error (int status, int errnum, const cha char statcmdbuf[32]; char *cmdbuf; char *emptybuf = ""; +static bool in_error = false; + +if (in_error) goto recursion_error; +in_error = true; /* Initialize these to avoid a lot of special case error handling. */ buf = statbuf; @@ -173,6 +177,9 @@ error (int status, int errnum, const cha /* Restore errno per our charter. */ errno = save_errno; +/* Reset our recursion lock. */ +in_error = false; + /* Done. */ return; @@ -195,6 +202,21 @@ memerror: #endif /* HAVE_SYSLOG_H */ exit (EXIT_FAILURE); + +recursion_error: +#if HAVE_SYSLOG_H +syslog (LOG_DAEMON | LOG_EMERG, + "error (%d, %d) called recursively. Message was:", + status, errnum); + +va_start (args, message); +vsyslog (LOG_DAEMON | LOG_EMERG, message, args); +va_end (args); + +syslog (LOG_DAEMON | LOG_EMERG, "Aborting."); +#endif /* HAVE_SYSLOG_H */ + +exit (EXIT_FAILURE); } signature.asc Description: OpenPGP digital signature ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [PATCH] pagealign_alloc: don't loop endlessly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thorsten Glaser wrote: >Derek Price dixit: > >>My patch logs the actual error message to the syslog too (via the >>vsyslog() call), but if your chroot is preventing access to the syslog, >>that wouldn't help anyhow. > > >Yes, that's why I was suggesting to print the error message to stderr >so at least the client gets an idea about what happened and can slap >the server administrator. CVS does this for quite some occasions, for >example no space available in the server's temporary directory. Could you point me at the code that does this? Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCePF8LD1OTBfyMaQRAhXMAJ4i5Ds+nN3xHmmV9GaAiYcB3ICr7wCdEjXk EP9Byuj3UUUChsErfKEnmqk= =LsW/ -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [PATCH] pagealign_alloc: don't loop endlessly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thorsten Glaser wrote: >Derek Price dixit: > >>Does the attached, more general, patch do the trick for you? > > >It does, but I do not get a diagnostic, neither on stderr >(CVS output) nor in syslog on server or client. This is >probably because the CVS server is running in a chroot. > >I suggest a diagnostics on stderr, plus - in this case - the >actual solution is to add a device node into the chroot, and >from a "recursion error" nobody would get the idea. How much good would sending the message to stderr really do? This problem can only occur on the server, where sending to stderr, at best, can only be reported to the client as an unrecognized protocol response, if reported at all, once the network buffers are disabled (the network buffer code is what is calling pagealign_alloc() here). Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCeOxVLD1OTBfyMaQRAtVIAKDiqPmz9ChWzpFMdM3qdW09gVuRRQCgmai4 zO0p26HHWC46yS7F89dQ2cw= =2hnM -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: MacOS X 10.3.7 Build Problem After CVS CheckOut
Conrad T. Pino wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Derek, From: Derek Price [mailto:[EMAIL PROTECTED] I never thought it was worth coming up with a more automated solution, but you're welcome to try. I would argue against changing the name of the executable though, and I'm not sure what else is workable. The "configure" script could test for the existence of a directory named "src/cvs" and if true then execute a "mkdir build" command if "build" is not already created. That being said, how many shell variations need to be tested before we commit such a fix assuming there are no objections? What good would it be to make the build directory if the user didn't know to cd there before building? Also, once the src dir is configured, the build dir will refuse to be configured. The user would have to `make distclean; cd build; ../configure' afterwards anyhow. There might be a way to bootstrap that, but why not try something simpler, like just printing a nice, easy-to-spot-and-read warning message? The test would be something like "$srcdir" = "$builddir" && $fs_case_insensitive && test -z "$exe_ext" I'm sure those var names are not correct, but you would have to make sure the latter test ran after all the tests that set the correct flags. Cheers, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: MacOS X 10.3.7 Build Problem After CVS CheckOut
Incidentally, I thought this was documented somewhere other than the email list, but I don't see it. I've added a note to INSTALL on stable and INSTALL-CVSon feature. Cheers, Derek Derek Price wrote: This is a well-known problem. The workaround is to use a build directory. i.e.: cvs co ccvs cd ccvs mkdir build cd build ../configure make I never thought it was worth coming up with a more automated solution, but you're welcome to try. I would argue against changing the name of the executable though, and I'm not sure what else is workable. Cheers, Derek Conrad T. Pino wrote: I'm seeing the same build problem on both stable & feature: Titanium:~/projects/cvs-1.12.12 conradtpino$ make make all-recursive Making all in lib make all-am make[3]: Nothing to be done for `all-am'. Making all in zlib make[2]: Nothing to be done for `all'. Making all in diff make[2]: Nothing to be done for `all'. Making all in src rm: cvs: is a directory make[2]: *** [cvs] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Titanium:~/projects/cvs-1.12.12 conradtpino$ The problem occurs because the MacOS file system appears to be case insensitive with respect to file names i.e. both of the following do the same thing: ls CVS ls cvs I'm seeing the error for the first time because I checked out with a revision tag instead of downloading a tar ball. I can work around the problem by using "export" instead of "checkout" command. The question becomes: Is it worthwhile fixing the build to deal with case insensitive UNIX file systems? Conrad ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: MacOS X 10.3.7 Build Problem After CVS CheckOut
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Derek, > From: Derek Price [mailto:[EMAIL PROTECTED] > > I never thought it was worth coming up with a more automated solution, > but you're welcome to try. I would argue against changing the name of > the executable though, and I'm not sure what else is workable. The "configure" script could test for the existence of a directory named "src/cvs" and if true then execute a "mkdir build" command if "build" is not already created. That being said, how many shell variations need to be tested before we commit such a fix assuming there are no objections? > Cheers, Ditto, > Derek Conrad -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQng1o7NM28ubzTo9EQJ4WwCgk0yMbtCgfIihIqdu4SfRVZx6bzcAn3aI 1QX5NKqIyvSn0RQn2k04rwkf =5J85 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: MacOS X 10.3.7 Build Problem After CVS CheckOut
This is a well-known problem. The workaround is to use a build directory. i.e.: cvs co ccvs cd ccvs mkdir build cd build ../configure make I never thought it was worth coming up with a more automated solution, but you're welcome to try. I would argue against changing the name of the executable though, and I'm not sure what else is workable. Cheers, Derek Conrad T. Pino wrote: I'm seeing the same build problem on both stable & feature: Titanium:~/projects/cvs-1.12.12 conradtpino$ make make all-recursive Making all in lib make all-am make[3]: Nothing to be done for `all-am'. Making all in zlib make[2]: Nothing to be done for `all'. Making all in diff make[2]: Nothing to be done for `all'. Making all in src rm: cvs: is a directory make[2]: *** [cvs] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Titanium:~/projects/cvs-1.12.12 conradtpino$ The problem occurs because the MacOS file system appears to be case insensitive with respect to file names i.e. both of the following do the same thing: ls CVS ls cvs I'm seeing the error for the first time because I checked out with a revision tag instead of downloading a tar ball. I can work around the problem by using "export" instead of "checkout" command. The question becomes: Is it worthwhile fixing the build to deal with case insensitive UNIX file systems? Conrad ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: PAM session support documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Murphy wrote: > Hi Guys, > I would like to commit the attached patch. It documents in > the example files the necessary session lines in the PAM > configuration file. > > I/we seem to have missed this when the session support was > added. The manual has the necessary additions. > > OK with you? Yeah, sure. You're mostly in charge where the PAM support is concerned, I think, as long as it remains possible to disable it and doesn't break backwards compatibility anywhere, in the protocol, API, or otherwise. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCd5WyLD1OTBfyMaQRAkAwAJsHEU9IcFOl2rcZuawE/L1GdX7KvACg2iYR j2vDG6yUzw/6aFC+/LquZrI= =lO7j -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
