pupil-labs / libuvc

a cross-platform library for USB video devices
https://int80k.com/libuvc/
Other
52 stars 30 forks source link

Correcting clock frequency to 0 #37

Closed yurikleb closed 4 years ago

yurikleb commented 4 years ago

I'm using libuvc together with pyuvc It seems like sometimes libuvc attempts to adjust the clock frequency to 0 which results in a Floating point exception: 8 and causes my app to crash.

here is a log of my app which is capturing a feed from a USB camera:

*** Correcting clock frequency to 18446744073709064655
*** Correcting clock frequency to 773985841442795
*** Correcting clock frequency to 24394025013
*** Correcting clock frequency to 18446744073705623779
*** Correcting clock frequency to 566162578616199
*** Correcting clock frequency to 26614331558
*** Correcting clock frequency to 993905
*** Correcting clock frequency to 40
*** Correcting clock frequency to 0
Floating point exception: 8

And another sample output:

*** Correcting clock frequency to 18446744073709542761
*** Correcting clock frequency to 706809490210815
*** Correcting clock frequency to 29107193129
*** Correcting clock frequency to 1273591
*** Correcting clock frequency to 57
*** Correcting clock frequency to 0
Floating point exception: 8

Is there any way to fix this? I am also unable to catch this exception in my code or via the debugger either, which results in my app crashing every 5-10 minutes or so.

papr commented 4 years ago

I think there is something going fundamentally wrong here. The Floating point exception is just a symptom. My clock frequency correction has the same magnitude over multiple correction. This is not the case for you. 🤔


*** Correcting clock frequency to 14999945
*** Correcting clock frequency to 14999989
*** Correcting clock frequency to 14999972
*** Correcting clock frequency to 14999954
*** Correcting clock frequency to 15000000
*** Correcting clock frequency to 14999955
*** Correcting clock frequency to 14999945
*** Correcting clock frequency to 14999986
*** Correcting clock frequency to 14999939
*** Correcting clock frequency to 14999922
*** Correcting clock frequency to 14999998
*** Correcting clock frequency to 14999961
*** Correcting clock frequency to 14999948
*** Correcting clock frequency to 14999987
*** Correcting clock frequency to 14999953
*** Correcting clock frequency to 14999928
*** Correcting clock frequency to 14999941
*** Correcting clock frequency to 14999999
*** Correcting clock frequency to 14999958
*** Correcting clock frequency to 14999900
*** Correcting clock frequency to 15000052
*** Correcting clock frequency to 15000014
*** Correcting clock frequency to 14999957
*** Correcting clock frequency to 14999994
yurikleb commented 4 years ago

Hey @papr I think you are correct, I tested with several other webcams, they all seem to be stable and generating the same magnitude over multiple corrections. It seems like the problem lies within that specific camera (a USB microscope). I will reach out to the manufacturer, see if they can help.

yurikleb commented 4 years ago

@papr just another quick question. which version of libuvc this fork is based on? I just got a response from the camera manufacturer and they claim that in UVC v1.1 and above, this issue should not be occurring as "UVC 1.1 ignores and does not use this dwClockFrequency property"

jake-nz commented 8 months ago

I'm also seeing this problem. I'm running on Mac OS and libuvc 0.1.0 with three Logitec C920 webcams at the same time.

I get Correcting clock frequency to 0 followed by Floating point exception every 30 minutes or so. I haven't noticed the frequency getting smaller and smaller as @yurikleb did but I will check for that next time.

Replacing the cameras is not an option for me. Would it be possible to ignore dwClockFrequency? Alternatively, I would be happy enough if I could catch this error and reinstantiate the device in my code.