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.
Summary: | Custom ANT target Postprocess hangs build (infinite loop) | ||
---|---|---|---|
Product: | www | Reporter: | Max Lobel <axobel> |
Component: | Builds & Repositories | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jtulach |
Priority: | P3 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Windows ME/2000 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Replaces strings in binary files. Fixed infinite loop problem.
Working Postprocess.java for Windows 2000 w/default Japanese encoding. |
Description
Max Lobel
2001-11-11 05:59:10 UTC
Created attachment 3356 [details]
Replaces strings in binary files. Fixed infinite loop problem.
I don't believe there is anything wrong with the code as it stands; if i is not -1, then that match should be replaced with newString before the next loop iteration and not match again. Of course it would not hurt to start the search at i+1 for speed, but it should not be required. There have been no other reports of such a hang, so I assume you have made some sort of other modification to the NetBeans sources; if so, what is it? [BTW next time please include a cvs diff -u patch from recent sources rather than a modified copy of the file, it is easier to look at and also safer in case the file is changed after you file a report.] Max writes: Shortly after I entered the issue I realised that the code is fine *albeit, inefficient(... Not only that, but if it wasnt, what would it even become a beta version(. The problem is much deeper, I&m afraid, and has to deal with system locale and language - at least on Windows 2000 *x2( and Windows Me on which myself and colleages have attempted to perform a build. As I mentioned in the reply to the reply that you sent, I live in Japan and use Windows 2000 for development and AIX on an RS6000 for deployment. Using ant, I have a build script for both Tomcat and WebSphere *on which our applications are deployed( and I use Netbeans for development, then deploy to WebSphere with about a 95% chance that the application will run well - completing the development and testing on the WebSphere server. I am a Netbeans, and open-source fan. I love the product and have always wished to contribute at least something to the project.... So here I am.. The main subject of the issue that I entered is not far from the truth. The Netbeans build hangs during the build of the openide, while it is running the compile-preprocessed target in Postprocess.java *org.netbeans.nbbuild package(. This has nothing to do with the code!! The fault lies solely in System.arraycopy*newString.getBytes*(, 0, b, i, oldString.getBytes*((; It does not throw any exceptions and happily continues *without changing a thing(, hence, the arr.indexOf function keeps returning the same value and hangs the build process. I guess by now you have noticed that there are some strange characters in this document. Well... I have changed my default locale and language to English, the build has run flawlessly, and my Japanese keyboard is trying to imitate an English keyboard! These are the changes *=(, (=), and &=' throughout the email. I have been very busy at work recently, but I would like to help. The reason that I ended up on this trail is because I wanted my staff, and myself, to have the use of the XML module. I didn&t keep track of this within the issue that I sent because I couldn&t find a link to amend the issue itself. I will try some other things and see what I can do. Max by the way you can append your comments to the bug by going to its page: http://www.netbeans.org/issues/show_bug.cgi?id=17508 (you must be logged in as axobel), and adding comments and submitting. I guess I'm still confused about what in your environment causes the problem: it only happens when running in Japanese mode? I don't see anything harmful in the patch, just curious why it would be necessary. Is System.arraycopy not working correctly in your JDK?? Or something else? Created attachment 3394 [details]
Working Postprocess.java for Windows 2000 w/default Japanese encoding.
I used US-ASCII encoding for all the conversions to and from bytes, and added some extra validations so that I wouldnt have to wait until the end of the build until I could see the result. This worked!! Finally!! I have attached the new file.. sorry. I havent checked out the CVS sources (yet) and I dont have time right now to set it up. Thanks for all your support - It was great. I finally feel like I have contributed at least something to the open-source movement as virtually all the software that I use for development is open-source. I will mark this issue as resolved, however, you might want to test the build on various other systems with other language/encoding settings. Thanks again, M@X Thanks for the patch. (It is not really FIXED until the code is committed, so reopening.) I will sanity-check and commit soon. Should be fixed now, please try again with current sources Max. Applied patch with some changes; mainly, using ISO8859_1 rather than US-ASCII as this encoding is exactly what is needed (a raw byte <-> 8-bit char conversion; ASCII conversion does weird substitutions which are not wanted here). Also simplified loop logic a bit. committed * Up-To-Date 1.11 core/release/CREDITS.html committed * Up-To-Date 1.3 nbbuild/antsrc/org/netbeans/nbbuild/Postprocess.java |