RE: Setup 2.218.2.6 [Was: Re: Setup 2.218.2.4] (new version uploaded)
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 15, 2002 8:55 AM The attached patch seems to fix this and some other problems. I've uploaded a new version to sourceware. At least some of the below should be useful on the trunk, too. Thanks heaps Chris. I appreciate this. (BTW: how did you reproduce the fault?) I'll probably rearrange what you've put into HEAD a little, as static variables are getting eliminated (the Builder is the appropriate place to store such information). I notice that you've increased the stack size for the parser - this shouldn't have been needed with the right hand recursion removed. Did you observe continued overflows or was this preventative? Cheers, Rob
RE: Setup 2.218.2.4 (fixed?)
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 2:57 PM To: [EMAIL PROTECTED] Subject: Re: Setup 2.218.2.4 (fixed?) On Mon, May 13, 2002 at 12:19:41PM -0400, Christopher Faylor wrote: On Mon, May 13, 2002 at 09:05:52PM +1000, Robert Collins wrote: I've noticed the same problem on a non-smb directory, fwiw. dir you mean as in d:\foo or as in NFS mounted? Occam's razor. I think I've tracked this problem down. I've checked in a couple of fixes in the branch. I've put up a new version of setup.exe on sourceware. Thanks. Somehow your version grabs atoi from cygwin1.dll. Doh. I'm about to upload a new version. I believe that there were a couple of problems. One was that setup.exe would consider anything with the string setup.ini to be a potential setup.ini file. The reason for this is that Robert (or someone) seems enamored of the use of strstr for path manipulation. I think I've mentioned before that you really can't do a strstr (path, foo.bar) and assume that any foo.bar that means that the file component is foo.bar. This assumption exists in several places in the source code. Yeah, it was on my this-is-not-quite-right list, but I didn't think it could be causing the crashes.. In my case, setup.exe was parsing files like setup.ini.old, setup.ini~, and setup.ini.orig. This caused problems since the assumption was that the setup.ini was the trailing component of a path spec, which it wasn't. Ah, so the trailing path was calculated as ...setup/ (given setup.ini.orig). The other problem was the clobbering of a global buffer. This resulted in either a stack overrun or just a hung setup.exe. I've attached the patch and ChangeLog below. I didn't try to check this into the trunk since I thought that Robert would look at it and want to do something another way. I might, but in no great rush. If you've got the time, please port this forward. Can I suggest that probably setup.exe needs something like a suffix function which operates similarly to strstr but only returns a non-NULL pointer if the string matches the last strlen(string) characters of a path? The STL provides rfind, and suffix could be created as a semi-trivial wrapper of rfind. Thanks for this Chris. Rob
Re: Setup 2.218.2.4 (fixed?)
On Tue, May 14, 2002 at 12:36:50AM -0500, Gary R. Van Sickle wrote: Can I suggest that probably setup.exe needs something like a suffix function which operates similarly to strstr but only returns a non-NULL pointer if the string matches the last strlen(string) characters of a path? What's worked well for me in the past in such situations is to just derive a Path class from std::string, and give it members such as GetFilename(), GetFullPath(), etc. I could knock out something analagous pretty quick I should think, maybe consolidating our two string classes (cistring and String) in the process If you look at the code, it isn't as simple as just getting the filename. There are also things like strstr (foo, .tar.bz2). I guess you could make something like GetExtension (foo, 2) to accommodate that. cgf
Re: Setup 2.218.2.6 [Was: Re: Setup 2.218.2.4]
On Tue, May 14, 2002 at 10:40:19AM -0400, Charles Wilson wrote: Still doesn't work when installing from a local directory (although it works fine when installing from internet) Once it begins parsing setup.ini, it dies almost immediately. But, there is no warning or error popup. If I send you a debuggable setup.exe, would you mind running it and getting a back trace? Or, if you are into pain, you could try building a setup.exe for yourself. Maybe it's because I like to build these things on linux but I had a very hard time getting things configured right so that I could debug my problem. Barring that, could you send an 'ls -lR' of your download directory? cgf
Re: Setup 2.218.2.6 [Was: Re: Setup 2.218.2.4]
Christopher Faylor wrote: On Tue, May 14, 2002 at 10:40:19AM -0400, Charles Wilson wrote: Still doesn't work when installing from a local directory (although it works fine when installing from internet) Once it begins parsing setup.ini, it dies almost immediately. But, there is no warning or error popup. If I send you a debuggable setup.exe, would you mind running it and getting a back trace? Yeah, I could do that. Or, if you are into pain, you could try building a setup.exe for yourself. Maybe it's because I like to build these things on linux but I had a very hard time getting things configured right so that I could debug my problem. I fear this. I don't have the appropriate mingw libraries, libstdc++, or nothin' -- and I really don't have time to figure it all out right now. Just gimme a debug version, and I'll send you a bt. Barring that, could you send an 'ls -lR' of your download directory? Not from here -- all of this must wait until tonight when I am home. --Chuck
Re: Setup 2.218.2.6 [Was: Re: Setup 2.218.2.4]
On Tue, May 14, 2002 at 01:10:05PM -0400, Charles Wilson wrote: Christopher Faylor wrote: On Tue, May 14, 2002 at 10:40:19AM -0400, Charles Wilson wrote: Still doesn't work when installing from a local directory (although it works fine when installing from internet) Once it begins parsing setup.ini, it dies almost immediately. But, there is no warning or error popup. If I send you a debuggable setup.exe, would you mind running it and getting a back trace? Yeah, I could do that. Actually, I think I duplicated the problem. Stay tuned. cgf
Re: Setup 2.218.2.6 [Was: Re: Setup 2.218.2.4] (new version uploaded)
On Tue, May 14, 2002 at 01:27:46PM -0400, Christopher Faylor wrote:
On Tue, May 14, 2002 at 01:10:05PM -0400, Charles Wilson wrote:
Christopher Faylor wrote:
On Tue, May 14, 2002 at 10:40:19AM -0400, Charles Wilson wrote:
Still doesn't work when installing from a local directory (although it
works fine when installing from internet)
Once it begins parsing setup.ini, it dies almost immediately. But,
there is no warning or error popup.
If I send you a debuggable setup.exe, would you mind running it and
getting a back trace?
Yeah, I could do that.
Actually, I think I duplicated the problem.
Stay tuned.
The attached patch seems to fix this and some other problems.
I've uploaded a new version to sourceware.
At least some of the below should be useful on the trunk, too.
cgf
2002-05-14 Christopher Faylor [EMAIL PROTECTED]
* filemanip.h (trail): Declare.
* filemanip.cc (trail): New function.
(find_tar_ext): Use trail() instead of strstr().
* fromcwd.cc (check_ini): Ditto.
* ini.cc (find_routine): Ditto. Don't tack local_dir to path since it
should now be fully qualified. Set ini_filename. Reset error_buf and
error_count for any subsequent ini file parsing.
(ini_filename): New static variable for parse error reporting.
(yyerror): Use full path of setup.ini in error message. Subtract one
from line number if at bol.
* find.cc (found_part): Eliminate.
(find_sub): Call for_each with full path found rather than just file
component.
(find): Don't calculate found_part.
* inilex.l (ini_init): Flush input buffer and reset line number.
(yybol): New function. Exports YY_AT_BOL.
* iniparse.y: Increase stack depth to allow more tokens to be processed.
(yyparse): Remove newline from error condition to allow subsequent
per-line error processing to proceed normally.
Index: ChangeLog
===
RCS file: /cvs/cygwin-apps/setup/ChangeLog,v
retrieving revision 2.218.2.6
diff -u -p -r2.218.2.6 ChangeLog
--- ChangeLog 14 May 2002 04:32:44 - 2.218.2.6
+++ ChangeLog 14 May 2002 22:45:15 -
@@ -1,5 +1,27 @@
2002-05-14 Christopher Faylor [EMAIL PROTECTED]
+ * filemanip.h (trail): Declare.
+ * filemanip.cc (trail): New function.
+ (find_tar_ext): Use trail() instead of strstr().
+ * fromcwd.cc (check_ini): Ditto.
+ * ini.cc (find_routine): Ditto. Don't tack local_dir to path since it
+ should now be fully qualified. Set ini_filename. Reset error_buf and
+ error_count for any subsequent ini file parsing.
+ (ini_filename): New static variable for parse error reporting.
+ (yyerror): Use full path of setup.ini in error message. Subtract one
+ from line number if at bol.
+ * find.cc (found_part): Eliminate.
+ (find_sub): Call for_each with full path found rather than just file
+ component.
+ (find): Don't calculate found_part.
+ * inilex.l (ini_init): Flush input buffer and reset line number.
+ (yybol): New function. Exports YY_AT_BOL.
+ * iniparse.y: Increase stack depth to allow more tokens to be processed.
+ (yyparse): Remove newline from error condition to allow subsequent
+ per-line error processing to proceed normally.
+
+2002-05-14 Christopher Faylor [EMAIL PROTECTED]
+
* find.cc (find_sub): Be more defensive in preserving trailing parts of
components when doing recursive directory searches or calling user
supplied for_each().
Index: filemanip.cc
===
RCS file: /cvs/cygwin-apps/setup/filemanip.cc,v
retrieving revision 2.6
diff -u -p -r2.6 filemanip.cc
--- filemanip.cc19 Feb 2002 04:33:28 - 2.6
+++ filemanip.cc14 May 2002 22:45:16 -
@@ -72,12 +72,12 @@ find_tar_ext (const char *path)
{
char *end = strchr (path, '\0');
/* check in longest first order */
- char *ext;
- if ((ext = strstr (path, .tar.bz2)) (end - ext) == 8)
+ const char *ext;
+ if ((ext = trail (path, .tar.bz2)) (end - ext) == 8)
return ext - path;
- if ((ext = strstr (path, .tar.gz)) (end - ext) == 7)
+ if ((ext = trail (path, .tar.gz)) (end - ext) == 7)
return ext - path;
- if ((ext = strstr (path, .tar)) (end - ext) == 4)
+ if ((ext = trail (path, .tar)) (end - ext) == 4)
return ext - path;
return 0;
}
@@ -140,6 +140,19 @@ parse_filename (String const in_fn, fil
f.ver = *ver ? ver : 0.0;
delete[] p;
return 1;
+}
+
+const char *
+trail (const char *haystack, const char *needle)
+{
+ /* See if the path ends in a trailing setup.ini component.
+ Just return if it doesn't. */
+ unsigned len = strlen (haystack);
+ int prefix_len = len - strlen (needle);
+ if (prefix_len 0
+ || strcasecmp (haystack += prefix_len, needle) != 0)
+
RE: Setup 2.218.2.4
-Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 9:59 AM Cc: [EMAIL PROTECTED] Subject: Setup 2.218.2.4 ...seems to have problems. Can we please revert to 2.194.2.26 as the production version, until this problem with the 218 branch is corrected? When processing the setup.ini file from a local directory (actually on a remote SMB share), it either a) fails with a popup that says setup.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created. (However, I can't seem to find this error log...) Please run it under DebugView/gdb/Visual debugger and see where the segfault is occuring. or b) consumes memory without bound until it dies with no error message. I never get to see the chooser. Great, we have someone who's seen setup's innards able to reproduce this. I was using a SMB share earlier today, no errors other than two bluescreens (youch, something dodgy with that kernel :}). And no, we can't go back, unless someone (not me) wants to build a 2.194 that won't crash with a yacc stack exhaustion. Rob
RE: Setup 2.218.2.4
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 11:31 AM To: [EMAIL PROTECTED] Subject: Re: Setup 2.218.2.4 On Sun, May 12, 2002 at 07:58:39PM -0400, Charles Wilson wrote: ...seems to have problems. Can we please revert to 2.194.2.26 as the production version, until this problem with the 218 branch is corrected? When processing the setup.ini file from a local directory (actually on a remote SMB share), it either a) fails with a popup that says setup.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created. (However, I can't seem to find this error log...) or b) consumes memory without bound until it dies with no error message. I never get to see the chooser. I'm using W2K. I've noticed the same problem on a non-smb directory, fwiw. dir you mean as in d:\foo or as in NFS mounted? Rob
RE: Setup 2.218.2.4
I also have problems with 'Install from Local Directory'. Setup 2.218.2.4 crashes on W98SE during the scan of the local directory tree with: SETUP caused a stack fault in module MSVCRT.DLL at 0167:7800fca4. Sorry for not being able to provide more information. 'Install from Internet' works fine. Could there be any problems with the combination UPX and initial DLL loading ? 'objdump -p setup.exe' gives funny output for the import address tables. Ton van Overbeek
Re[2]: Setup 2.218.2.4
Hello Ton, Monday, May 13, 2002, 2:45:00 PM, you wrote: TvO I also have problems with 'Install from Local Directory'. TvO Setup 2.218.2.4 crashes on W98SE during the scan of the local TvO directory tree with: TvO SETUP caused a stack fault in module MSVCRT.DLL at 0167:7800fca4. Give me your copy of MSVCRT.DLL (zipped please) in private mail and I'll look into it. Btw you can the setup source from CVS or snapshot and compile with debuggin symbols, then run setup.exe from withing GDB and you'll see where the crash occures.
RE: Setup 2.218.2.4 (fixed?)
Can I suggest that probably setup.exe needs something like a suffix function which operates similarly to strstr but only returns a non-NULL pointer if the string matches the last strlen(string) characters of a path? What's worked well for me in the past in such situations is to just derive a Path class from std::string, and give it members such as GetFilename(), GetFullPath(), etc. I could knock out something analagous pretty quick I should think, maybe consolidating our two string classes (cistring and String) in the process -- Gary R. Van Sickle Brewer. Patriot.
Setup 2.218.2.4
...seems to have problems. Can we please revert to 2.194.2.26 as the production version, until this problem with the 218 branch is corrected? When processing the setup.ini file from a local directory (actually on a remote SMB share), it either a) fails with a popup that says setup.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created. (However, I can't seem to find this error log...) or b) consumes memory without bound until it dies with no error message. I never get to see the chooser. I'm using W2K. --Chuck Here is setup.log.full: - 2002/05/12 19:50:07 Starting cygwin install, version 2.218.2.4 2002/05/12 19:50:07 Current Directory: \\Polgara\private\software\cygwin 2002/05/12 19:50:10 Ending cygwin install -
Re: Setup 2.218.2.4
On Sun, May 12, 2002 at 07:58:39PM -0400, Charles Wilson wrote: ...seems to have problems. Can we please revert to 2.194.2.26 as the production version, until this problem with the 218 branch is corrected? When processing the setup.ini file from a local directory (actually on a remote SMB share), it either a) fails with a popup that says setup.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created. (However, I can't seem to find this error log...) or b) consumes memory without bound until it dies with no error message. I never get to see the chooser. I'm using W2K. I've noticed the same problem on a non-smb directory, fwiw. cgf
