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.

Bug 17508 - Custom ANT target Postprocess hangs build (infinite loop)
Summary: Custom ANT target Postprocess hangs build (infinite loop)
Status: RESOLVED FIXED
Alias: None
Product: www
Classification: Unclassified
Component: Builds & Repositories (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P3 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-11-11 05:59 UTC by Max Lobel
Modified: 2001-11-15 11:35 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Replaces strings in binary files. Fixed infinite loop problem. (3.99 KB, text/plain)
2001-11-11 06:01 UTC, Max Lobel
Details
Working Postprocess.java for Windows 2000 w/default Japanese encoding. (4.49 KB, text/plain)
2001-11-13 15:44 UTC, Max Lobel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Max Lobel 2001-11-11 05:59:10 UTC
While executing target compile-preprocessed of the openide the build of 
Netbeans hangs. The code in Postprocess.replaceString(byte[] b) attempts to get 
the indexOf the string to replace, however, it always retrieves the same index 
and will never return -1 unless the string does not exist in the file. Hence, 
causing an infinite loop during the build.

The attachment to this issue is the fixed file. I added a variable to mark the 
previous index of the search string, and changed the search method to start 
from the after the previous find.

indexOf(oldString) -> indexOf(oldString, pos)
Comment 1 Max Lobel 2001-11-11 06:01:27 UTC
Created attachment 3356 [details]
Replaces strings in binary files. Fixed infinite loop problem.
Comment 2 Jesse Glick 2001-11-11 23:56:17 UTC
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.]
Comment 3 Jesse Glick 2001-11-12 16:59:21 UTC
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.
Comment 4 Jesse Glick 2001-11-12 17:03:33 UTC
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?
Comment 5 Max Lobel 2001-11-13 15:44:54 UTC
Created attachment 3394 [details]
Working Postprocess.java for Windows 2000 w/default Japanese encoding.
Comment 6 Max Lobel 2001-11-13 15:51:33 UTC
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
Comment 7 Jesse Glick 2001-11-13 16:09:51 UTC
Thanks for the patch. (It is not really FIXED until the code is
committed, so reopening.)
Comment 8 Jesse Glick 2001-11-13 16:10:15 UTC
I will sanity-check and commit soon.
Comment 9 Jesse Glick 2001-11-15 11:35:30 UTC
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