search

liuhuasong / nativelibs4java

Automatically exported from code.google.com/p/nativelibs4java
0 stars 0 forks source link

Support JNA-like Structures #54

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Please support JNA-like structures (if possible), i.e.

public class sockaddr extends StructObject
{
    /**
     *
     */
    @Field(0)
    public int sa_family;
    /**
     *
     */
    @Array({16})
    @Field(1)
    public byte[] sa_data;

    /**
     * Constructor.
     */
    public sockaddr()
    {
        super();
    }

    /**
     * Constructor.
     * 
     * @param pointer
     */
    public sockaddr(Pointer pointer)
    {
        super(pointer);
    }
}

Original issue reported on code.google.com by andrei.s...@gmail.com on 8 Mar 2011 at 4:55

GoogleCodeExporter commented 8 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

GoogleCodeExporter commented 8 years ago 
(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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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:

GoogleCodeExporter commented 8 years ago 
This issue was closed by revision r1874.

Original comment by olivier.chafik@gmail.com on 8 Apr 2011 at 5:15

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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:

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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:

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
(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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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:

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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:

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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:

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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:

GoogleCodeExporter commented 8 years ago 
Thanks, I can now reproduce :-)

Cheers
--
zOlive

Original comment by olivier.chafik@gmail.com on 6 May 2011 at 12:41