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: ka...@mit.edu > To: ztgr...@live.com > CC: kerberos@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. > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos