Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Wed, 3 Jul 2002 21:33:49 +0200 From: Pavel Tsekov Reply-To: Pavel Tsekov X-Priority: 3 (Normal) Message-ID: <878516866.20020703213349@gmx.net> To: cygwin AT cygwin DOT com Subject: [PATCH] Re: Setup.exe 2.249.2.4 crashing under Windows NT 4.0 SP6 X-Sender: Pavel Tsekov MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------60CEF717905BC2" Note-from-DJ: This may be spam ------------60CEF717905BC2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, there! :) Friday, June 28, 2002, 7:26:59 PM, Jim wrote: JG> I've been running Cygwin for some time now. Today I went to upgrade my JG> various packages and found that a new version (2.249.2.4) of setup.exe JG> was available. It starts normally, but when I try to make a selection JG> from "Install from Internet", "Download from Internet", and "Install JG> from Local Directory", I get an error dialog: JG> The instruction at "0x78001d22" referenced memory at "0x00000000". JG> The memory could not be "read". JG> followed by the usual "OK to terminate, Cancel to debug" choices. JG> The dialog pops up as soon as I try to change which radio button is JG> selected, or if I leave the default choice and hit "Next>". I've asked the user to send me his msvcrt.dll and found that the exception occures in strcpy (). The only suspicious code which is executed when the user changes the selections is the constructor of the packagedb class. The only place where strcpy() is called (indirectly) not safe, in the constructor is the following snippet: int parseable; src[0] = 0; srcsz = 0; sscanf (line, "%s %s %d %s %d", pkgname, inst, &instsz, src, &srcsz); fileparse f; parseable = parse_filename (inst, f); parse_filename () calls strcpy () like this: parse_filename (String const &in_fn, fileparse & f) { char *p, *ver; char fn[in_fn.size() + 1]; strcpy (fn, in_fn.cstr_oneuse()); Consider that for some reason the sscanf call doesn't succeed (empty line in installed.db). In this case pkg name would contain garbage data. Now if the first char of the garbage data happens to be a null character, the code will crash in parse_filename. I know that the possibility this to happen is very low, but it seems that for the original poster the crash was happening every time. A requirement for this bug to show up is that installed.db file should be corrupted in some way. I requested the file, but I was sent the file which resulted after a succesfull installation (performed by a patched setup.exe). I suggest the attached patch to guard against such problems. Btw as I mentiond above I've sent a patched setup.exe to the user and he confirmed that it fixed the problem. The attached patch is different from the one I originally applied, but it just addresses the problem in a better way. 2002-07-03 Pavel Tsekov * filemanip.cc (parse_filename): Do not try to parse empty strings (filenames). * package_db.cc (packagedb::packagedb): For each line check if sscanf() extracted good package name and filename. This patch is against 2.249.2.4. It should apply to the HEAD too. ------------60CEF717905BC2 Content-Type: application/octet-stream; name="filemanip.cc.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="filemanip.cc.patch" LS0tIGZpbGVtYW5pcC5jYy5vcmlnCTIwMDItMDctMDMgMjA6NDY6MTQuMDAwMDAwMDAwICswMjAw CisrKyBmaWxlbWFuaXAuY2MJMjAwMi0wNy0wMyAyMDoxOTo1NS4wMDAwMDAwMDAgKzAyMDAKQEAg LTg0LDE4ICs4NCwxOCBAQCBpbnQKIHBhcnNlX2ZpbGVuYW1lIChTdHJpbmcgY29uc3QgJmluX2Zu LCBmaWxlcGFyc2UgJiBmKQogewogICBjaGFyICpwLCAqdmVyOwotICBjaGFyIGZuW2luX2ZuLnNp emUoKSArIDFdOwotICBzdHJjcHkgKGZuLCBpbl9mbi5jc3RyX29uZXVzZSgpKTsKLSAgCi0gIGlu dCBuID0gZmluZF90YXJfZXh0IChmbik7CisgIGNoYXIgKmZuOworICBpbnQgbjsKIAotICBpZiAo IW4pCisgIGZuID0gaW5fZm4uY3N0ciAoKTsKKyAgaWYgKGZuID09IDAgfHwgIShuID0gZmluZF90 YXJfZXh0IChmbikpKQogICAgIHJldHVybiAwOwogCiAgIGYudGFpbCA9IGZuICsgbjsKICAgZm5b bl0gPSAnXDAnOwogICBmLnBrZyA9IGYud2hhdCA9IFN0cmluZygpOwogICBwID0gYmFzZSAoZm4p LmNzdHIoKTsKKyAgZGVsZXRlW10gZm47CiAgIGNoYXIgY29uc3QgKmV4dDsKICAgLyogVE9ETzog bWFrZSBjb25zdCBhbmQgbm9uLWNvbnN0IHRyYWlsIHZhcmlhbnQuICovCiAgIGlmICgoZXh0ID0g dHJhaWwgKHAsICItc3JjIikpKQo= ------------60CEF717905BC2 Content-Type: application/octet-stream; name="package_db.cc.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="package_db.cc.patch" LS0tIHBhY2thZ2VfZGIuY2Mub3JpZwkyMDAyLTA3LTAzIDIxOjEzOjUyLjAwMDAwMDAwMCArMDIw MAorKysgcGFja2FnZV9kYi5jYwkyMDAyLTA3LTAzIDIxOjE2OjU1LjAwMDAwMDAwMCArMDIwMApA QCAtNzUsMTAgKzc1LDE4IEBAIHBhY2thZ2VkYjo6cGFja2FnZWRiICgpCiAJICAgICAgd2hpbGUg KGRiLT5nZXRzIChsaW5lLCAxMDAwKSkKIAkJewogCQkgIGludCBwYXJzZWFibGU7Ci0JCSAgc3Jj WzBdID0gMDsKKwkJICBzcmNbMF0gPSAnXDAnOworCQkgIHBrZ25hbWVbMF0gPSAnXDAnOworCQkg IGluc3RbMF0gPSAnXDAnOwogCQkgIHNyY3N6ID0gMDsKKwkJICBpbnN0c3ogPSAwOworCiAJCSAg c3NjYW5mIChsaW5lLCAiJXMgJXMgJWQgJXMgJWQiLCBwa2duYW1lLCBpbnN0LCAmaW5zdHN6LCBz cmMsCiAJCQkgICZzcmNzeik7CisKKwkJICBpZiAocGtnbmFtZVswXSA9PSAnXDAnIHx8IGluc3Rb MF0gPT0gJ1wwJykKKwkJCWNvbnRpbnVlOworCiAJCSAgZmlsZXBhcnNlIGY7CiAJCSAgcGFyc2Vh YmxlID0gcGFyc2VfZmlsZW5hbWUgKGluc3QsIGYpOwogCQkgIGlmICghcGFyc2VhYmxlKQo= ------------60CEF717905BC2 Content-Type: text/plain; charset=us-ascii -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ------------60CEF717905BC2--