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.
FFJ-dev-010730_1-f4j_ee jdk 1.3.1-b24 linux with 2.4.3 kernel I was doing checkout of all files from :pserver:<user>@fortecvs:/forte4j using the external cvs client. Everything seemed to be working OK, output of the command was being displayed in the dialog box. After quite a long time of successful execution of the command, IDE freezed and a dialog box with the title "Unexpected Exception" appeared. The dialog box was gray - no text in it - and the whole IDE was freezed. There was no text on the console but ide.log file contained many lines with "java.lang.OutOfMemoryError". BTW, there was enough disk space, memory used only in 3/4, swap used in 1/2. I have been running the IDE with -J-Xincgc -J-Xms64m -J-Xmx196m. Setting priority to P1 because the external cvs client is not usable for me.
I had the same problem on Windows 2000 JDK 1.3.1-b24 Forte for Java, CE v. 3.0 (Build 20010725-0210) I try it twise, but I wasn't successful. For every time I saw the exception window with java.lang.OutOfMemoryError and IDE was freezed. I have machine with 390MB RAM
did the checkout finish (did you get all the files)? Using simultaneously javacvs by any chance? were the annotations updated or were all files "local" when you restarted the IDE? BTW: Isn't P1 a "bit" exxagerated?
No, of course, not all the files were checked out! I had to kill the IDE and the command was killed with it! No, I was not doing or using anything simultaneously. What else than P1 should it be if I cannot use the module...? BTW, don't you store the whole output of the command in the JTextField (or whatever it is in the dialog box)? There was a lot of output from the command - maybe it used up all the memory...
maybe... BTW there's a workaround: checkout single modules... with a workaround, it's usable again :)
Tondo, you said: "I had to kill the IDE and the command was killed with it!" I don't understand how it happend. That can't be simply true. I can't believe in it. This is a one of a big advantages when the ide crashes or whatever, the external proccess will not died. I'm realy currious in the way how did you kill the ide? Pls, be as much exact as it is possible:-) thanks
Well, I am sorry but it is true. No cvs process is running and the checkout is at the same point where it stopped. I killed the IDE by killing its console.
O.K., we can do a limited fix to Pilsen: 1) disable Data output and Data error output for the CHECKOUT command. This will double the amount of data, that can be processed. 2) Set a limit of lines, that can be shown in the Output Window. This limit will be hardcoded to 5000 lines, because it's too late to create a property for that. These two changes should fix the problem. If you agree with this solution, I'll do the fix in the main trunk and if it will work right we can ask for the approval to merge it to Pilsen.
Fine. I think this fix is good for Pilsen. I understand there is not enough time now to make a UI change and create an option for it. This fix is much better than letting the checkout output overflow the memory. BTW, wouldn't there be similar problem with UPDATE or other commands?
I think, that checkout produce the largest amount of data. Update only prints the updated files. But, yes, we can extend this also for the update command and import, export commands. I can easily disable the Data output for these commands. The limit in the Output Window will apply to all commands.
Fixed in the main trunk. Can you verify the fix in dev build 20010801? Diff: http://vcscvs.netbeans.org/source/browse/vcscvs/src/org/netbeans/modules/vcs/cmdline/CvsFileSystem.java.diff?r1=1.134&r2=1.135 http://vcscore.netbeans.org/source/browse/vcscore/src/org/netbeans/modules/vcscore/commands/CommandsPool.java.diff?r1=1.3 0&r2=1.31 http://vcscore.netbeans.org/source/browse/vcscore/src/org/netbeans/modules/vcscore/commands/CommandOutputVisualizer.java. diff?r1=1.6&r2=1.7
I have verified the fix in today's dev build 20010801. The fix works OK - I was able to checkout everything without the OutOfMemoryError. Please, put it also to {pilsen_fcs}.
I'm downgrading the Priority to P2 (rather P3?) 'cause I think it is not so blocking bug as reporter said. IMHO this bug has been already reported but by our misstake hasn't been correctly set as a Pilsen bug too. And it was partialy fixed in dev.Today is fixed in dev [Nbdev-200108010100] and we'll play with it little bit to asure that it is realy fixed. This bug can occure only under special circumstance: Checking out the content of a realy huge repository. Workarounds might be: checking out it by smaller pieces (smaller modules) or/and add extra RAM (sorry for that, but it realy might help)
I have to admit that I was also able to reproduce it on my Win2K machine with 400 MB RAM after "Refresh Recursively" repeated 15 times. On the other hand although my IDE took 95% of CPU I was successful with normal exit and therefore no killing was necessary however I had to be pretty patient and try more attempts. :-) I would also like to stress that the fix integrated yesterday by Martin to development builds of NetBeans is NOT ideal and in fact is a hack. I consider storing outputs into files as the best solution instead of using memory and therefore personally don't recommend this fix to integrate to Pilsen.
I agree with Jirka. Since the output of the commands is stored permanently during the session now. (because of the runtime tab and the command history there). So a bigger amount of commands with smaller output can have same effects as one command with huge output.
last comment is mine :)