git show with --date=format:%F dies with out-of-memory error

[snaewe]

• I was not able to find an open
  or closed issue
  matching what I'm seeing

Setup

• Which version of Git for Windows are you using? 32-bit or 64-bit? Include the
  output of git version as well.

git 2.9.3(2) 64bit

$ git --version
git version 2.9.3.windows.2

• Which version of Windows are you running? 32-bit or 64-bit?

Win7 64bit

• What options did you set as part of the installation? Or did you choose the
  defaults?

$ cat /etc/install-options.txt
Path Option: Cmd
SSH Option: OpenSSH
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

No.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git init -q demo ; cd demo ; git commit -q --allow-empty -m "empty" ; git show -s --date=format:%F --pretty='format:%h (%ad)'

• What did you expect to occur after running these commands?

I expected to see something like:

086cb71 (2016-08-29)

like I did on another Linux system.

• What actually happened instead?

After a couple of minutes (while my system was swapping itself to death....) the output inside of bash was:

fatal: Out of memory, realloc failed

Seems to be a problem with strftime() returning 0 for invalid/unknown format specifiers (%F that is).

[snaewe]

I had the chance to test this on a 32bit XP System with git 2.9.3.windows.2.
The output of git show... (as above) is something like:

086cb71 ()

It seems the invalid or unknown format specifier is ignored by strftime() in this case.

[landstander668]

For what it's worth, I'm not able to reproduce this problem using Git 2.9.3 64-bit on Ubuntu. So it does appear to be specific to Git for Windows.

[dscho]

Indeed, this is a Windows-specific behavior: https://msdn.microsoft.com/en-us/library/fe06s4ak.aspx

Please note that by using strftime(), we buy into this problem, as a return value of 0 is ambiguous. Setting aside that it indicates parameter validation errors on Windows, it also can mean both "out of memory" as well as "the length of the formatted date is 0".

Not sure how to proceed with this... 😦

[snaewe]

Hhhmmm....did you read the paragraph that mentions "Parameter Validation" ? Does _set_invalid_parameter_handler get called by the MSYS-runtime ? Maybe it's enough to simply check errno. I'll try that....

[snaewe]

And indeed!
Using this test of strftime gives an
'errno: 22' for an invalid format specifier ('%_' for example).
I tried that on a 64bit Windows 7 system and used the compiler from here (because I have no possibility to download the complete g4w SDK.)

[dscho]

@snaewe yes, I read that. The problem is that it is undefined whether errno is set in case of success.

Imagine an implementation of strftime() that relies on some other functions in libc. Now imagine that one of those functions sets errno and strftime() handles that correctly and returns with 0 to imply that the buffer is too small. That is perfectly legal, according to POSIX.

So we cannot rely on ret == 0 && errno implying that there was an error (except maybe on Windows).

I guess I really have to bite the bullet and set a handler that die()s. Not pretty, but it'll do the job of fixing the bug you encountered...

[dscho]

Could you give https://github.com/git-for-windows/git/releases/tag/prerelease-v2.10.0.windows.1.11.geda474c a try?

[snaewe]

Will do. But have to wait till monday ...