Unfortunately NB6.7.1 has another problem - when you try to debug, it comes up with message 'listening on .....', just sits there for a while, then says 'Socket Closed' and debugger exits back.
I have tried googling for a solution to this without success. The interesting thing with this is under 'Leopard' a similar thing was happening, except the Error Message were quite long with inferences to 'Transport' not being opened.
Under NB6.1 on Leopard non of these issues were a problem, and that is why I am using NB6.1.
But for the launcher, NB is a Java application. NB 6.7 has a lot of bug fixes which the earlier versions don't have. Plus, the UI is more polished (I use it). Check your Java settings in control panel and see which version of the VM is configured for first use by applications. Try moving that around to see if the problem goes away.
Again, Snow Leopard's firewall is more strict. Try turning the firewall off to see if that helps; especially when you get socket errors in 6.7
But for the launcher, NB is a Java application. NB 6.7 has a lot of bug fixes which the earlier versions don't have. Plus, the UI is more polished (I use it). Check your Java settings in control panel and see which version of the VM is configured for first use by applications. Try moving that around to see if the problem goes away.
Again, Snow Leopard's firewall is more strict. Try turning the firewall off to see if that helps; especially when you get socket errors in 6.7
I totally agree with 6.7.1. The UI is much cleaner,sharper, and polished, but it's no use if I can't debug.
I tried changing various settings - I moved the preferred VM for JRE6 (32 bit) up to the top, tried other settings in both Java preferences and NB preferences. In all cases still get the following error:
***********
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
ERROR: transport error 202: gethostbyname: unknown host
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:690]
Java Result: 134
debug:
BUILD SUCCESSFUL (total time: 2 seconds)
************
I did find by googling a workaround for the above suggesting to add entries to the '/etc/hosts' file to solve the problem. I did this to no avail.
I have a river close by, but on the way there decided it was too cold to jump in - and I have no more hair left to pull out! Getting desperate.
Did you rebuild your ruby gems after installing snow leopard? Some of the native extensions (like what is used in the debug ide) aren't compatible after upgrading to SL. Many suggestions are out there, one of them being to trash mac ports completely and reinstall everything. I don't think the Netbeans IDE is the issue.
Did you rebuild your ruby gems after installing snow leopard? Some of the native extensions (like what is used in the debug ide) aren't compatible after upgrading to SL. Many suggestions are out there, one of them being to trash mac ports completely and reinstall everything. I don't think the Netbeans IDE is the issue.
Thanks for your suggestion - but I am not using Ruby Gems.
I am not very literate when it comes to higher level OS maintenance issues, so I tend to look at these problems from a more general perspective. My gut feeling here is that there are some permission problems and/or some files have moved between Leopard/Snow Leopard.
Just recapping on the known issues:
Leopard+NB6.1=Debug OK
Snow Leopard+NB6.1=Debug works but no variable values shown
Leopard+NB6.7+=Debug fails with Transport issue
Snow Leopard+NB6.7+=Debug fails with Transport issue
I might be wrong, but to me my gut says this points to:
NB6.7+ uses Transport differently (access permission on files or port access???)
NB6.1 throws and Exception error when accessing OR displaying 'Variable values'
Thanks for your suggestion - but I am not using Ruby Gems.
I am not very literate when it comes to higher level OS maintenance issues, so I tend to look at these problems from a more general perspective. My gut feeling here is that there are some permission problems and/or some files have moved between Leopard/Snow Leopard.
Just recapping on the known issues:
Leopard+NB6.1=Debug OK
Snow Leopard+NB6.1=Debug works but no variable values shown
Leopard+NB6.7+=Debug fails with Transport issue
Snow Leopard+NB6.7+=Debug fails with Transport issue
I might be wrong, but to me my gut says this points to:
NB6.7+ uses Transport differently (access permission on files or port access???)
NB6.1 throws and Exception error when accessing OR displaying 'Variable values'
Debugging is not a NB feature, it uses two rubygems to do the same. Try to do a
sudo gem install ruby-debug-base ruby-debug-ide
NB uses the following on my iMac.
> ruby-debug-base (0.10.3)
> ruby-debug-ide (0.4.6
I haven't updated to SL yet. I will post here after I do so. I don't want to break things just yet.
2. OP is debugging java code in a java IDE, using the java debugger. This has absolutely nothing to do with ruby or ruby gems. Perhaps if he were working on ruby code, this would have some relevance.
3. "Debugging is not a NB feature" - incorrect. Debugging is, in fact, a NB feature.
I am seeing problems with debugging a glassfish instance running a debugger, using netbeans. I'm using the SocketAttach debug attach method. The problems I am seeing are slowness and multiple threads being reported where there should only be a single thread at a particular breakpoint.
It took quite a long time to connect to the debugger, and takes a long time to populate values in the variables pane, but does seem to connect in the end and work (after a fashion).
Not much help I know, but I just wanted to save you running off after ruby bits.
2. OP is debugging java code in a java IDE, using the java debugger. This has absolutely nothing to do with ruby or ruby gems. Perhaps if he were working on ruby code, this would have some relevance.
3. "Debugging is not a NB feature" - incorrect. Debugging is, in fact, a NB feature.
I am seeing problems with debugging a glassfish instance running a debugger, using netbeans. I'm using the SocketAttach debug attach method. The problems I am seeing are slowness and multiple threads being reported where there should only be a single thread at a particular breakpoint.
It took quite a long time to connect to the debugger, and takes a long time to populate values in the variables pane, but does seem to connect in the end and work (after a fashion).
Not much help I know, but I just wanted to save you running off after ruby bits.
Thanks. I didn't think so.
I will investigate this 'netbeans.conf' file.
Don't ask me why, but I still think it is something to do with permissions or the way the 'ports' are used or accessed.
Since upgrading to Snow Leopard, when I debug a Java program, the 'Local Variables' panel does not show the variable 'Value's.
Constructive help would be appreciated to fix this problem.
This may seem counterintuitive, but go to your Security Preferences panel and TURN ON your firewall. Restart whatever program was having the problem. Your firewall will prompt you as to whether you will allow the program to accept incoming connections. Say yes.
This may seem counterintuitive, but go to your Security Preferences panel and TURN ON your firewall. Restart whatever program was having the problem. Your firewall will prompt you as to whether you will allow the program to accept incoming connections. Say yes.
I am running plain vanilla Snow Leopard. No additional Virus software or Firewalls. Unless you are referring to something available in SL that I am not aware of.
I am running plain vanilla Snow Leopard. No additional Virus software or Firewalls. Unless you are referring to something available in SL that I am not aware of.
Yes, SL has a built-in firewall. Go to System Preferences -> Security -> Firewall.
Comments
Since upgrading to Snow Leopard, when I debug a Java program, the 'Local Variables' panel does not show the variable 'Value's.
Constructive help would be appreciated to fix this problem.
Try Netbeans 6.7.1 instead?
Try Netbeans 6.7.1 instead?
Thanks for your reply.
Unfortunately NB6.7.1 has another problem - when you try to debug, it comes up with message 'listening on .....', just sits there for a while, then says 'Socket Closed' and debugger exits back.
I have tried googling for a solution to this without success. The interesting thing with this is under 'Leopard' a similar thing was happening, except the Error Message were quite long with inferences to 'Transport' not being opened.
Under NB6.1 on Leopard non of these issues were a problem, and that is why I am using NB6.1.
Again, Snow Leopard's firewall is more strict. Try turning the firewall off to see if that helps; especially when you get socket errors in 6.7
But for the launcher, NB is a Java application. NB 6.7 has a lot of bug fixes which the earlier versions don't have. Plus, the UI is more polished (I use it). Check your Java settings in control panel and see which version of the VM is configured for first use by applications. Try moving that around to see if the problem goes away.
Again, Snow Leopard's firewall is more strict. Try turning the firewall off to see if that helps; especially when you get socket errors in 6.7
I totally agree with 6.7.1. The UI is much cleaner,sharper, and polished, but it's no use if I can't debug.
I tried changing various settings - I moved the preferred VM for JRE6 (32 bit) up to the top, tried other settings in both Java preferences and NB preferences. In all cases still get the following error:
***********
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
ERROR: transport error 202: gethostbyname: unknown host
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:690]
Java Result: 134
debug:
BUILD SUCCESSFUL (total time: 2 seconds)
************
I did find by googling a workaround for the above suggesting to add entries to the '/etc/hosts' file to solve the problem. I did this to no avail.
I have a river close by, but on the way there decided it was too cold to jump in - and I have no more hair left to pull out! Getting desperate.
Read this: http://groups.google.com/group/rubyo...e355f37ce57a23
Did you rebuild your ruby gems after installing snow leopard? Some of the native extensions (like what is used in the debug ide) aren't compatible after upgrading to SL. Many suggestions are out there, one of them being to trash mac ports completely and reinstall everything. I don't think the Netbeans IDE is the issue.
Read this: http://groups.google.com/group/rubyo...e355f37ce57a23
Thanks for your suggestion - but I am not using Ruby Gems.
I am not very literate when it comes to higher level OS maintenance issues, so I tend to look at these problems from a more general perspective. My gut feeling here is that there are some permission problems and/or some files have moved between Leopard/Snow Leopard.
Just recapping on the known issues:
Leopard+NB6.1=Debug OK
Snow Leopard+NB6.1=Debug works but no variable values shown
Leopard+NB6.7+=Debug fails with Transport issue
Snow Leopard+NB6.7+=Debug fails with Transport issue
I might be wrong, but to me my gut says this points to:
NB6.7+ uses Transport differently (access permission on files or port access???)
NB6.1 throws and Exception error when accessing OR displaying 'Variable values'
Thanks for your suggestion - but I am not using Ruby Gems.
I am not very literate when it comes to higher level OS maintenance issues, so I tend to look at these problems from a more general perspective. My gut feeling here is that there are some permission problems and/or some files have moved between Leopard/Snow Leopard.
Just recapping on the known issues:
Leopard+NB6.1=Debug OK
Snow Leopard+NB6.1=Debug works but no variable values shown
Leopard+NB6.7+=Debug fails with Transport issue
Snow Leopard+NB6.7+=Debug fails with Transport issue
I might be wrong, but to me my gut says this points to:
NB6.7+ uses Transport differently (access permission on files or port access???)
NB6.1 throws and Exception error when accessing OR displaying 'Variable values'
Debugging is not a NB feature, it uses two rubygems to do the same. Try to do a
sudo gem install ruby-debug-base ruby-debug-ide
NB uses the following on my iMac.
> ruby-debug-base (0.10.3)
> ruby-debug-ide (0.4.6
I haven't updated to SL yet. I will post here after I do so. I don't want to break things just yet.
1. Netbeans does not use the java runtime nominated in your java control panel on OS X. It uses the one nominated in this file:
/Applications/NetBeans/NetBeans 6.7.app/Contents/Resources/NetBeans/etc/netbeans.conf
adjust for appropriate version.
2. OP is debugging java code in a java IDE, using the java debugger. This has absolutely nothing to do with ruby or ruby gems. Perhaps if he were working on ruby code, this would have some relevance.
3. "Debugging is not a NB feature" - incorrect. Debugging is, in fact, a NB feature.
@Rodney.Nagel
I am seeing problems with debugging a glassfish instance running a debugger, using netbeans. I'm using the SocketAttach debug attach method. The problems I am seeing are slowness and multiple threads being reported where there should only be a single thread at a particular breakpoint.
It took quite a long time to connect to the debugger, and takes a long time to populate values in the variables pane, but does seem to connect in the end and work (after a fashion).
Not much help I know, but I just wanted to save you running off after ruby bits.
@talksense101
1. Netbeans does not use the java runtime nominated in your java control panel on OS X. It uses the one nominated in this file:
/Applications/NetBeans/NetBeans 6.7.app/Contents/Resources/NetBeans/etc/netbeans.conf
adjust for appropriate version.
2. OP is debugging java code in a java IDE, using the java debugger. This has absolutely nothing to do with ruby or ruby gems. Perhaps if he were working on ruby code, this would have some relevance.
3. "Debugging is not a NB feature" - incorrect. Debugging is, in fact, a NB feature.
@Rodney.Nagel
I am seeing problems with debugging a glassfish instance running a debugger, using netbeans. I'm using the SocketAttach debug attach method. The problems I am seeing are slowness and multiple threads being reported where there should only be a single thread at a particular breakpoint.
It took quite a long time to connect to the debugger, and takes a long time to populate values in the variables pane, but does seem to connect in the end and work (after a fashion).
Not much help I know, but I just wanted to save you running off after ruby bits.
Thanks. I didn't think so.
I will investigate this 'netbeans.conf' file.
Don't ask me why, but I still think it is something to do with permissions or the way the 'ports' are used or accessed.
Since upgrading to Snow Leopard, when I debug a Java program, the 'Local Variables' panel does not show the variable 'Value's.
Constructive help would be appreciated to fix this problem.
This may seem counterintuitive, but go to your Security Preferences panel and TURN ON your firewall. Restart whatever program was having the problem. Your firewall will prompt you as to whether you will allow the program to accept incoming connections. Say yes.
This may seem counterintuitive, but go to your Security Preferences panel and TURN ON your firewall. Restart whatever program was having the problem. Your firewall will prompt you as to whether you will allow the program to accept incoming connections. Say yes.
I am running plain vanilla Snow Leopard. No additional Virus software or Firewalls. Unless you are referring to something available in SL that I am not aware of.
I am running plain vanilla Snow Leopard. No additional Virus software or Firewalls. Unless you are referring to something available in SL that I am not aware of.
Yes, SL has a built-in firewall. Go to System Preferences -> Security -> Firewall.
NetBeans IDE 6.7.1 (Build 200907230233) downloaded 3 days ago
Loaded old NetBeans projects from a Vista Laptop, had no problems building, running or debugging...
Alan