Re: Broken Debugger on OS X Sierra

Yes, thanks, I've seen all this, but unfortunately it doesn't answer my
question. As I said, it's true you can modify your hosts file, but the
problem is that previous versions of Mac didn't require this as far as I
can tell. Or, if they did, then JDI worked around it ... or something.

In other words, this worked on my machine, as I mentioned, but I'm trying
to pre-empt getting an influx of confused users having to modify their
hosts file, as it's a nasty workaround. Is there a different approach in
JDI that does not require this? AKA, for non_remote connections, should you
still pass a dt_socket command?

Stefik

On Sun, Oct 2, 2016 at 11:05 AM, Peter Hansson <[email protected]>
wrote:

> Couple of links on this issue:
>
> http://stackoverflow.com/questions/29188789/eclipse-
> mac-os-x-debug-error-fatal-error-in-native-method-jdwp-no-transports
>
> https://netbeans.org/bugzilla/show_bug.cgi?id=157931
>
> http://forums.netbeans.org/post-36441.html
>
> https://wiki.eclipse.org/Debug/FAQ#I_can_run_a_program_
> but_not_debug_it.3F.3F.3F
>
> Sorry, the links do not explain why you see this on OS X Sierra and not
> the release before that.
>
>
>
> On Sun, Oct 2, 2016 at 4:27 AM, Andreas Stefik <[email protected]> wrote:
>
>> Folks,
>>
>> I recently upgraded to OS X Sierra and have run into a problem with the
>> debugger. I don't think it's a bug in NetBeans, but want to report is here,
>> see if anyone else has run into it, and see if there's a better solution.
>>
>> First, the problem is that we have a custom debugger, which boots and
>> runs Java Bytecode. Our debug launcher looks like this:
>>
>> //typical connector
>> LaunchingConnector connector = Bootstrap.virtualMachineManage
>> r().defaultConnector();
>>
>> //all the flags
>> Map map = connector.defaultArguments();
>> Connector.Argument mainArg = (Connector.Argument) map.get("main");
>> mainArg.setValue("-jar \"" + executable + "\"");
>> Connector.Argument optionsArg = (Connector.Argument) map.get("options");
>> optionsArg.setValue("-Duser.dir=\"" + workingDirectory + "\"");
>>
>> //launch the VM
>> try {
>>     virtualMachine = connector.launch(map);
>> } catch (IOException | IllegalConnectorArgumentsException |
>> VMStartException ex) {
>>     Logger.getLogger(JDIDebugger.class.getName()).log(Level.SEVERE,
>> null, ex);
>> }
>>
>> Nothing special here, just bootup a JVM and run it with debug settings.
>> This translates to a command that looks something like this on my machine:
>>
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_102.jdk/Contents/Home/jre/bin/java
>> -Duser.dir=/Users/stefika/Repositories/quorum-language/Quorum3 -Xdebug
>> -Xrunjdwp:transport=dt_socket,address=CSadmins-MacBook-Pro-3.local:63636,suspend=y
>> -jar /Users/stefika/Repositories/quorum-language/Quorum3/Run/Default.jar
>>
>> Again, nothing special here. However, after upgrading to Sierra, I was
>> getting this error (key problem in bold):
>> 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 [debugInit.c:750]
>> FATAL ERROR in native method: JDWP No transports initialized,
>> jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
>> Abort trap: 6
>>
>> Unknown host tells me it's not connecting. This means my machine's name,
>> which happens to be CSadmins-MacBook-Pro-3.local, isn't in the
>> /etc/hosts file on my Mac. Now, that's easy to fix by adding a loopback
>> entry to the hosts file, but here's what I don't get:
>>
>> *Questions*:
>>
>> 1. Why is this necessary on OS X Sierra, but not the previous release?
>>
>> 2. I'm a little worried this is going to break for others using our stuff
>> in deployment. Is there anything I should change about my connector? The
>> Map entry doesn't contain a dt_socket command. Should I add one manually to
>> the map or is that bad?
>>
>> 3. The Java debugger doesn't appear to have this problem. For local runs,
>> should I be doing something different?
>>
>> I hope that explains the problem. Obviously, I'd like to avoid users
>> having to mess with this file, if possible.
>>
>> Stefik
>>
>>
>>
>