Build 3245: need your help to find bugs Follow
Hello, All,
In build 3245 just released we have significantly reworked the internals of VFS implementation (the reason is the huge delays when working with Idea on linux with lots of automounted disks). For the whole of last week I've been struggling with bugs caused by this refactoring. While I did my best to get it bug free, there is a horribly large possibility of some bugs being still there. I would greatly appreciate your help in pointing this out.
Thank you in advance,
Eugene.
Please sign in to leave a comment.
The first bug: 5245, not 3245 ;)
It only shows there are others as well...:)
How do I test the VFS implementation? What kind of operations would be affected by the VFS implementation? What kind of symptoms could bugs there have? Wrong file locations? Incorrect file contents? Data loss? Exceptions? Something else? How would I know this is caused by the VFS implementation?
I have basically no idea how to help you test this. Even only a few examples of bugs you have already fixed would help greatly.
Bas
All you mentioned and more. The bugs I have already encountered include duplicate classes in the project view, different assertions from write psi actions and slow file synchronization.
Real first bug? ;)
http://www.jetbrains.net/jira/browse/IDEA-7521
This might be related. I get the exceptions below every time I open my project.
Bas
Nope, this is not related, I'll look at this on Monday (since this exception will be assigned to me anyway:)
Eugene.
It would be interesting to get guess of the possibility of
data-corruption or loss, so we can plan on "backups" - otherwise I'd
tend to not use 5245 "really" (?) but then nothing will be tested... I
found this thread rather "frightening" in that I really thought about
not upgrading to 5245 - curiosity won, however ;)
Still would appreciate the guess.
regards,
Messi
Eugene Vigdorchik wrote:
Just a guess, but... Is your project referencing idea.jar? If this is the case, then the reason of the problem is probably our obfuscator.
Yes, you guessed right, it's a plugin.
This is fixed.
Cool, thanks Eugene!
Eugene Vigdorchik wrote:
Hello eugene, this sounds exciting, do you plan to use FAM and inotify
as well? I've written a script that simulates OSX fslogger for
inotify-enabled kernels.
There are no plans to support native watching with linux in 6.0.
What if I duplicate the fslogger output exactly so you don't need to
write any new code?
Eugene Vigdorchik wrote:
That would definitely make my life easier:)
But how your script is going to be distributed/setup?
Eugene Vigdorchik wrote:
We would kill for this functionality here so we would be willing to do
all the work for setup, support, etc. We would be okay if this were
secret feature disabled by default. The script depends on inotify and
python-inotify, which are generally not available and/or installed by
default for all linuxes.
I could make fslogger-compatible, but currently I provide simpler interface:
C xx.xxx = file created
M xx.xxx = file modified
D xx.xxx = file deleted
fslogger looks more complex. However if you want compatibility I will do it.
Can your script check for all prerequisites like inotify itself? If yes then it would be safe to distribute it with idea and only watch with its help when it explicitly says so.
What's a prerequisite?
Eugene Vigdorchik wrote:
Oops, sorry for my bad English.
I meant could the script check for kernel inotify-enableness and possibly other stuff it needs itself?
Eugene Vigdorchik wrote:
Yes, the script would simply quit or print some error code if it doesn't
work.