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

[Anton Smirnov]

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

> On 11 October 2013 10:42, Anton Smirnov <dev at antonsmirnov.name> wrote:
>
>> 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
>>
>
> So, here, the object address was correct, in the array.
>
>
> // 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: []
>>
>
> Is this from another call? Can you print the address/contents of the array?
>

yes, index instance address is within <>:
10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): <0x6564805c> hold to index=0
(0x6564805c) -> 0xbeb06704


> It might be that the array is pointing to the wrong place, or the array's
> own address has somehow changed, thus it's not CXIndex that is corrupted,
> but the array representation.
>

no, the same array pointer after unmap (after passing long from java to
native code):

10-11 15:35:15.473: ERROR/CLANG_DEBUG(2491): <0x6564805c> get from index=0
(0x6564805c) -> 0xbeb06704

if array pointer is different then array[0] will be different most likely,
but it's exactly the same:
0xbeb06704


>
>
> // 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
>>
>
> Is this still the array? The address is different than you use to have
> earlier.
>

0xbeb066c8 is CXTranslationUnit instance address, not CXIndex instance
address. While parsing right index instance address is passed (
index=0xbeb06704):
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


> cheers,
> --renato
>

My idea is not CXInstance pointer address is corrupted (it's exactly the
same), but memory for this address.

I can provide code output where all the clang invocations are done with one
single native invocation and it works (tokens are found).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131011/8e83e361/attachment.html>