Re: Broken Debugger on OS X Sierra

Ok, I sent off an email to them. We'll see how that goes. At least there's
a workaround, in the meantime.

Stefik

On Mon, Oct 3, 2016 at 11:00 AM, Andreas Stefik <[email protected]> wrote:

> 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.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 + "\"");
>
> 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
>>>
>>>
>>>
>>
>