Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
File::Stat.new() issue in 1.7.23 on Windows 7 #3525
I have been investigating a Logstash issue with the file input on windows 7 x86.
Se this JVM error log at https://gist.github.com/ph/c0dcc55573337a8d2296
When we try to use the
Few points that I know:
I have tried to create a simple test case outside of Logstash without luck so far.
@ph hmmm this is pretty weird. It sort of sounds like some race exists where FindFirstFileW thinks something is there and then it really isn't and it crashes. I am wondering if there are any issues in MSDN (or however bugs are tracked in Windows) about FindFirstFileW. It is a little odd to be seeing this problem since this is a very common API call in Windows.
Hmm I might have had a breakthrough! https://msdn.microsoft.com/en-us/library/windows/desktop/aa364946%28v=vs.85%29.aspx
Check out this section on transactional support:
If a file is open for modification in a transaction, no other thread can open the file for modification until the transaction is committed. So if a transacted thread opens the file first, any subsequent threads that try modifying the file before the transaction is committed receives a sharing violation. If a non-transacted thread modifies the file before the transacted thread does, and the file is still open when the transaction attempts to open it, the transaction receives the error ERROR_TRANSACTIONAL_CONFLICT.
@ph the logstash script you have that reproduces this that I can run locally on my win7 windows machine?
ignore my last two comments. I had not looked at the actual crash dump since before I left for Japan and I realize I should have :)
So, I was spending time this afternoon looking at GetFileAttributesExW when the crash is happening after that call in the failure branch in FindFirstFileW. So this bug just got much different and hopefully will get some traction now that I am actually looking at the right method :|
I can reproduce this problem entirely within jnr-posix now. If I create a temp file via java.io.File then FindFirstFileW will crash the JVM. If I access the parent directory of that file then the call passes. I would expect some all or nothing behavior unless some fields are layed out wrong WindowsFindData and directories are not trying to write to those fields somehow??? Anyways this is good new since I have something local which is broken.
This particular bug was not occurring very often because it is only called on a failure from GetFileAttributesExW. So, in other words, only in a weird case.
added a commit
Jan 12, 2016
I think I got it for realsies this time. I cannot reproduce on 32 bit JVM running the logstash example now but I would love to get confirmation this is good with logstash now. (I just ran nightly so that link should be latest version)