This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[ JDK VERSION : J2SE 1.4.2_02 ] I searched for this bug, but could not find it. I remember that the bug is filed so if it's a duplicate, sorry and close it. After working in the editor I cannot save the file. attaching ide.log
Created attachment 13696 [details] ide.log
It seems like 3rd party module (struts support from James Holmes) caused the problem. (assuming that it was not rewritten to use new windowing system) Assigning to core for evaluation.
the window system exceptions in the log are related to issue #40624. IMHO these cannot cause the described problem of not being able to save the file. moving to editor for evaluation. Justification: The user describes that he/she was working in the editor.
Not sure why there is that invalid lock exception. Reassigning to openide/filesystems for evaluation.
Known problem with FileEntry.takeLock: one instance of FileLock is distributed from FileEntry and is shared between independent pieces of code. As soon as one ownere of lock releases it the others keep invalid locks.
But: 1. the exception is thrown because of null lock (see MultiFileObject.java:528) 2. DES is already (from 17/2/2004) checking lock presence and validity (see DataEditorSupport.java:402-404) so the only way it can pass null or invalid lock is to obtain it from takeLock() method JavaEditor takes lock through EditorSupport from MultiDataObject MDO does its own caching and validity check, so it can only pass null lock if it gets it from FileObject. BTW: The Entry.takeLock Javadoc is wrong, it states it can return null, but it shouldn't. Can the FIleObject actually return null lock?
Radek, can you look at it more? I don't see how it can happen now (after 25/2/2004) Vano, is it reproducible? If it is, I can provide a debugging patch and we may be able to nail it down even for 3.6 If you can't reproduce it, please downgrade it to P3 and mark it with RANDOM keyword. Without more info I can't target the fix for 3.6
DES:405 - getFileImpl ().getOutputStream (fileLock) MFO.testLock:528 - if (lock == null) FSException.io ("EXC_InvalidLock" .. [simplified] So, in MFO.testLock is compared "lock" with "fileLock". But first must be true that MFO is ever locked (lock != null) which isn't true according attached stacktrace. --- Result: Attached ied.log comes from 20/2/2004. I think your fix (25/2/2004) should help - at least decrease probability . Priority decreased to P4 because your fix isn't 100%. Test lock for validity and its usage must be atomic and exclusive which currently isn't. But please if you can reproduce or it occures regularly (on last dev builds) then please don't hasitate and increase priority again !
It happened again. using Q-build 200403040727. This bug dirves me crazy. I lost 100 lines of code because of this!!! I know we're in a high resistance mode but this bug MUST be fixed by 3.6 If needed (nobody's going to fix this bug by 3.6) I will call for NetCat participants to vote. and fix this bug.
Created attachment 13893 [details] ide.log
Created attachment 13894 [details] please disregard the previous ide.log. Now attaching the real one.
Vano, do you have steps to reproduce? Start with new userdir .... Thanks for help .....
OK, I've just commited a workaround to dev trunk.
Created attachment 13922 [details] Used workaround
Yarda, could you please review the workaround while Radek is on vacations?
Created attachment 13938 [details] Fixed diff. The previous one was wrong (bad placement of toString method)
The fix definitively improves the current state.
Integrated into release36 openide/src/org/openide/filesystems/MultiFileObject.java,v1.114.4.1 openide/loaders/src/org/openide/text/DataEditorSupport.java,v1.13.4.1
Vano, can you reproduce it now ? If so reopen , thanks in advance.... I can't - verified in [nb_36_rc1](20040313-0952)
NetBeans 3.6 RC1 Emptry userdir: Generated a property from bean patterns node. The file can not be saved. Just a comment: This bug happened only after some action: 1. Import Wizard 2. Generate property from bean patterns node It does not happen if I don't use above actions. Hope this will help.
Created attachment 14092 [details] ide.log
Thanks for the report. With the improved debugging info I put into code last time it points to a problem in filesystems. Radku, please note that the lock I'm passing thinks it is valid (it things so even after throwing the exception as is visible from: "org.openide.filesystems.MultiFileObject$MfLock@2023c2 for com/silkroad/srm3/form/ChargeForm.java valid=true" What is very suspicious to me is that o.o.f.FileLock contains no synchronization at all, but that don't necesarilly have to be the problem.
New high priority issue in release36, cc-ing interested parties.
Created attachment 14096 [details] Here is hot fix. Please test it if you can
I don't use cvs version. What is the shortest way for me to test the hotfix? If it's necessary I will try cvs version
Radek or Petr, please provide a binary patch for testing. Thanks.
Created attachment 14102 [details] Binary patch for ../netbeans/lib/patches
This hotfix seems very safe to me. To be clear, it is a workaround that makes the behaviour of the MfLock consistent even when its internal structures go out of sync. This way, should anything go wrong, it will trigger the workaround I've integrated before and allow transparent handling of the internal inconsistency.
This happened again event after applying binary patch. So now it's another exception FileAlreadyLockedException. attaching ide.log
Created attachment 14119 [details] ide.log
I believe I've found aprobable scenario on what is going on inside to trigger this problem: 1. something acquires a lock on MFO (which locks the delegate) 2. it releases the reference to it without releaseLock() 3. gc occurs, clears the MFO.lock weak reference and puts the MfLock in the finalization queue. 4. editor locks the MFO again (works because the lock.get() gives null result) 5. finalize() on the first MfLock is performed, clears the reference to the second lock. 6. editor tries to get OutputStream, passing the second MfLock, which has valid = true, but the MFO doesn't know it now (because of step 5) This is what I realized before reading your last report. There is still one thing missing in the scenario, and that is how can it get new MfLock in step 4, when the delegate file should be still locked. Possible explanation is that the sublocks ("GCed" now) were put into the finalization queue before the MfLock...
Created attachment 14120 [details] This example may be interesting for better understanding of finalization.
You are definitely right. I played with the same idea. I'll attach binary patch which should solve this problem. But the primary culprit is unknown code that gets FileLock , doesn't release it and then let it garbage collected - I add into patch also diagnostic that should reveal who is responsible.
Created attachment 14124 [details] Binary patch
Created attachment 14125 [details] Here is diff related to last binary patch
I deleted old fs.jar from lib/patches and put new fs2.jar there. Is it right?
Yes.
Vano, can you please test the patch and let us know the result? We are very close to the release deadline and would like to resolve this issue asap. Thanks
I'm currently testing it. No problems so far. Could you please tell me the timeframe for testing and I will close it by that time if there is no problems.
Timeframe: ASAP This patch also contains some diagnostic ( lockedByTrace.printStackTrace(System.err) in lock.diff attachment) - I'm eager to know if there is any ouput of it.
I looked at ide.log and discovered lot of exceptions there. I think it's your diagnosed exceptions. attaching ide.log
Created attachment 14184 [details] ide.log
Two things: 1. The debugging part (which won't go to rel36 anyway) is wrong, it fails to filter only the problematic locks. This is why there is so many entries in the log (false alarms) ;-( 2. I'd place the delegate releasing out of the conditional block, as the condition will always be false during finalize (reference already cleared), but it would be nice to speedup releasing the delegates. Note: they should be released from their finalize() as a result of the same GC run, so it should make very little difference.
>Two things: >1. The debugging part (which won't go to rel36 anyway) is wrong, it > fails to filter only the problematic locks. This is why there is so > many entries in the log (false alarms) ;-( > You are right, I'm aware of it. >2. I'd place the delegate releasing out of the conditional block, as > the condition will always be false during finalize (reference already > cleared), but it would be nice to speedup releasing the delegates. > Note: they should be released from their finalize() as a result of > the same GC run, so it should make very little difference. > I agree. So, I''ll ask for review today, prepare new patch for release36 without diagnostic and including integration of your 2. comment. So, I hope you will review this patch. Then I prepare one binary patch just for testing - this patch will include integration of both your comments. I hope Vano will review this binary patch and will provide output of it.
Fixed into trunk. /cvs/openide/src/org/openide/filesystems/FileLock.java,v <-- FileLock.java new revision: 1.12; previous revision: 1.11 /cvs/openide/src/org/openide/filesystems/MultiFileObject.java,v <-- MultiFileObject.java new revision: 1.118; previous revision: 1.117
Created attachment 14191 [details] Patch for nb36 - please review (without diagnostic)
Created attachment 14194 [details] Binary patch - Vano please could you test with this binary patch again and provide output of it.
I've reviewed the last patch.
I plan to integrate reviewed patch into nb3.6 today.
I'm testing fs3.jar patch and no problems so far.
Fixed into release36. /cvs/openide/src/org/openide/filesystems/MultiFileObject.java,v <-- MultiFileObject.java new revision: 1.114.4.2; previous revision: 1.114.4.1
old issue without any news - closed