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.
This is a regression introduced in patch1 after fixing bug #178201 Steps to reproduce: - create Fractal sample project - leave project properties "Console Type" and "Terminal Type" as Default - run it, it runs successfully - switch profiler off - run the project Result: "There was an error creating the child process for this terminal" window appears
It's reproducible on all platforms except Windows. On Mac term window (dorun.sh) gives: /usr/X11/bin/xterm: Can't execvp /Applications/NetBeans/NetBeans 6.8.app/Contents/Resources/NetBeans/cnd3/bin/dorun.sh: Permission denied
To rollback patch1 changes a user just need to reinstall nb6.8 and use a fresh userdir.
The reason is the absence of execution permissions for cnd3/bin/dorun.sh I've just installed a fresh 6.8 - cnd3/bin/dorun.sh has execution permissions. If I upgrade it to 6.8.1, i see that cnd3/bin/dorun.sh don't have execution permissions. As soon as I set execution permissions for this file, the bug disappears.
When I build IDE from sources, cnd3/bin/dorun.sh execution permissions are set. So I believe the problem is in the installer.
The issue is that MakeNBM stores executable files info in Info/executables.list but updater read that information from Info/executable.list Fixed by using Info/executable.list in MakeNBM: http://hg.netbeans.org/core-main/rev/7ddf91788e0d Actually, should be reproducible on 6.9 dev builds as well within the following scenario: 1) Install 6.9 M1 JavaSE 2) Run IDE, open Tools->Plugins, install C/C++, restart 3) After restart cnd/bin/dorun.sh does not have executable permissions Definitely needs to be back-ported to 6.8 (patch2).
Dima, I tend to be afraid to backport a change in build infrastructure, which in fact means, that if it should really have to have an influence, then affected NBMs available from Update Center must be rebuilt and go through complete publishing cycle. Please explain why we should not go with a fix rather in updater than in MakeNBM? (I know about singular better than plural rule, but this rule seems to be much softer than what it means if we would have insisted on it)
I can't but agree with you, so reverting change in MakeNBM and doing that in autoupdate.services: http://hg.netbeans.org/core-main/rev/244ed71aa63d
The patch looks good.
Integrated into 'main-golden', will be available in build *201003110200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/244ed71aa63d User: Dmitry Lipin <dlipin@netbeans.org> Log: Better fix for #180672 - fix updater rather than MakeNBM
The patch has been ported into release68_fixes repository as http://hg.netbeans.org/release68_fixes/rev/f8848d09917d
verified in patch2 candidate 20100318