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.
When searching the java classes of my project for 2 or more successive characters (ex : "AA" or "###", the IDE gets in an endless loop (100% CPU). Quite annoying I must say.
NetBeans version, number, JDK ? Search in Editor or Search in Project, or Search on FileSystem ?
Additionnal info : version : Netbeans IDE 3.4 but its the same on the older version. jdk : 1.4.1-rc but it's the same for 1.4.0 search in project (works in editor)
Please, could you attach (as file) thread dump stack (Ctrl+Break on java console) while searching? Thanks.
Could you be a little more precise ? I don't have any java console open when running Netbeans.
Please, run 'netbeans/bin/runide.exe' - it opens console.
Sorry but I manage to make the console appear only when launching applets through a browser. Launching runide.exe directly doesn't make the console appear. Note : I'm under windows XP. Any Idea ?
Do you really run runide.exe, is not runidew.exe? If so, try to run runidew.exe and let me know. Thanks a lot.
Well, maybe you mean by "console" the simple DOS window ? I was looking for somme sort of real console like the one which appears when launching and applet (and the option being checked in the configuration panel of windows). If it is this, you will be disapointed because the only feedback I get from Netbeans is this : -------------------- C:\Java\netbeans\bin>runide Type Groups Level Module Name ---- ------ ----- ----------- err * 255 * (Default) ^C C:\Java\netbeans\bin> -------------------- In fact, Netbeans takes 100% CPU but it is not freezed, I can still use it (sort of) and close it. But it doesn't give any result. I can even launch another search but there's still some loop in the backround that eats all my CPU.
OK, in your DOM window type "Ctrl+Break" and it will print "Full thread dump" to the window. Please attach this listing as separate file to this issue. Thanks.
Created attachment 7615 [details] The thread dump while netbeans is in the endless searching loop.
Ah, you mean Ctrl + "Arrêt défil" :-). Ok, I finally got it. thanks for taking care of this problem.
Wait, more probably Ctrl + "pause attn". Other file is comming.
Created attachment 7616 [details] The Full thread dump while netbeans is in the endless searching loop.
Thanks.
Provide exact steps to reproduce. I am not able to reproduce this bug.
I just made some more test and here is what I found. First, the symptoms : when I do a "Find" on one of my packages in my project, I don't get any result, CPU gets at 100%, and stays there even if I close NetBeans. It seams this is due to a BMP file in one of my packages. I though it was a more general problem. Do you want me to attach the file (900 KB) ? I still don't see why this is causing an endless loop. I must say I would never have thought that the search even went into image files...
I have tried it on Solaris (Solaris 8, NetBeans 3.4, JDK 1.4.0) and searching worked. Maybe it happens just with your project. Could you try to: - invoke search from the "Filesystems" tab of the Explorer - run NetBeans with a clean user directory and run search on directory "examples"?
I have made extensive tests and it is really weird : it happens only with one specific bmp file. Whatever the search I do, on whatever directory (tested also on only one directory with one file : the image file), I get the endless loop. Other bmp files work alright, jpg also. I try to attach the bmp file if you want to test it. Thank you for looking into this but since it âppears to be only a very specific problem, maybe it isn't worth it. I just have to encode this file in jpg. I nevertheless find it strange that the search for a string looks into image files.
Created attachment 8489 [details] the bmp file wich is causing the problem
Since the problem is specific to a single file, I lower the priority. Jean-Pierre, consider using format GIF or PNG instead of JPG. The file will be smaller and will preserve the original image quality (JPG is good for photos, not for technical drawings). Btw. BMP is the worst image format I know for storing large images.
Thanks for the tips but in fact, I'm allready using GIFs most of the time, JPG for some specific images. This BMP comes from a screenshot and has in fact allready been converted and transformed. I only kept the BMP as a backup. But I still find it strange that some file (whatever the type) can cause an endless search loop... And it did cause me some trouble for month because I couldn't find any solution, never thinking a single file could be the problem. OK for the low priority, but I'm still curious about this bug.
Jean-Pierre, I just reproduced the bug. I will look at the problem. For the next bug reports, please do not attach large attachments (the image has over 770 kB) or compress the attachments first (the image has approx. 40 kB if packed with "zip").
There are two major problems: - images are search as it were text files - the searching algorithm is very inefficient The searching algorithm has two problems: - it is primitive, i.e. it uses the simpliest mechanism when searching multiple matches (when a match is found, move one character forward and search again) - when performing case-insensitive search on a single string, the string is upper-cased each time a match is found When combined together, searching in a .bmp file can take up to several hours, depending on its size and power of the computer.
This bug is fixed now since the search feature does not "freeze" when searching image files (thanks to the simple patch which prevents multiple transformations to uppercase when multiple matches are found on a line). But there is still a problem that image files are searched by default even if looking for text. But this is another issue - already registerd: 30345 - "search filesystems" should restore type automatically 23584 - search filesystem should not search binary / class files
Cool. Thx.
[200306020100], jdk1.4.1_02 Verified on attached bmp file.