[cfe-dev] clang via JNI + libclang-c

[Anton Smirnov]

I'm not sure that it's JNI stack problem.
Let me show you log with comments:

// invoke index() from java to native
10-11 15:35:15.463: ERROR/CLANG_DEBUG(2491): env: [0x40194ce8]
10-11 15:35:15.463: ERROR/CLANG_DEBUG(2491): createIndex();

// &index = 0xbeb06704
10-11 15:35:15.463: ERROR/CLANG_DEBUG(2491): call mapIndex [0xbeb06704]
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): found IndexClass
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): found IndexConstructor
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): found IndexPointerField

// hold CXIndex in array in [0] in native code
// return 0 to java
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): <0x6564805c> hold to index=0
(0x6564805c) -> 0xbeb06704
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): env (parse): [0x40194ce8]

// invoke parse from java and pass 0 as index
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): unmapIndex()
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): <0x6564805c> get from index=0
(0x6564805c) -> 0xbeb06704

// unmapped correctly as index pointer is still 0xbeb06704
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): restored index 0xbeb06704

// now invoking clang parse
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): argument filename:
[./testfile.cpp]
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): args = 0
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): unsaved files = 1
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): found UnsavedFileClass
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): found UnsavedFileConstructor
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): found UnsavedFileFilenameField
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): found UnsavedFileSourceField
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): unsaved file:
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): ./testfile.cpp
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): unsaved file content:
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): { int a = 10; }
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): parsing: index=0xbeb06704
filename=./testfile.cpp args_count=0 files_count=1
        file=./testfile.cpp

// oops, where is filename ? (probably CXIndex at 0xbeb06704 is corrupted
for some reason)
10-11 15:35:15.503: ERROR/CLANG_DEBUG(2491): after parse filename: []
10-11 15:35:15.503: ERROR/CLANG_DEBUG(2491): mapTranslationUnit()
10-11 15:35:15.503: ERROR/CLANG_DEBUG(2491): found TranslationUnitClass
10-11 15:35:15.503: ERROR/CLANG_DEBUG(2491): found
TranslationUnitConstructor
10-11 15:35:15.503: ERROR/CLANG_DEBUG(2491): found
TranslationUnitPointerField

// pack translation unit and return index to java
10-11 15:35:15.503: ERROR/CLANG_DEBUG(2491): hold translationUnit to
index=0 (0x656480dc) -> 0xbeb066c8

// invoke tokenize() from java with tu index = 0
10-11 15:35:15.503: ERROR/CLANG_DEBUG(2491): tokenize: length = 17
10-11 15:35:15.503: ERROR/CLANG_DEBUG(2491): get tu from index=0
(0x656480dc) -> 0xbeb066c8
10-11 15:35:15.503: ERROR/CLANG_DEBUG(2491): unmapped tu 0xbeb066c8
// unpakced ok (the same tu pointer 0xbeb066c8)

10-11 15:35:15.503: ERROR/CLANG_DEBUG(2491): checking unboxed..
10-11 15:35:15.503: ERROR/CLANG_DEBUG(2491): before tokenize filename: []
10-11 15:35:15.503: ERROR/CLANG_DEBUG(2491): <0> tokens

It seems that CXIndex instance was corrupted (during return and next
invocation) somehow as if i invoke clang methods within one native code
method it's okay.

As i said i can try to pack and unpack within one native code method and
it's still okay, so packing/unpacking does not hurt.

JNI env pointer is the same in all java->native code invocations.

I'm in stuck.



2013/10/11 Renato Golin <renato.golin at linaro.org>

> On 11 October 2013 10:17, Anton Smirnov <dev at antonsmirnov.name> wrote:
>
>> i tried to hold CXIndex as static variable in native code (array of
>> pointers to be more detailed) and pass just index to java back and then
>> pass index to native code in order to hold variable in native code without
>> passing.
>>
>> Still the same result.
>>
>
> So, IIRC, it's not the stack itself (stack variables), but the return
> value, that on Intel is at the bottom of the stack. So it doesn't matter
> where your native objects live, if you try to return them (or a pointer to
> them), and the stack itself is too small, it'd subtract too much from the
> stack pointer and then wouldn't find the correct return value because the
> offset would be negative, and you get corrupted pointers.
>
> Adding a "int a[1024]" to each function fixed the problem because even
> subtracting a lot, it'd never be negative when compared to the return
> value, and going back to the return address was still possible. Give it a
> try, at least to see if that's the problem we're looking for.
>
> Be wary that that was 10 years ago, JNI may have bred some new bugs since
> then...
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131011/9fc3401a/attachment.html>