jvm crashes between reads

[Saeid Nourian]

In order to speed up reading I'm experimenting with leaving the device
open the entire time.
It works well when I read values from sensor within a loop, but if I
put a System.in.read() in the loop to wait for a key before next read,
then the entire JVM crashes.
Any ideas why?
Should close the port after each read and reopen it again before next
read?

Here's the JVM crash log:


#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x04e933fe, pid=3360,
tid=5696
#
# JRE version: 6.0_31-b05
# Java VM: Java HotSpot(TM) Client VM (20.6-b01 mixed mode, sharing
windows-x86 )
# Problematic frame:
# C [NGIO_lib.dll+0x333fe]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

--------------- T H R E A D ---------------

Current thread (0x047c0c00): JavaThread "Thread-4" daemon
[_thread_in_native, id=5696, stack(0x05100000,0x05150000)]

siginfo: ExceptionCode=0xc0000005, writing address 0x0483a000

Registers:
EAX=0x0481be80, EBX=0x05257210, ECX=0x0000003b, EDX=0x00000000
ESP=0x0514f304, EBP=0x0514f30c, ESI=0x05275390, EDI=0x0483a000
EIP=0x04e933fe, EFLAGS=0x00010202

Top of Stack: (sp=0x0514f304)
0x0514f304: 0001ff00 00000000 0514f33c 04e934a4
0x0514f314: 0481be80 05257210 0001ff00 fffffffe
0x0514f324: 00000039 74ab1194 0000036c 0481be80
0x0514f334: 05257210 05257208 0514f36c 04e93506
0x0514f344: 0481be80 05257210 0001ff39 00000008
0x0514f354: 04e75263 0000036c 05257208 0001ff41
0x0514f364: 05160ba0 00027100 00027100 04e6147c
0x0514f374: 0481be78 05257208 0001ff41 00000002

Instructions: (pc=0x04e933fe)
0x04e933de: 4d 10 c1 e9 07 eb 06 8d 9b 00 00 00 00 66 0f 6f
0x04e933ee: 06 66 0f 6f 4e 10 66 0f 6f 56 20 66 0f 6f 5e 30
0x04e933fe: 66 0f 7f 07 66 0f 7f 4f 10 66 0f 7f 57 20 66 0f
0x04e9340e: 7f 5f 30 66 0f 6f 66 40 66 0f 6f 6e 50 66 0f 6f


Register to memory mapping:

EAX=0x0481be80 is an unknown value
EBX=0x05257210 is an unknown value
ECX=0x0000003b is an unknown value
EDX=0x00000000 is an unknown value
ESP=0x0514f304 is pointing into the stack for thread: 0x047c0c00
EBP=0x0514f30c is pointing into the stack for thread: 0x047c0c00
ESI=0x05275390 is an unknown value
EDI=0x0483a000 is an unknown value


