This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] Re: Setup.exe 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 ( 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,
          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  <>

            * (parse_filename): Do not try to parse empty
            strings (filenames).
            * (packagedb::packagedb): For each line check if sscanf()
            extracted good package name and filename.

This patch is against It should apply to the HEAD too.

Description: Binary data

Description: Binary data

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]