Closed GoogleCodeExporter closed 9 years ago
Hi Andrei,
While easy to write, JNA-style structures are inherently bad, for two main
reasons :
- they introduce memory duplication, with necessary read() / write() steps (and
auto-write mechanism) that are hard to grok
- they are slower (everything gets copied back and forth)
BridJ strives for maximum speed, and the current design achieves that.
However, it has indeed become harder to write struct bindings by hand.
One *shouldn't* write structs by hand, the use of JNAerator is, if not
compulsory, strongly recommended.
In earlier versions of BridJ, I used an in-between approach :
{{{
public native int sa_family();
public native void sa_family(int value);
}}}
But it turned out that some Java code was needed anyway in the native binding,
and the result was very poorly-performing structs.
I might manage to switch back to native methods someday, but in the meanwhile
it's safer to use JNAerator : it will adapt to future binding methods.
To use JNAerator in a Maven project, you can add a jnaerator.config file in
src\main\jnaerator and put your C/C++ headers somewhere, as it's done for
instance in the JavaCL project :
http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/OpenCL/Op
enCL4Java/
(the bindings can then be regenerated with 'mvn jnaerator:jnaerate').
Cheers
Original comment by olivier.chafik@gmail.com
on 8 Mar 2011 at 6:15
(FYI there are very simple benchmarks in BridJ's automatic tests, with a
comparison between the structs from Javolution, JNA and BridJ vs. hand-written
NIO-based structs : build from sources and run 'mvn test -Dtest=ComparisonTest'
to see how bad JNA structs can be, even in the simplest cases ;-))
Original comment by olivier.chafik@gmail.com
on 8 Mar 2011 at 6:41
This is really great that BridJ's 'maximum speed' mode is implemented already,
but I think for most classes it is not critical.
May be 2-3 classes (probably used in callbacks) may require 'maximum speed'.
Thanks for accepting the task.
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 8 Mar 2011 at 6:52
I've implemented this feature partially (attached).
Methods:
- public int sizeOf(Object o);
- public int sizeOf(Class type);
- public Pointer<?> allocate(final Object o);
- public Object read(Pointer<?> ptr, final Class type);
- public Object write(Pointer<?> ptr, final Object o);
- public void print(final Object o); - prints object fields (for debugging)
- public void printFieldsLayout(final Class type); - prints fields layout:
offset/size (for debugging).
Big/little endian order is handled,
alignment is not handled 'cause I don't know what is it and is it critical or
not :)
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 8 Apr 2011 at 1:22
Attachments:
This issue was closed by revision r1874.
Original comment by olivier.chafik@gmail.com
on 8 Apr 2011 at 5:15
Hi Andrei,
Thanks a lot for contributing your code.
Here are some remarks about it :
- I don't understand why you implemented these TypeIO classes : Pointer<T> or
PointerIO<T> should be enough for all your needs here (unless you have a good
reason to use byte[] instead of Pointer<Byte>)
- You should avoid duplicating code as in the various TypeIO classes, as it
becomes very long to read and write and hardly maintainable : you can look at
BridJ's sources to see how to write templates, and use a simular Maven pom.xml
to automate the source template instantiation (look at Pointer, for instance :
http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/Runtime/B
ridJ/src/main/velocity/org/bridj/Pointer.java)
- Struct and fields alignment is a capital matter that is already dealt with
properly in StructIO. It creates gaps between fields so that each field's
address is aligned so some boundary. I encourage you to read its
computeStructLayout() method
(http://code.google.com/p/nativelibs4java/source/browse/trunk/libraries/Runtime/
BridJ/src/main/velocity/org/bridj/StructIO.java)
Anyway, I've just implemented JNA-like fields in BridJ (which prints a
performance warning), since you appear to find this very important ;-).
In the process, I've fixed an issue with inherited structs :-D
This is fixed by revision #1874, available in freshly-deployed version
0.5-SNAPSHOT.
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 8 Apr 2011 at 5:22
Thanks! not sure how to use it :)
Nevertheless attached code throws NullPointerException in StructIO:
Caused by: java.lang.NullPointerException
at org.bridj.StructIO.readFieldsFromNative(StructIO.java:596)
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 8 Apr 2011 at 6:06
Attachments:
Hi Andrei,
Just to let you know that I'm working on this right now :-)
Side note : please don't use byte[] but Pointer<Byte> for your guid array field
(doesn't fix your crash yet, but still important :-)).
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 10 Apr 2011 at 8:01
Hi Andrei,
Your code now runs fine with the latest snapshot (I just modified GUID to use
Pointer<Byte> instead of byte[], please see attachment).
Thanks again for your patience and feedback :-)
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 10 Apr 2011 at 10:57
Attachments:
Hi Olivier,
Thank you very much. It works! :)
Is it possible to add some debugging features:
1. public void printFieldsLayout(final Class type) that prints fields layout,
like in provided BridJX.java.
For example,
org.bridj.demos.win.com.AM_MEDIA_TYPE 72
name offset/size (elements) type
majortype 0/16 (1) org.bridj.demos.win.com.GUID
subtype 16/16 (1) org.bridj.demos.win.com.GUID
bFixedSizeSamples 32/4 (1) int
bTemporalCompression 36/4 (1) int
lSampleSize 40/4 (1) int
formattype 44/16 (1) org.bridj.demos.win.com.GUID
pUnk 60/4 (1) org.bridj.Pointer
cbFormat 64/4 (1) int
pbFormat 68/4 (1) org.bridj.Pointer
that will make easier to debug struct issues if any.
2. public void print(final Object o) - prints fields values, like in provided
BridJX.java.
3. Is it possible to enumerate methods with parameters found in the *.dll
(*.so) library?
Thanks & Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 10 Apr 2011 at 11:27
Hi Sergei,
Glad it works !
I've followed your suggestions and added BridJ.describe(Type) and
BridJ.describe(NativeObject) (and StructObject.toString() now returns
BridJ.describe(this) by default).
The struct layout is now printed if you set BRIDJ_DEBUG=1 or -Dbridj.debug=true.
(see revision #1879)
As for iterating on methods / functions, you can use
BridJ.getNativeLibrary(name).getSymbols() and call getParsedRef() on each
Symbol.
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 10 Apr 2011 at 1:38
(also, for symbols iteration : beware that C++-mangled functions/methods do
contain return types on Windows but not on other OSes, and that COM dlls seldom
contain any exported symbol)
Original comment by olivier.chafik@gmail.com
on 10 Apr 2011 at 1:43
Thank you very much!
I've downloaded the latest jar but there is one more NullPointerException:
Caused by: java.lang.NullPointerException
at java.lang.Class.isAssignableFrom(Native Method)
at org.bridj.PointerIO.getInstance(PointerIO.java:131)
at org.bridj.PointerIO.getPointerInstance(PointerIO.java:77)
Reproduce:
AM_MEDIA_TYPE am = new AM_MEDIA_TYPE();
String s = BridJ.describe(am);
System.out.println(s);
It seems the same exception is thrown if you launch TestDirectShowVideoCapturer.
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 10 Apr 2011 at 6:41
Oops, sorry about that... I've changed something on MacOS X without testing it
on Windows... silly me !
This is now fixed...
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 10 Apr 2011 at 9:30
Hi Olivier,
Thank you very much. StructObject looks perfect now!!!
But I have issue with callbacks now.. it doesn't work for some reasons..
class com.smaxe.os.bridj.example.ExAviCapVideoCapturer (in attached sources).
Sometimes it throws many NullPointerExceptions (seems like callback method to
invoke is NULL) or causes JVM crash.
Also basic callback example com.smaxe.os.bridj.TestBridJ throws Exception:
TestBridJ main method:
public static void main(final String[] args)
{
capVideoStreamCallback callback = new VideoCallback();
System.out.println("apply");
callback.apply(null /*hwnd*/, null /*pvhdr*/);
Pointer<?> ptr = Pointer.pointerTo(callback);
System.out.println("ptr: " + ptr);
System.out.println("apply 2: ");
((capVideoStreamCallback) ptr.get()).apply(null /*hwnd*/, null /*pvhdr*/);
System.out.println("success");
}
Exception:
Exception in thread "main" java.lang.RuntimeException: Failed to cast pointer
to native object of type com.smaxe.os.bridj.win32.VideoCallback
at org.bridj.BridJ.createNativeObjectFromPointer(BridJ.java:189)
at org.bridj.Pointer.getNativeObjectAtOffset(Pointer.java:594)
at org.bridj.Pointer.getNativeObjectAtOffset(Pointer.java:601)
at org.bridj.CommonPointerIOs$CallbackPointerIO.get(CommonPointerIOs.java:127)
at org.bridj.CommonPointerIOs$CallbackPointerIO.get(CommonPointerIOs.java:114)
at org.bridj.Pointer.get(Pointer.java:713)
at org.bridj.Pointer.get(Pointer.java:5318)
at org.bridj.Pointer.get(Pointer.java:689)
at com.smaxe.os.bridj.TestBridJ.main(TestBridJ.java:36)
Caused by: java.lang.RuntimeException: Failed to cast pointer Pointer(peer =
0x3160000, targetType = com.smaxe.os.bridj.win32.VideoCallback) to instance of
type com.smaxe.os.bridj.win32.VideoCallback
at org.bridj.CRuntime$CTypeInfo.cast(CRuntime.java:124)
at org.bridj.BridJ.createNativeObjectFromPointer(BridJ.java:184)
... 8 more
Caused by: java.lang.RuntimeException: Failed to create implementation class
for callback type com.smaxe.os.bridj.win32.VideoCallback :
java.lang.RuntimeException: Callback com.smaxe.os.bridj.win32.VideoCallback
doesn't have any abstract method.
at org.bridj.CallbackNativeImplementer.getCallbackImplType(CallbackNativeImplementer.java:81)
at org.bridj.CRuntime.getTypeForCast(CRuntime.java:412)
at org.bridj.CRuntime$CTypeInfo.getCastClass(CRuntime.java:113)
at org.bridj.CRuntime$CTypeInfo.cast(CRuntime.java:120)
... 9 more
Caused by: java.lang.RuntimeException: Callback
com.smaxe.os.bridj.win32.VideoCallback doesn't have any abstract method.
at org.bridj.CallbackNativeImplementer.getCallbackImplType(CallbackNativeImplementer.java:62)
... 12 more
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 11 Apr 2011 at 12:39
Attachments:
Hi Andrei,
The last issue comes from the fact that ptr is a Pointer<VideoCallback>.
You can cast it to a capVideoStreamCallback pointer with this line instead :
Pointer<capVideoStreamCallback> ptr =
Pointer.pointerTo(callback).as(capVideoStreamCallback.class);
As for the ExAviCapVideoCapturer case, I'm investigating it right now :-)
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 15 Apr 2011 at 4:00
Hi Olivier,
Thank you very much.
Callbacks are the last feature I need to port code from JNA to BridJ.
As to capVideoStreamCallback:
capVideoStreamCallback callback = new VideoCallback();
callback.apply(null /*hwnd*/, null /*pvhdr*/);
Pointer<capVideoStreamCallback> ptr =
Pointer.pointerTo(callback).as(capVideoStreamCallback.class);
(capVideoStreamCallback) ptr.get()).apply(null /*hwnd*/, null /*pvhdr*/);
This code works correctly, but
VideoCallbackcallback = new VideoCallback();
callback.apply(null /*hwnd*/, null /*pvhdr*/);
Pointer<VideoCallback> ptr = Pointer.pointerTo(callback);
(VideoCallback) ptr.get()).apply(null /*hwnd*/, null /*pvhdr*/);
doesn't work. The same exception as above is thrown. Is it ok or ..?
Thanks, Andrei.
Original comment by andrei.s...@gmail.com
on 15 Apr 2011 at 4:23
Hi Andrei,
I've just fixed the capVideoStreamCallback issue (namely, the VideoCallback
class not being treated correctly due to the fact that it doesn't derive
directly from Callback), in revision #1894 and latest Maven snapshot.
As an aside, I see that VideoCallback returns pointerToInt(1). This might cause
illegal memory access in the caller code, because the JVM will GC this pointer
whenever it sees fit. I recommend using a statically-allocated pointer that
will be reused, if possible.
Anyway, thanks for your feedback and stay tuned for the rest :-)
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 15 Apr 2011 at 4:47
Oh, I get it : you meant `Pointer.pointerToAddress(1)` ((LRESULT)1), not
`Pointer.pointerToInt(1)` (new int[] { 1 }) :-)
Original comment by olivier.chafik@gmail.com
on 15 Apr 2011 at 4:55
Yes, in JNA this callback looks like:
private final class VideoCaptureCallback extends Object implements
capVideoStreamCallback
{
public LRESULT callback(final HWND hwnd, final VIDEOHDR vhdr)
{
// some processing
return new LRESULT(1);
}
}
capVideoStreamCallback docs are available at
http://msdn.microsoft.com/en-us/library/dd797759%28v=vs.85%29.aspx
Thanks, Andrei.
Original comment by andrei.s...@gmail.com
on 15 Apr 2011 at 5:04
Hi Olivier,
Any idea regarding "callback issue"? Were you able to reproduce it on your
system?
Thanks, Andrei.
Original comment by andrei.s...@gmail.com
on 16 Apr 2011 at 8:02
Hi Andrei,
I've reproduced the issue, I'm currently trying to understand what's going on
(and fixing the crash-protection mechanism in the process :-)).
Sorry for the slow progress, I'll let you know as soon as I make a breakthrough.
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 16 Apr 2011 at 10:26
Great! The most important is that you can reproduce it! :)
Thanks for your efforts!
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 16 Apr 2011 at 10:44
Hehe, I've identified and fixed a major issue : Pointer arguments weren't
supported in callbacks !
(only @Ptr long was supported, this is fixed by revision #1898 and available in
latest snapshot)
Btw, for 32/64 bits compatibility you should ditch your second SendMessageA
binding in favour of something like this :
public static native Pointer<?> SendMessageA(Pointer<?> hWnd, int msg, @Ptr
long wParam, @Ptr long lParam)
Thanks for your continued patience and perfect feedback :-)
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 17 Apr 2011 at 12:24
Thank you very much!
Callback method is invoked correctly several times at the beginning, after that
it throws exception:
java.lang.RuntimeException: Failed to instantiate pointer of type
com.smaxe.os.bridj.win32.HWND
at com.smaxe.os.bridj.win32.lib.User32.SendMessageA(Native Method)
at com.smaxe.os.bridj.win32.AviCap.capGrabFrameNoStop(AviCap.java:331)
at com.smaxe.os.bridj.win32.support.VideoCaptureDevice$CaptureRunnable.run(VideoCaptureDevice.java:229)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalMonitorStateException
... 4 more
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 17 Apr 2011 at 1:12
Also when trying to read VIDEOHDR in the callback:
public Pointer apply(final HWND hwnd, final Pointer pvhdr)
{
System.out.println("apply");
VIDEOHDR vhdr = new VIDEOHDR(pvhdr);
BridJ.readFromNative(vhdr);
System.out.println(vhdr);
return Pointer.pointerToAddress(1);
}
it throws
java.lang.IllegalMonitorStateException
at com.smaxe.os.bridj.win32.lib.User32.SendMessageA(Native Method)
at com.smaxe.os.bridj.win32.AviCap.capGrabFrameNoStop(AviCap.java:331)
at com.smaxe.os.bridj.win32.support.VideoCaptureDevice$CaptureRunnable.run(VideoCaptureDevice.java:237)
at java.lang.Thread.run(Thread.java:619)
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 17 Apr 2011 at 1:24
Hum, weird...
This issue does not happen if you change your callback's signature to :
public Pointer<?> apply(final Pointer<?>/*HWND*/ hwnd, final Pointer<VIDEOHDR>
pvhdr);
Dunno why yet, might be related to callIO instances not being hard-referenced
(they're the ones responsible for instantiating exotic pointers), or something
like that...
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 17 Apr 2011 at 9:40
Oh, by the way : please don't use Java arrays in struct fields (they're not yet
supported) :
Instead of :
@Field(6) @Array({4}) public Pointer<?>[] dwReserved;
Rather use :
@Field(6) @Array({4}) Pointer<Pointer<Integer>> dwReserved;
Original comment by olivier.chafik@gmail.com
on 17 Apr 2011 at 9:42
Also, the readFromNative call will be performed automatically upon a typed
pointer's get() call :
public Pointer<?> apply(final Pointer<?>/*HWND*/ hwnd, final Pointer<VIDEOHDR>
pvhdr)
{
System.out.println("apply");
VIDEOHDR vhdr = pvhdr.get();
//BridJ.readFromNative(vhdr);
System.out.println(vhdr);
return Pointer.pointerToAddress(1);
}
Original comment by olivier.chafik@gmail.com
on 17 Apr 2011 at 9:46
Hi Olivier,
Regarding arrays.. I noticed BridJ warning and fixed it. Thanks!
Regarding callbacks:
- If
public Pointer<?> apply(final Pointer<?> hwnd, final Pointer<VIDEOHDR> pvhdr)
callback is used then exception is thrown:
java.lang.RuntimeException: Pointer is not typed (call Pointer.as(Type) to
create a typed pointer) : Cannot get pointed value
at com.smaxe.os.bridj.win32.lib.User32.SendMessageA(Native Method)
at com.smaxe.os.bridj.win32.AviCap.capGrabFrameNoStop(AviCap.java:331)
at com.smaxe.os.bridj.win32.support.VideoCaptureDevice$CaptureRunnable.run(VideoCaptureDevice.java:243)
at java.lang.Thread.run(Thread.java:619)
- But
public Pointer<?> apply(final Pointer<?> hwnd, final Pointer<?> pvhdr)
{
System.out.println("apply");
VIDEOHDR vhdr = (VIDEOHDR) pvhdr.as(VIDEOHDR.class).get();
System.out.println("apply2");
return Pointer.pointerToAddress(1);
}
callback doesn't read video header and never returns from "read" action, i.e.
"apply" is printed, but "apply2" not.
PS. I used the latest snapshot.
Thanks, Andrei.
Original comment by andrei.s...@gmail.com
on 17 Apr 2011 at 12:42
I fixed a major calling convention issue in revision #1901 (available in latest
snapshot), but it still looks like there is some IllegalMonitorStateException
happening here and there...
Cheers
--
Olivier
Original comment by olivier.chafik@gmail.com
on 17 Apr 2011 at 5:20
Thanks.
I tested the latest snapshot and it behaves similarly to the previous.
Did you update the snapshot? It looks like latest snapshot is older than latest
revision.
Thanks, Andrei.
Original comment by andrei.s...@gmail.com
on 17 Apr 2011 at 7:11
Hi Andrei,
Actually, there's a two-hour time shift between the maven repo and the SVN
server, and the snapshot was indeed updated.
I can reproduce the befuddling IllegalMonitorStateException problem so I expect
it to haunt me for the start of next week...
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 17 Apr 2011 at 9:59
Hi Olivier,
I don't think the latest snapshot improved callback :)
For some reasons:
public Pointer<?> apply(final Pointer<?> hwnd, final Pointer<?> pvhdr)
{
System.out.println("apply");
BridJ.sizeOf(VIDEOHDR.class);
System.out.println("apply2");
return Pointer.pointerToAddress(1);
}
freezes on the "BridJ.sizeOf(VIDEOHDR.class);" line and never prints "apply2"
or returns from callback.
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 21 Apr 2011 at 7:57
Hi Andrei,
I've identified what might be *the* main issue here (I'm dumbly reusing the
same JNIEnv pointer between different threads in the callback).
I'm working on it, please be patient...
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 25 Apr 2011 at 8:15
Hi Andrei,
Hope you haven't given up on BridJ yet ;-)
I've deployed a new 0.5-SNAPSHOT version of BridJ with a major fix for
callbacks that are called in a different thread than the one they were created
from (see revision #1909).
It appears to fix the hanging / crash / IllegalThreadMonitorStateException with
your code on my Windows box.
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 25 Apr 2011 at 9:15
Hi Olivier,
Great! This is definitely a HUGE success!
Avicap example is working now :)
pcap example throws some exceptions at present. I'll review it and let you know.
Thank you very much!
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 25 Apr 2011 at 9:36
Hi Olivier,
I think BridJ.writeToNative(*) has a bug (test example attached).
Description:
There are StructA with "int field0" and "int field1" fields and StructB
with "StructA field0" and "int field1".
If I set StructB.field0.field0 to "value" and BridJ.writeToNative(StructB) then
StructB.field0.field0 is not written to the native.
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 26 Apr 2011 at 1:14
Attachments:
Hi Andrei,
Thanks for your continued feedback !
This nested struct read/write issue is fixed by revision #1914 and is available
in the latest snapshot :-)
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 26 Apr 2011 at 2:32
Hi Olivier,
Great! Thank you very much.
Will be possible to add JNA-like feature to map MyMethod to MyMethodW or
MyMethodA?
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 26 Apr 2011 at 2:43
Hi Olivier,
Other issue was found in the case when StructA contains Pointer<StructA> field
(test example attached).
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 26 Apr 2011 at 6:05
Attachments:
Hi Andrei,
Thanks for spotting this new issue, it is fixed in revision #1926 (I've
redeployed a snapshot :-)).
(and for the public record, as I've told you by email, the Unicode vs. ANSI
feature you've suggested was added in revision #1917).
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 26 Apr 2011 at 10:46
Hi Olivier,
Thanks!
The latest build added a new bug to org.bridj.jawt.JAWTUtils:
java.lang.RuntimeException: Pointer is not typed (call Pointer.as(Type) to
create a typed pointer) : Cannot get pointed value
at org.bridj.Pointer.throwBecauseUntyped(Pointer.java:744)
at org.bridj.Pointer.getIO(Pointer.java:3487)
at org.bridj.Pointer.get(Pointer.java:713)
at org.bridj.Pointer.get(Pointer.java:5344)
at org.bridj.Pointer.get(Pointer.java:689)
at org.bridj.jawt.JAWTUtils.getNativePeerHandle(JAWTUtils.java:88)
at com.smaxe.os.bridj.example.ExAviCapVideoCapturer.main(ExAviCapVideoCapturer.java:82)
Also I have
java.lang.RuntimeException: Native exception (code = 0xC0000005)
at com.smaxe.os.bridj.pcap.PcapLibrary.pcap_loop(Native Method)
at com.smaxe.os.bridj.pcap.support.NetworkDevice$CaptureRunnable.run(NetworkDevice.java:244)
at java.lang.Thread.run(Thread.java:619)
exception called when callback method is invoked. Is it possible to debug it
somehow or to provide source code?
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 27 Apr 2011 at 7:33
Hi Andrei,
The JAWT issue is hopefully fixed in revision #1928, but you're gonna need to
build it from sources as my Mac's HD just died :
http://code.google.com/p/bridj/wiki/Build
As for the native exception, it's an illegal access error that would tend to
indicate that an invalid pointer is being used in the native code (did you pass
it a buffer large enough ?). If you built pcap from sources and / or have debug
symbols for it readily available, you can launch Java in gdb / Eclipse CDT / MS
Visual Studio and see where the debugger breaks, otherwise the native code will
perform as a black box and you can just triple-check the arguments you pass to
it.
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 27 Apr 2011 at 9:42
Hi Olivier,
Thank you very much! but I will wait for you build :)
As to pcap... I am using the latest WinPcap dll
(http://www.winpcap.org/install/default.htm). Ok, i will check arguments.
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 27 Apr 2011 at 12:02
Hehe, you may try now (hope the deployed jar is correct...)
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 27 Apr 2011 at 12:14
Thanks, tested, no JAWT exception anymore, but I get:
java.lang.RuntimeException: Native exception (code = 0xC0000005)
at com.smaxe.os.bridj.win32.lib.User32.SendMessageA(Native Method)
at com.smaxe.os.bridj.win32.AviCap.capGrabFrameNoStop(AviCap.java:318)
at com.smaxe.os.bridj.win32.support.VideoCaptureDevice$CaptureRunnable.run(VideoCaptureDevice.java:239)
at java.lang.Thread.run(Thread.java:619)
with the code that worked yesterday correctly :)
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 27 Apr 2011 at 12:26
Hi Andrei,
This exception indicates a native crash (illegal memory access) that was caught
by the new crash protection mechanism.
Could you attach your up-to-date code ? (with the latest attachment I get no
such error on my test Windows box).
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 6 May 2011 at 12:23
Hi Olivier,
I tested with the latest update (today) and the same happens.
Code attached.
Regards, Andrei.
Original comment by andrei.s...@gmail.com
on 6 May 2011 at 12:35
Attachments:
Thanks, I can now reproduce :-)
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 6 May 2011 at 12:41
Original issue reported on code.google.com by
andrei.s...@gmail.com
on 8 Mar 2011 at 4:55