Error: Reading from device (error code: 75) with TBS 6205

[ChristopherHackett]

Using NativeTest I get the following with my TBS 6205 cards.

Has native support: true
Numer of devices: 8
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter0
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter1
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter2
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter3
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter4
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter5
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter6
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter7
-- Tuning and reading a single packet two times

Waiting 2 seconds for data ... done
java.io.IOException: Error: Reading from device (error code: 75)
        at org.czentral.dvb.io.NativeDVBIO.available(Native Method)
        at org.czentral.dvb.io.NativeTest.main(Unknown Source)

Which is coming from this native code. Looking up error code 75 I see EOVERFLOW 75 Value too large for defined data type.

Have I complied the native code wrong or is there a compatibility issue with TBS 6205 cards?

Interestingly if I change the test code to wait 200 ms instead of 2000 ms I get the following

Has native support: true
Numer of devices: 8
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter0
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter1
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter2
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter3
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter4
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter5
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter6
TurboSight TBS 6205 DVBT/T2 frontend - /dev/dvb/adapter7
-- Tuning and reading a single packet two times

Waiting 2 seconds for data ... done
47 2 59 14 76 7e 17 c0 8c 9e 49 2c 82 a0 39 b ...

Waiting 2 seconds for data ... done
47 2 59 14 76 7e 17 c0 8c 9e 49 2c 82 a0 39 b ...
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f22a2b25101, pid=5023, tid=139786735195904
#
# JRE version: OpenJDK Runtime Environment (7.0_91-b02) (build 1.7.0_91-b02)
# Java VM: OpenJDK 64-Bit Server VM (24.91-b01 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea 2.6.3
# Distribution: Ubuntu 14.04 LTS, package 7u91-2.6.3-0ubuntu0.14.04.1
# Problematic frame:
# C  [libNativeDVBIO.so.0.0.0+0x3101]  Java_org_czentral_dvb_io_NativeDVBIO_close+0xb3
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# ~/dvb-is/java/hs_err_pid5023.log
[thread 139786734143232 also had an error]
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted (core dumped)

The stack in hs_err_pid5023.log is

Stack: [0x00007f22a2a21000,0x00007f22a2b22000],  sp=0x00007f22a2b20930,  free space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libNativeDVBIO.so.0.0.0+0x3101]  Java_org_czentral_dvb_io_NativeDVBIO_close+0xb3
j  org.czentral.dvb.io.NativeDVBIO.close()V+0
j  org.czentral.dvb.io.NativeDVBIO$ShutdownHook.run()V+4
v  ~StubRoutines::call_stub
V  [libjvm.so+0x5edc89]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x339
V  [libjvm.so+0x5ecade]  JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x20e
V  [libjvm.so+0x6296d1]  thread_entry(JavaThread*, Thread*)+0xd1
V  [libjvm.so+0x906c70]  JavaThread::thread_main_inner()+0xf0
V  [libjvm.so+0x906ee1]  JavaThread::run()+0x221
V  [libjvm.so+0x7cc742]  java_start(Thread*)+0xf2

[vbence]

The code was only tested with a narrow list of hardware. What I can think about is the driver buffering data even when it is not being red, and when its internal buffer fail it will just abort and return that error for subsequent calls for read. A pro card like that probably only needs a few ms to start receiving packets, so the 200ms works fine in your case.

The SIGSEGV might be unreleated; it can be a memory freeing issue on my part. I will have to look into it, it will probably only manifest when you close the program.

It would be interesting to see if other JVMs (OpenJDK) produce the same error.

Please note, I can only follow up in a week's time. I will be off the grid next week.

[ChristopherHackett]

I was using OpenJDK but using oracle still produces the same

Waiting 2 seconds for data ... done
47 0 65 16 4 d9 c0 6b 47 1c 45 fe ef 2c e4 7b ...

Waiting 2 seconds for data ... done
47 0 65 16 4 d9 c0 6b 47 1c 45 fe ef 2c e4 7b ...
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fb75b02a101, pid=6388, tid=140425482626816
#
# JRE version: Java(TM) SE Runtime Environment (7.0_80-b15) (build 1.7.0_80-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.80-b11 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libNativeDVBIO.so.0.0.0+0x3101]  Java_org_czentral_dvb_io_NativeDVBIO_close+0xb3
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# ~/dvb-is/java/hs_err_pid6388.log
[thread 140425481574144 also had an error]
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted (core dumped)