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.
Local host: Windows 7 64bit, all patches installed as of today Remote host: Ubuntu 12.04 64bit, all patches installed as of today Netbeans; vanilla install, copy mode, not shared files Tried 7.2 code, and latest daily build; same error. When using the remote build it works only intermittently for me. If I create a project, it will build perfectly for a random number of runs, then spontaneously it fails as per: Copying project files to /home/admin/.netbeans/remote/192.168.18.100/sdfsdfsdf-pc-Windows-x86_64/ at admin@192.168.18.100:443 Makefile:1: warning: NUL character seen; rest of line ignored --- snip --- make: *** No targets. Stop. BUILD FAILED (exit value 2, total time: 1s) If I delete the project (but not source) then re-enter it, then it works fine for a few builds again.
Both client and server run as VMs under vmware, on the same host hardware. It seems to be something to do with times; if I delete the local project timestamp files under nbproject/private/timestamps* then I can avoid deleting and recreating the projects...
Another possible workaround is to just remove the line with Makefile from nbproject/private/timestamps* file. For me to be able to fix this, following information is needed: Launch the IDE with additional command line flags -J-Dremote.support.logger.level=0 -J-Dnativeexecution.support.logger.level=0 -J-Dcnd.rfs.controller.trace=1 -J-Dcnd.rfs.preload.trace=1 and send me or attach IDE log (Please note that it can contain host and user name you would probably like to strip) Since only after several attempts build fails, the log can be rather large; if you are able to understand for sure the place in the log where failed build starts, you can cut the above.
Not enough information to diagnose and fix. Should this repeat, please reopen with additional information.
This is on 7.2 but I have the same problems. Size of files is correct but all are just 0-bytes. I have also a 64 bit Windows system.
js-java, please reopen bug with additional info (see comment #3)
What kind of infomation? I created a C++ project. In Options window I added a remote host for building with "acess project files via automatic copying". Base dir and compilers are specified manually as this is a cross compile. Next in the project properties I created a configuration "release-on-target" which uses the remote host config as "build host" and the added compiler setup as "Tool Collection". When I check this into SVN and check it out on the compiler machine I can compile without problems. So generally configuration setup is working. Now I start compiling in Netbeans. It is compiling the files via SSH to the compiler machine and starts make and I get the error message. When I check the files, all have the correct file size but content is only NULL bytes. Compile host is a Ubuntu 12 running in VirtualBox VM. Netbeans 7.2 runs on host system (Win Vista 64).
Created attachment 132179 [details] Netbeans app log from clean & build
Comment on attachment 132179 [details] Netbeans app log from clean & build The attachment I submitted is a log file from an attempted clean & build which resulted in the following terminal output: Copying project files to /home/debian/.netbeans/remote/build-server/computername-Windows-x86/ at debian@build-server Makefile:1: warning: NUL character seen; rest of line ignored Makefile:2: warning: NUL character seen; rest of line ignored ... Makefile:18: warning: NUL character seen; rest of line ignored make: *** No rule to make target `clean'. Stop. I have three projects, one is a static library which the other two projects link to and none of them build even after deleting both the nbproject/private/timestamps* file and the ~/.netbeans folder on the remote host.
Just got the above to build by: - Deleting the timestamps files AND - Touching the Makefile by adding a character and saving, updating the file's timestamp Netbeans then successfully built a few times and then returned to the same error. I wonder if it has something to do with windows and unix timestamps
We are getting the same errors from time to time with Win XP 32Bit and SunOS 5.10 Generic_139555-08 sun4u sparc SUNW,Sun-Fire-480R Solaris. I thought it's an network error in our company since nobody else had this bug.
I've got the same with C++ project. Ubuntu host, and Debian as a remote build system. ../drivers/base/tcpclient.cpp:1:1: warning: null character(s) ignored This line appears in a build sometimes for a different files, causing errors. Touching this files fixes that for a while, but it always come back again. It has been with me from 7.2, and now on 7.3 it is still there.
Is there a need, for any further log files to fix this?
Yes, to be able to understand what's going on, I would ask you to launch IDE with additional options -J-Dremote.support.logger.level=0 -J-Dnativeexecution.support.logger.level=0 -J-Dcnd.rfs.controller.trace=1 -J-Dcnd.rfs.preload.trace=1 and attach message log. Please note that this log will contain user and host name you would probably like to strip.
Can't proceed without an answer to the previous question. Could you provide information requested and reopen the bug?
How to do it? I've tried netbeans-7.3/bin/netbeans -J-Dremote.support.logger.level=0 -J-Dnativeexecution.support.logger.level=0 -J-Dcnd.rfs.controller.trace=1 -J-Dcnd.rfs.preload.trace=1 But no output in terminal.
Oh yes, release versions redirect stdout and stdin into IDE log. It resides in ${userdir}/var/log/messages.log. So the necessary information should be there. (You can also specify J-Dnetbeans.logger.console=true to make it print to console too). Please note that the log will contain host and user names; you would probably like to strip this.
Created attachment 134538 [details] log with parameteres enabled Here is log, but as i see there is no warning in log, that is in the topic. It definitely was in build output.
(In reply to comment #17) > Created attachment 134538 [details] > log with parameteres enabled > > Here is log, but as i see there is no warning in log, that is in the topic. It > definitely was in build output. Yes, I see no info concerning build in your log. It seems the log corresponds to IDE session within which you didn't build your project. Could you run NetBeans once more with the same options, build your project, make sure build fails in the way you described and attach the log? Could you also tell me what tools are you using on your remote machine? GNU? Which version? And what is the Linux kernel version on this machine? Auto copy uses some interception technique, so this can matter...
Created attachment 134565 [details] build output window contents Build was done it is sure. Just for some reason output is not in message log. But when i run netbeans with debug options, build window gets much more output. I've copy-pasted it to file. May be info you are searching for is there.
I've been getting the same issue for months now, and simply deleting the timestamp files and restarting Netbeans to get around the issue. Usually I'll get a dozen builds done before it starts again, so not the end of the world. The environment is the same as when I initially opened the ticket; all patched, and running the latest nightly dev build of the the c++ netbeans download. I'll upload a log file from a failed build; hopefully this will help you diagnose what is going on!
Created attachment 134576 [details] log file from a build that failed with a nul error on a source file... Never eat shredded wheat...
(In reply to comment #21) > Created attachment 134576 [details] > log file from a build that failed with a nul error on a source file... > > Never eat shredded wheat... Sorry, but this time you forgot to add command line options -J-Dcnd.rfs.controller.trace=1 -J-Dcnd.rfs.preload.trace=1 (the log lists all options, you can check it yourself). All 4 options should be specified to get force IDE printing all necessary info: -J-Dremote.support.logger.level=0 -J-Dnativeexecution.support.logger.level=0 -J-Dcnd.rfs.controller.trace=1 -J-Dcnd.rfs.preload.trace=1
Created attachment 134595 [details] rerun the logging against a failed build... Don't eat the yellow snow...
I'm pretty sure I ran the last build with the same flags on the Netbeans shortcut (it was after all just a cut and paste). Hopefully this set of logs will have what you want in them...
Is it fixed yet? What about now? And now? ;)
Do you have all the information you need to be able to reproduce and/or understand the cause?
Any update on this? I have been having this problem for years. Looks like a duplicate of 200390 to me which I don't think has been mentioned.
Those NUL-filled files are made by create_file() in rfs_controller.c: http://hg.netbeans.org/main/file/b4878b21411e/cnd.remote/tools/rfs_controller.c#l267 I guess create_file() is called for files that IDE considered non-important and not worth uploading.
Create_file() is called to ensure disk structure is the same. open() and some other functions are interposed when building, so actual upload is done only for files that are open when building I wouldn't need to create this empty directory structure if it was possible to interpose stat() on Linux. But it isn't possible to interpose it at least for some linuxes. desperate_dante, it seems I forgot to add that I need output window content as well. Some of the mentioned debugging/tracing options print into output wiundow. Debugging options are -J-Dremote.support.logger.level=0 -J-Dnativeexecution.support.logger.level=0 -J-Dcnd.rfs.controller.trace=1 -J-Dcnd.rfs.preload.trace=1 kazssym, cwpetersen, if you launch NetBeans with these command line options and send/attach message log AND output window content, I hope I'll be able to solve this. Please note that this output will contain host and user name, which you would probably like to strip.
Thank you for describing how it works. I understand that NetBeans preloads a shared library to hook several file operations on the remote server. Then I have a question. What will happen if the remote tool chain is 32-bit binary running on a 64-bit kernel?
We build both 32-bit and 64-bit .so, names are same, they are both on LD_LIBRARY_PATH. So loader loads the correct one automatically. I just tried to include a 32-bit tool into build on my 64-bit linux. Everything works ok.
I might have seen this problem only when I worked on a remote terminal from NetBeans IDE. I needed to run some make commands other than make all (Build) or make clean (Clean) occasionally and I normally used remote terminals for them. These days I modifies the project's Build command as needed and I haven't seen the problem as before. So if others see the problem in the Build/Clean IDE command, it would be a different problem from mine.
Created attachment 144923 [details] Failed build hell muhahaha... By failing to prepare, you are preparing to fail...
*** Bug 238526 has been marked as a duplicate of this bug. ***
*** Bug 235804 has been marked as a duplicate of this bug. ***
Starting from 7.4 you may use SFTP transport, which is qiuite reliable and fast enough. I strongly encourage you to try it.
Since moving to the SFTP option I've not had a repeat of this bug (mostly as I'm not using the functionality now though) ;)
Moving to SFTP as the copying mechanism fixed the error of my files being sent as null padded binary files. Can confirm the error with 'Autocopy' Persists on Netbeans 8.2