Possible Windows Build Bug
Zachary Greve
ztgreve at live.com
Mon Jun 22 18:20:06 EDT 2015
It happens when building list files for AES, DSA, and so on. Which one it crashes on is different each time.
I am going to try building again and see what I get.
> Date: Mon, 22 Jun 2015 17:27:56 -0400
> From: kaduk at MIT.EDU
> To: ztgreve at live.com
> CC: kerberos at MIT.EDU
> Subject: Re: Possible Windows Build Bug
>
> On Mon, 22 Jun 2015, Zachary Greve wrote:
>
> > In the echo_files method in the libecho utility there is a line that reads:
> >
> > ff = _findfirst(f, &fdt); // line 64
> >
> > which errors out with an access violation in ntdll.dll.
>
> Can you say a bit more about where this crash is observed? E.g., during a
> build of what version of the krb5 tree (where in the build?), using which
> compiler and windows SDK version, etc..
>
> > Changing the line to read:
> >
> > ff = _findfirst(filepath, &fdt);
> >
> > fixed the issue.
> >
> > Is this a bug?
>
> This piece of code is (very old and) written in a rather strange way, but
> I am not convinced that your propsal is a correct fix to the bug, if one
> is present.
>
> The purpose of this utility is to expand wildcards in a given path
> expression (it is only used in two makefiles in the tree). There seems to
> be an implicit assumption that the wildcard will only occur in the last
> path component. The _find() family returns only the matched filename
> (without directory), so libecho requires a copy of the containing
> directory as well as the full path (i.e., wildcard expression) in order to
> fulfil its purpose of printing out all matches to the wildcard. The
> directory is stored in the 'filepath' variable, whereas the wildcard
> expression is in 'f'. So, I think the _findfirst() call should use f, not
> filepath.
>
> I think we need to hear more about the crash and the context of the failed
> call in order to say what's going on here.
>
> -Ben Kaduk
>
> P.S. kfwdev@ might be a better list to discuss this on.
>
More information about the Kerberos
mailing list