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

indigo_ccd_qhy2 crashes the server if launced with the -i option #441

Open
Paolo97Gll opened this issue Feb 12, 2022 · 3 comments
Open

indigo_ccd_qhy2 crashes the server if launced with the -i option #441

Paolo97Gll opened this issue Feb 12, 2022 · 3 comments
Assignees
Labels

Comments

@Paolo97Gll
Copy link

Paolo97Gll commented Feb 12, 2022

Following the documentation, I launched the indigo_ccd_qhy2 driver using the -i option.

### Underlaying SDK is not stable
Due to instability in the vendor provided SDK problems on all platforms should be expected. Therefore it is
advised to use this driver with -i option like this:
indigo_server -i indigo_ccd_qhy2
This will execute the driver in a separate process and in case of a driver crash the server will not be affected.
This will come at the cost of somewhat reduced performance.

I normally use the following command:

indigo_server --enable-info --disable-bonjour indigo_ccd_asi indigo_ccd_atik -i indigo_ccd_qhy2 indigo_wheel_sx indigo_agent_alpaca

For the test I used the following command.

indigo_server --enable-trace -i indigo_ccd_qhy2  > indigo.log 2>&1

And then the server crashed when I tried to take a 0.1 second shot (it happens also with 0.001, 0.01 and 1). The behaviour is the same that happens with the first ("long") command. Here the log file: indigo.log.

Without the -i option, everything works well and no crash happen. The camera is a QHY5 III 178 mono.

@polakovic
Copy link
Member

We'll check it, but for now try to avoid -i switch. For such a fast camera it may slow down everything by many orders of magnitude (because of very inefficient INDI legacy protocol enforced by -i switch).

@rumengb, it looks like a memory overrun in base64 decoding.

@polakovic polakovic added the bug label Feb 12, 2022
@Paolo97Gll
Copy link
Author

Ok, thanks!

@rumengb
Copy link
Member

rumengb commented Feb 13, 2022 via email

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

No branches or pull requests

3 participants