This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH] Re: Setup.exe 188.8.131.52 crashing under Windows NT 4.0 SP6
- From: "Robert Collins" <robert dot collins at syncretize dot net>
- To: "Pavel Tsekov" <ptsekov at gmx dot net>,<cygwin at cygwin dot com>
- Date: Thu, 4 Jul 2002 08:42:15 +1000
- Subject: Re: [PATCH] Re: Setup.exe 184.108.40.206 crashing under Windows NT 4.0 SP6
- References: <firstname.lastname@example.org>
Thanks Pavel, nice catch.
I've applied this to HEAD and 2002-07. This evening I'll get 2002-06 done
and release a new setup.exe
----- Original Message -----
From: "Pavel Tsekov" <email@example.com>
Sent: Thursday, July 04, 2002 5:33 AM
Subject: [PATCH] Re: Setup.exe 220.127.116.11 crashing under Windows NT 4.0 SP6
> 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 (18.104.22.168) 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;
> srcsz = 0;
> sscanf (line, "%s %s %d %s %d", pkgname, inst, &instsz, src,
> 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
> 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 <firstname.lastname@example.org>
> * filemanip.cc (parse_filename): Do not try to parse empty
> strings (filenames).
> * package_db.cc (packagedb::packagedb): For each line check if
> extracted good package name and filename.
> This patch is against 22.214.171.124. It should apply to the HEAD too.
> 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/
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html