Stack: [0x05100000,0x05150000], sp=0x0514f304, free space=316k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [NGIO_lib.dll+0x333fe] NGIO_OpenDeviceListSnapshot+0x141de
C [NGIO_lib.dll+0x334a4] NGIO_OpenDeviceListSnapshot+0x14284
C [NGIO_lib.dll+0x33506] NGIO_OpenDeviceListSnapshot+0x142e6

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sun.jna.Function.invokeInt(I[Ljava/lang/Object;)I+0
j com.sun.jna.Function.invoke([Ljava/lang/Object;Ljava/lang/
Class;)Ljava/lang/Object;+309
J com.sun.jna.Function.invoke(Ljava/lang/Class;[Ljava/lang/
Object;Ljava/util/Map;)Ljava/lang/Object;
j com.sun.jna.Library$Handler.invoke(Ljava/lang/Object;Ljava/lang/
reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+344
j $Proxy0.device_ReadRawMeasurements(Lcom/sun/jna/Pointer;B[I[JI)I+40
j
org.concord.sensor.labquest.jna.LabQuestImpl.readRawMeasurementsAnalog(B[II)I
+12
v ~StubRoutines::call_stub
j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/
Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;
[Ljava/lang/Object;)Ljava/lang/Object;+87
j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;
[Ljava/lang/Object;)Ljava/lang/Object;+6
j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/
Object;)Ljava/lang/Object;+161
j org.concord.sensor.labquest.jna.SingleThreadDelegator.run()V+48
v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
=>0x047c0c00 JavaThread "Thread-4" daemon [_thread_in_native, id=5696,
stack(0x05100000,0x05150000)]
0x020e1c00 JavaThread "Low Memory Detector" daemon [_thread_blocked,
id=3688, stack(0x045b0000,0x04600000)]
0x020cf000 JavaThread "C1 CompilerThread0" daemon [_thread_blocked,
id=5188, stack(0x04520000,0x04570000)]
0x020ce000 JavaThread "Attach Listener" daemon [_thread_blocked,
id=5912, stack(0x04490000,0x044e0000)]
0x020cb000 JavaThread "Signal Dispatcher" daemon [_thread_blocked,
id=4960, stack(0x04400000,0x04450000)]
0x020be400 JavaThread "Finalizer" daemon [_thread_blocked, id=4940,
stack(0x04370000,0x043c0000)]
0x020bd000 JavaThread "Reference Handler" daemon [_thread_blocked,
id=2176, stack(0x042e0000,0x04330000)]
0x021e9c00 JavaThread "main" [_thread_blocked, id=6084,
stack(0x00430000,0x00480000)]

Other Threads:
0x02080c00 VMThread [stack: 0x02190000,0x021e0000] [id=5000]
0x020f5000 WatcherThread [stack: 0x04640000,0x04690000] [id=6052]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
def new generation total 4928K, used 3321K [0x24510000, 0x24a60000,
0x29a60000)
eden space 4416K, 75% used [0x24510000, 0x2484e5f0, 0x24960000)
from space 512K, 0% used [0x24960000, 0x24960000, 0x249e0000)
to space 512K, 0% used [0x249e0000, 0x249e0000, 0x24a60000)
tenured generation total 10944K, used 0K [0x29a60000, 0x2a510000,
0x34510000)
the space 10944K, 0% used [0x29a60000, 0x29a60000, 0x29a60200,
0x2a510000)
compacting perm gen total 12288K, used 603K [0x34510000, 0x35110000,
0x38510000)
the space 12288K, 4% used [0x34510000, 0x345a6f80, 0x345a7000,
0x35110000)
ro space 10240K, 51% used [0x38510000, 0x38a3e318, 0x38a3e400,
0x38f10000)
rw space 12288K, 55% used [0x38f10000, 0x395aa088, 0x395aa200,
0x39b10000)

Code Cache [0x021f0000, 0x02298000, 0x041f0000)
total_blobs=260 nmethods=126 adapters=70 free_code_cache=32881024
largest_free_block=0

Dynamic libraries:
0x00400000 - 0x00425000 C:\Program Files (x86)\Java\jre6\bin
\javaw.exe
0x77360000 - 0x774e0000 C:\Windows\SysWOW64\ntdll.dll
0x74aa0000 - 0x74bb0000 C:\Windows\syswow64\kernel32.dll
0x769f0000 - 0x76a36000 C:\Windows\syswow64\KERNELBASE.dll
0x76490000 - 0x76530000 C:\Windows\syswow64\ADVAPI32.dll
0x76730000 - 0x767dc000 C:\Windows\syswow64\msvcrt.dll
0x74bb0000 - 0x74bc9000 C:\Windows\SysWOW64\sechost.dll
0x74f20000 - 0x75010000 C:\Windows\syswow64\RPCRT4.dll
0x74a40000 - 0x74aa0000 C:\Windows\syswow64\SspiCli.dll
0x74a30000 - 0x74a3c000 C:\Windows\syswow64\CRYPTBASE.dll
0x74e20000 - 0x74f20000 C:\Windows\syswow64\USER32.dll
0x74d80000 - 0x74e10000 C:\Windows\syswow64\GDI32.dll
0x75240000 - 0x7524a000 C:\Windows\syswow64\LPK.dll
0x76800000 - 0x7689d000 C:\Windows\syswow64\USP10.dll
0x751e0000 - 0x75240000 C:\Windows\system32\IMM32.DLL
0x75260000 - 0x7532c000 C:\Windows\syswow64\MSCTF.dll
0x7c340000 - 0x7c396000 C:\Program Files (x86)\Java\jre6\bin
\msvcr71.dll
0x6d7f0000 - 0x6da9f000 C:\Program Files (x86)\Java\jre6\bin\client
\jvm.dll
0x71ed0000 - 0x71f02000 C:\Windows\system32\WINMM.dll
0x71f10000 - 0x71f5c000 C:\Windows\system32\apphelp.dll
0x6d7a0000 - 0x6d7ac000 C:\Program Files (x86)\Java\jre6\bin
\verify.dll
0x6d320000 - 0x6d33f000 C:\Program Files (x86)\Java\jre6\bin\java.dll
0x6d7e0000 - 0x6d7ef000 C:\Program Files (x86)\Java\jre6\bin\zip.dll
0x73080000 - 0x73096000 C:\Windows\system32\CRYPTSP.dll
0x73040000 - 0x7307b000 C:\Windows\system32\rsaenh.dll
0x72f80000 - 0x72f97000 C:\Windows\system32\USERENV.dll
0x72f70000 - 0x72f7b000 C:\Windows\system32\profapi.dll
0x6d600000 - 0x6d613000 C:\Program Files (x86)\Java\jre6\bin\net.dll
0x76530000 - 0x76565000 C:\Windows\syswow64\WS2_32.dll
0x756d0000 - 0x756d6000 C:\Windows\syswow64\NSI.dll
0x72500000 - 0x7253c000 C:\Windows\system32\mswsock.dll
0x708a0000 - 0x708a6000 C:\Windows\System32\wship6.dll
0x70960000 - 0x70970000 C:\Windows\system32\NLAapi.dll
0x70950000 - 0x70960000 C:\Windows\system32\napinsp.dll
0x70930000 - 0x70942000 C:\Windows\system32\pnrpnsp.dll
0x70900000 - 0x70927000 C:\Program Files (x86)\Common Files\Microsoft
Shared\Windows Live\WLIDNSP.DLL
0x74e10000 - 0x74e15000 C:\Windows\syswow64\PSAPI.DLL
0x76a40000 - 0x76a97000 C:\Windows\syswow64\SHLWAPI.dll
0x724b0000 - 0x724f4000 C:\Windows\system32\DNSAPI.dll
0x708f0000 - 0x708f8000 C:\Windows\System32\winrnr.dll
0x70bb0000 - 0x70bb5000 C:\Windows\System32\wshtcpip.dll
0x72660000 - 0x7267c000 C:\Windows\system32\IPHLPAPI.DLL
0x72650000 - 0x72657000 C:\Windows\system32\WINNSI.DLL
0x72470000 - 0x72476000 C:\Windows\system32\rasadhlp.dll
0x708b0000 - 0x708e8000 C:\Windows\System32\fwpuclnt.dll
0x10000000 - 0x10052000 C:\Users\snourian\AppData\Local\Temp
\jna4953443884999485701.tmp
0x04e60000 - 0x04ed1000 C:\workspace-sensor\labquest-jna\target
\classes\org\concord\sensor\labquest\jna\win64_java32\NGIO_lib.dll
0x75040000 - 0x751dd000 C:\Windows\syswow64\SETUPAPI.dll
0x75610000 - 0x75637000 C:\Windows\syswow64\CFGMGR32.dll
0x75730000 - 0x757bf000 C:\Windows\syswow64\OLEAUT32.dll
0x754b0000 - 0x7560c000 C:\Windows\syswow64\ole32.dll
0x767e0000 - 0x767f2000 C:\Windows\syswow64\DEVOBJ.dll
0x6fd40000 - 0x6fd49000 C:\Windows\system32\HID.DLL
0x049e0000 - 0x049fd000 C:\workspace-sensor\labquest-jna\target
\classes\org\concord\sensor\labquest\jna\win64_java32\WDAPI921.dll
0x74900000 - 0x74951000 C:\Windows\system32\WINSPOOL.DRV

VM Arguments:
jvm_args: -Dfile.encoding=Cp1252
java_command: org.concord.netlogosensor.SensorReporter
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=C:\Program Files (x86)\Java\jdk1.6.0_22
PATH=C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program
Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files
(x86)\Common Files\Microsoft Shared\Windows Live;C:\Windows\system32;C:
\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell
\v1.0\;C:\Program Files (x86)\Java\jre6\bin\;C:\Program Files
(x86)\Windows Live\Shared;C:\Program Files (x86)\Java
\jdk1.6.0_22\bin;C:\Program Files\SlikSvn\bin\;C:\Program Files
\Mercurial;c:\apache-maven-3.0.3\bin;C:\Program Files\SlikSvn\bin
USERNAME=snourian
OS=Windows_NT
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 23 Stepping 10,
GenuineIntel



--------------- S Y S T E M ---------------

OS: Windows 7 , 64 bit Build 7601 Service Pack 1

CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 23
stepping 10, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1

Memory: 4k page, physical 4181932k(1673816k free), swap
8362016k(5361116k free)

vm_info: Java HotSpot(TM) Client VM (20.6-b01) for windows-x86 JRE
(1.6.0_31-b05), built on Feb 3 2012 18:44:09 by "java_re" with MS VC+
+ 7.1 (VS2003)

time: Mon Mar 05 12:45:48 2012
elapsed time: 3 seconds

[Scott Cytacki]

What you are suggesting doesn't fit with how the devices are used, so let me give some context:

There are generally 2 ways to interact with the devices.  

One is to have them stream data, another is to do one time/ one shot reading.

The java sensor api only exposed the stream data option.  So once you start the collection you need to continue reading from the device.  Until you stop it.  Most devices have a buffer that they fill up as they are streaming data, so if you don't read from it fast enough the samples will go into the buffer.  Once the buffer is full each device handles this a differently.  I wouldn't be surprised if the full buffer case is mis-handled in some of our or their code. 

So back to your question:

When we are doing a data collection in our other code we do leave the device open all the time.  We simply call start and then let it run reading the samples as they come in.   You could emulate one-shot, by calling start, waiting for data to show up in the read and then calling stop.  But I would expect this to be slow, because the start call in many cases cycles through all the available ports to see what is attached.  

You could implement one-shot support in the java sensor api, but you would then need to implement this for all the available sensor devices.  So instead I would hack it like this:   start the collection and leave it running with a thread calling read.  Then when you need your 'one-shot' data have the thread return its most recently read value.  This will not be as efficient as doing a real one-shot but if that becomes a problem we can fix it at that point.

I don't know why the LabQuest library crashed, but I would guess it is because some calls to it were made in an unexpected order.  That might be because you are not calling the methods of the LabQuestSensorDevice in the correct order.  The SensorDevice tests demonstrate this order:

/sensor/src/test/java/org/concord/sensor/device/SensorDeviceTest.java

You can also look at the comments in SensorDevice which talk about the order:

/sensor/src/main/java/org/concord/sensor/device/SensorDevice.java

Up to this point the normal interface to the sensors was at a higher level, this higher level code in the otrunk-sensor sensor project.  That code takes care of the order, and has more checks to make sure things are done correctly.  However, I don't think you need to use that otrunk-sensor code.  It might be safer, but it is more complicated and has more dependencies than I expect you need.   I'm assuming instead you are using the LabQuestSensorDevice directly.  This has less safety, but it also should be simpler and smaller. 

If this lower level of abstraction becomes popular then it will make sense to add some utilities to make it more safe.

Scott

--
You received this message because you are subscribed to the Google
Groups "org-concord-sensor" group.
To post to this group, send email to org-conco...@googlegroups.com
To unsubscribe from this group, send email to
org-concord-sen...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/org-concord-sensor?hl=en?hl=en
Google Code project for org-concord-sensor: http://code.google.com/p/org-concord-sensor/

[Saeid Nourian]

Hi Scott,
I followed your advice but doesn't look like multithreading is
supported. I get exception as soon as i read sensor from a different
thread:

Exception in thread "main" java.lang.IllegalStateException: this is
bad if the stored method is null
at
org.concord.sensor.labquest.jna.SingleThreadDelegator.invokeMethod(SingleThreadDelegator.java:
50)
at org.concord.sensor.labquest.jna.SingleThreadDelegator
$1.invoke(SingleThreadDelegator.java:34)
at $Proxy1.readRawMeasurementsAnalog(Unknown Source)
at
org.concord.sensor.vernier.labquest.LabQuestSensorDevice.read(LabQuestSensorDevice.java:
291)
at
org.concord.netlogosensor.SensorReporter.getSensorValue(SensorReporter.java:
89)
at org.concord.netlogosensor.SensorReporter.main(SensorReporter.java:
147)

SingleThreadDelegator seem to be the cause of this.

Saeid

> ...
>
> read more »

[Scott Cytacki]

Multithreading does work at least in the way that otrunk-sensor uses it.  But I wouldn't be surprised if 

you uncovered a bug.

The point of SingleThreadDelegator is to funnel all access to the device through a single thread.  This is so multiple threads can access the device but all the calls to the device go through a single thread.   Some devices have this constraint in their native library implementations.

Looking at that code I don't see how you can get the error you are reporting. Can I see the code that is causing this error?

My best guess at this point is that the thread of the single thread delegator is being stopped and still used after that.  So then the calls through it are piling up and then this error occurs.  

The single thread delegator thread is started on this line in LabQuestSensorDevice:

labQuest = labQuestLibrary.openDevice(firstDeviceName);

And the thread is stopped whenever labQuest.close() is called in LabQuestSensorDevice.

Scott

[Saeid Nourian]

Hi Scott,
I don't think I'm closing the single thread delegator. Here is my
code:
When I run it I get a single printout from the Thread.run() but then
the JVM crashes.
Do you see anything wrong in the code?

public class SensorReporter {

private SensorDevice device = null;
private int port;
private SensorThread sensorThread;

private class SensorThread extends Thread {
private double value;

public double getValue() {
return value;
}

@Override
public void run() {
final float[] data = new float[1];

while (true) {
final int samples = device.read(data, 0, 0, null);

if (samples != 0)
value = data[0];

System.out.println(value);

try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}

public SensorReporter() {
this.port = 1;
initDevice();
device.start();
sensorThread = new SensorThread();
sensorThread.start();
}

private void initDevice() throws ExtensionException {
final JavaDeviceFactory deviceFactory = new JavaDeviceFactory();
final int deviceId = DeviceID.VERNIER_LAB_QUEST;
device = deviceFactory.createDevice(new DeviceConfigImpl(deviceId,
null));

final ExperimentRequestImpl request = new ExperimentRequestImpl();
request.setPeriod(0.00005f);
request.setNumberOfSamples(-1);

final SensorRequestImpl sensor = new SensorRequestImpl();
sensor.setDisplayPrecision(-2);
sensor.setRequiredMax(Float.NaN);
sensor.setRequiredMin(Float.NaN);
sensor.setPort(port);
sensor.setStepSize(0.1f);
sensor.setType(SensorConfig.QUANTITY_TEMPERATURE);

request.setSensorRequests(new SensorRequest[] {sensor});

final ExperimentConfig actualConfig = device.configure(request);

if (actualConfig == null) {
device.close();
throw new ExtensionException("Sensor device is not attached to the
computer.");
}

if (actualConfig == null || !actualConfig.isValid()) {
device.close();
throw new ExtensionException("Cannot find sensor at port " + port +
".");
}
}

public static void main(final String[] args) throws
ExtensionException {
final SensorReporter sensorReporter = new SensorReporter();

> ...
>
> read more »

[Stephen Bannasch]

Scott, I haven't had time to integrate Saeid's work into the github repo.

If you had time to help get Saeid work integrated into that branch and Saeid up to speed using egit and the github repo that
would be great -- I think it would make digging into just the questions you are both working on right now much faster.