Hangs on close (macOS)

[haniibrahim]

Similar issue as with the embedded Win 8 Guy but on macOS and a bit different.

When call closePort it does not hang it closes the program as expected (try code below). But immediately after, the fan turns on loud and even other serial apps (e.g. CoolTerm) cannot reach the serial port and hang. I have to kill them. I have to reboot but I cannot shut down the Mac regularly. The Mac hangs on shutdown/reboot (black screen). I have to use the power button. I use the latest driver (compatible from macOS 10.9 to 10.15). It happens with older JSerialComm versions, too. Pseudo ports (via socat) work well. And e.g. CoolTerm (a macOS terminal app) works with the driver w/o any problems.

Environment macOS 10.14 Mojave on MacBookPro 2019 Java 1.8, Oracle JSerialComm 2.6.0 Prolific PL2303TA Chipset of the USB2Serial cable Prolific driver v. 2.0.0 (2019-12-04) (http://www.prolific.com.tw/us/showproduct.aspx?p_id=229&pcid=41)

Example code:

import com.fazecast.jSerialComm.SerialPort;

public class TestClose {

    public static void main(String[] args) {
        SerialPort comPort = SerialPort.getCommPort("cu.usbserial"); // May change port name
        comPort.openPort();
        System.out.println("Port opened");
        comPort.closePort();
        System.out.println("Port closed");
    }
}

Thank you

PS: Thank you for your efforts on this library. It works well on my two apps on Windows and GNU/Linux

[hedgecrw]

Thanks for the bug report. This is probably unrelated to the Windows 8 closePort() issue, and I'm not exactly sure what could be causing it. Can you retry your exact code from above but actually check the return values from openPort() and closePort() to see what they are doing? I'm also going to try and compile a native MacOS program for you to try which does exactly what your application is showing above but without any of the Java stuff. I'll post back once I have that completed. Thanks!

[haniibrahim]

Thanks for your prompt reply. I checked the return value of both methods openPort and closePort with the code above and both were true. So It opens and closes the port successfully according to the return values.

BTW: I wrote a simple serial datalogger which log the data as expected. So that works. When I close Port it closes the application w/o any exceptions (as my test code above) but with the same problems as mentioned in my initial report. Windows 10 and GNU/Linux with the same USB2Serial adapter were fine. Unfortunately I have no other serial adapter w/ another chipset which work on my Mac.

[hedgecrw]

Sorry the long delay. Please download and test the following native MacOS application:

https://www.dropbox.com/s/llzam1anqn5tvld/test_serial.out?dl=0

You may need to chmod this to make it executable. It is the Mac native part of jSerialComm verbatim with some added debugging to see what is happening on your system. The parameter to the application is the device filename to the serial port (i.e. /dev/cu.usbserial). Please let me know the results of running this application on your system. Thanks!

[haniibrahim]

Thank you. Your app print:

Port opened
Port closed

in the terminal when opened the first time. No error messages or such. But after I cannot open any app who uses serial communication. When I restart your app it hangs w/o any messages, when I open a GUI terminal app and try to connect the serial port, it freezes. When I try to restart my MAC it hangs at shutdown and I have to use the power button. In short: It behaves exactly as I mentioned initially.

[hedgecrw]

Okay that's great news actually...it means that the issue is definitely not being caused by the Java portion of the library, so now we can start narrowing down what exactly is happening here.

Sorry for the work required on your end, but would you mind going through and testing each of the following Mac programs and letting me know which ones work properly and which ones result in your computer hanging. This will greatly help me narrow down what exactly is causing the issue:

• https://www.dropbox.com/s/qya0j9wi338hzbp/testOpenClose1?dl=0
• https://www.dropbox.com/s/fep0lhszbcoex84/testOpenClose2?dl=0
• https://www.dropbox.com/s/hwhy0xtfwp3l2q6/testOpenClose3?dl=0
• https://www.dropbox.com/s/4bgcazhzad91mek/testOpenClose4?dl=0
• https://www.dropbox.com/s/1yg7khk0bhx5ej1/testOpenClose5?dl=0
• https://www.dropbox.com/s/9magi1xmm0wjdt5/testOpenClose6?dl=0

[haniibrahim]

Sorry for the work required on your end, ...

Do not be funny. I appreciate what you are doing without any financial equivalent. I use it, so it is my part to support you. And I do have the advantage of that. This is minimal what Open Source is all about in my eyes.

But back to the results: All 6 apps gave the same result as:

./testOpenClose1 /dev/cu.usbserial
Port opened
Port closed

=> All 6 apps did not hang

To verify it I executed your initial test app again:

./test_serial.out /dev/cu.usbserial
Port opened
Port closed

=> hang

Hope this helps.

[hedgecrw]

Oh wow, that's not what I was expecting the results to be. The final program (testOpenClose6) was pretty much the full program but without some of the configuration options applied. This means the bug doesn't have anything to do with closing the port but with something in how it is configured.

Please now try the following which slowly re-enable configuration options. If all of these work, the only thing left is to test read timeouts:

• https://www.dropbox.com/s/gq9l81x1hgbt3bz/testOpenClose7?dl=0
• https://www.dropbox.com/s/vcq03dmvb9yw9kw/testOpenClose8?dl=0
• https://www.dropbox.com/s/vcq03dmvb9yw9kw/testOpenClose8?dl=0
• https://www.dropbox.com/s/2cyoo9v1wvx5zwy/testOpenClose10?dl=0

[haniibrahim]

Port opened
Port closed

All hung.

BTW. You sent app8 twice.

[hedgecrw]

Now we're getting somewhere...narrowed it down to one line with four configuration options. Please see which of these work for you:

• https://www.dropbox.com/s/ukss6nquk7ro5vy/testOpenClose11?dl=0
• https://www.dropbox.com/s/uht7ovh21i3d8rg/testOpenClose12?dl=0
• https://www.dropbox.com/s/s4kkxm4l95l5k08/testOpenClose13?dl=0
• https://www.dropbox.com/s/ni7g4vlbg742sww/testOpenClose14?dl=0

[haniibrahim]

11, 12 => did not hang 13, 14 => hung

[hedgecrw]

Ok, fingers crossed, I think I got it:

• https://www.dropbox.com/s/n6c9a1lk6po70wz/testOpenCloseFull?dl=0

[haniibrahim]

Works! Did not hang. Congratulation.

[hedgecrw]

Fantastic! In that case, please try the following version of jSerialComm (please test full functionality for your application), and if it works, I'll go ahead and make a full release. Thanks again for all your testing!

https://www.dropbox.com/s/96b082qk9nqigxa/jSerialComm-2.6.1.jar?dl=0

[haniibrahim]

Well done. It works so far. It does not hang.

PS: At my SerialLogger I get an error but not a crash, after receiving data and even w/o receiving data when I just close the port at macOS:

null
The read operation timed out before any data was returned.

At Windows just null

But data was received completely. So the app works and it or the driver did not hang. But I did not have it w/ 2.6.0. Did you changed anything at the Java side?

[hedgecrw]

I'd have to see your source code to see exactly what the logic is, but that output string "read operation timed out" is thrown whenever a read from an InputStream returns without any data. Most likely, you have some sort of reference to the serial port's InputStream in a different thread that is still waiting for a read at the time you close the port.

Other than that, I released all of the fixes in the most recent library v2.6.1 this morning.

[haniibrahim]

Thank you I will check the code.

[hedgecrw]

Closing as fixed.