Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serial Port is not disposed correctly during a flutter hot restart #68

Open
bryceremick opened this issue Sep 1, 2022 · 8 comments · May be fixed by #84
Open

Serial Port is not disposed correctly during a flutter hot restart #68

bryceremick opened this issue Sep 1, 2022 · 8 comments · May be fixed by #84

Comments

@bryceremick
Copy link

Anytime I do a hot restart on my flutter app after the port has been initialized, I get this error:

Unhandled Exception: SerialPortError: Device or resource busy, errno = 16

Basically my app runs through this initialization process during every hot restart:

  1. Close/Dispose the port if it already exists
  2. Create new SerialPort instance
  3. OpenReadWrite
  4. Set Baud Rate
  5. Create new SerialPortReader instance
  6. Listen to data

I get this error at step 3 after a hot restart.

My guess is that the port is not disposed correctly and when a new port gets opened for read/write the OS throws this error because the old port still exists in memory.

This is on Android 7.1 btw.

Any suggestions on how to solve this?

Thanks

@saguado69
Copy link

Same for me, sorry @bryceremick how do you run the package under Android? It does not work for me, I always have an issue related to permissions.

Thanks for any help.

@hareendranmg
Copy link

Hi @bryceremick, do you find any solution? I also getting this error in ubuntu.

@bryceremick
Copy link
Author

@hareendranmg I have not found any solution for this yet, unfortunately. Hot reload is working for me, but not hot restart.

@evanwsu
Copy link

evanwsu commented Jul 24, 2023

I believe the reason for this issue is that Flutter performs a hot restart, which restarts the entire application, causing the SerialPort instance to be garbage-collected, but the SerialPort object associated with the native object is not properly disposed. I attempted to call serialPort.dispose() in relevant lifecycle methods, but it seems that hot restart does not trigger these lifecycle methods.

@NickNevzorov
Copy link

Same for windows. After hot restart serialPort.dispose() is not called and no way to reopen port

@alexbatalov alexbatalov linked a pull request Mar 29, 2024 that will close this issue
@shingohu
Copy link

I have solved this problem. You can save the address of the last opened serial port. When hot restart occurs, check for any serial port addresses that have not been properly closed in the main function. If they exist, create a SerialPort by constructing the SerialPort. freeAddress method, then close and dispose of them

@vigorox
Copy link

vigorox commented May 30, 2024

I have solved this problem. You can save the address of the last opened serial port. When hot restart occurs, check for any serial port addresses that have not been properly closed in the main function. If they exist, create a SerialPort by constructing the SerialPort. freeAddress method, then close and dispose of them

@shingohu
Got the same issue in Windows. Can you please share your code?

@shingohu
Copy link

I have solved this problem. You can save the address of the last opened serial port. When hot restart occurs, check for any serial port addresses that have not been properly closed in the main function. If they exist, create a SerialPort by constructing the SerialPort. freeAddress method, then close and dispose of them

@shingohu Got the same issue in Windows. Can you please share your code?

 Future<void> hotRestart(int ptr) async {
    SerialPort port = SerialPort.fromAddress(ptr);
    if (port.isOpen) {
      port.close();
      port.dispose();
    }
  }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants