Re: Broken Debugger on OS X Sierra

Martin,

Thanks for this, super helpful. I've done more digging and here's what I've
tried/where I'm at:

1. I've now tried to replicate the issue on two other machines. One of them
had the same behavior I noticed, the other didn't, even with identical
/etc/hosts files, identical OS, and identical versions of the JDK. The only
difference I can find between them is that both of the machines that
exhibit the behavior have hardware from early 2011. The machine that
doesn't has hardware from late 2012. It's possible that there's a
difference in the native library is calls to between these different
hardware versions, but that's just a guess.

Point being, this means it is *definitely not* a bug in NetBeans. It's
either a bug in the JDK or Sierra's native implementation of get host.

2. I tried two different versions of the JDK, both version 8. Specifically,
the latest (102), and an older version (45). Same behavior I noticed in
Sierra, but not in the previous version of Mac.

3. In theory, localhost with this config of /etc/hosts should actually be
ok. I "think" what is going on here is that with this connection:

//typical connector
LaunchingConnector connector = Bootstrap.virtualMachineManager().
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 + "\"");

I'm guessing it has an implicit flag that is injected for dt_socket, which
puts in the computer name, *not local host --- I can replicate this
behavior reliably.* Now, on an upgraded machine, there is a file called
/etc/hosts.orig, which I'm guessing is the previous version from
non-Sierra. However, that file also doesn't have the computer name, but
works, so I'm pondering if Mac had some kind of implicit mapping from the
computer name to localhost in native. In the flag I sent, you can also see
the computer name is listed, not local host, by default.

4. I don't know for sure, but I'm now wondering if I can just override the
implicit (not specified by me) dt_socket flag to be localhost, not what the
JDK puts in there (computer name). That's probably what I'll try next.
However, I'm not sure if this is a good idea or not, because I don't know
if the JDK prefers to inject this option based on some other information.
Do you think I can do this reliably without this screwing up people using
our software?

Anyway, I'll toss an email off to the place you mention and see what they
say.

Stefik


On Mon, Oct 3, 2016 at 12:20 AM, Martin Entlicher <
[email protected]> wrote:

> Hi Andreas,
>
> this can not be a NetBeans issue and you'd better ask debugger developers
> at [email protected]
>
> NetBeans is using address=localhost:... and then connects to localhost.
> localhost should always be set in /etc/hosts AFAIK, thus it ought to work.
>
> Do you use the same JDK version after the OS upgrade? During evaluation of
> https://netbeans.org/bugzilla/show_bug.cgi?id=268056 I've found that they
> apparently changed some logic in the Java debugger backend in JDK 9. I do
> not think you've upgraded to JDK 9, but maybe there could be some subtle
> changes between JDK updates...
>
> Regards,
> Martin
>
> On 2.10.2016 04:27, Andreas Stefik 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
>>
>>
>>
>