JNI:getUniqueID return value is not fixed?

[AnFengDe]

Test data:
http://epub-samples.googlecode.com/files/kusamakura-japanese-vertical-writing-20121124.epub
http://epub-samples.googlecode.com/files/wasteland-20120118.epub

I wrote test case for check unique id of book by JNI, but sometimes get 'http://www.aozora.gr.jp/cards/000148/card776.html@2012-04-24T00:00:00Z' , sometimes get 'http://www.aozora.gr.jp/cards/000148/card776.html@2012-04-24T00:00:0X'.

I read the code along the call chain, the unique id is constituted by 'dc:identifier' and 'dcterms:modified'.

I think the real reason under the JNI layer.

[AnFengDe]

[prcolaco]

Can you please share a bit of the code that generates that log? Are your tests calling the Java method or the JNI method? It would be great if you could describe a little more so that I can try to reproduce it here. Thanks.

[AnFengDe]

Thanks for your response.
The code in afd branch, you can checkout.

log code in https://github.com/readium/Launcher-Android/blob/afd/Readium_SDK_Test_Android/src/org/readium/sdk/test/util/Util.java (search LOGPACK tag)

[prcolaco]

I was able to reproduce this behavior and it happens only when different calls to Package.nativeGetUniqueID() are issued. For book kusamakura-japanese-vertical-writing-20121124.epub I also got sometimes:
UniqueID: 'http://www.aozora.gr.jp/cards/000148/card776.html@2012-04-24T00:00:0X'
and sometimes:
UniqueID: 'http://www.aozora.gr.jp/cards/000148/card776.html@2012-04-24T00:00:00Z'

Followed the calls down to the core and the strange "mutant" value comes from the expression:

char *data = (char *) pckg->UniqueID().c_str();

which is in the nativeGetUniqueID() JNI function.

This meant that either ePub3::Package::UniqueID() was returning different results somehow, or the ePub3::string::c_str() was messing it up.

So I tried the following:

//char *data = (char *) pckg->UniqueID().c_str();
ePub3::string str = pckg->UniqueID();
char *data = (char *) str.c_str();

and I got the correct result always:
UniqueID: 'http://www.aozora.gr.jp/cards/000148/card776.html@2012-04-24T00:00:00Z'

So it means that some of the casts, either default or defined, on the first line is messing the original result, or some memory corruption in the string handling is happening.

Working on it...

[AnFengDe]

Ha, Great Job!
Yes, I have been try test OSX version, it looks ok, I think it is under JNI layer.

[prcolaco]

The bug has been hunt down! :)

It is in the JNI layer as AFD suggested and is due to:

char *data = (char *) pckg->UniqueID().c_str();

In this line, ePub3::string behaves like std::string, and when c_str() is called it returns an INTERNAL pointer to the string data inside the std::string object it contains!

But in this line the ePub3::string object (that contains the std::string object) is created "on the fly" and destructed after returning the pointer... So we keep a pointer to deleted data!!!

Meaning that this pointer can point to data that is still there, or sometimes to data that has been overwritten or corrupted in some way.

This concludes that the proper way of getting a string from a core object should be:

ePub3::string str = pckg->UniqueID();
char *data = (char *) str.c_str();

This makes the str object exist until the current scope finishes and allow us to "copy" the data to whatever object we want to, i.e. to a jstring to be returned like in the getUniqueID() function.

Going to change all the JNI layer to avoid this problem and will post when done.

Thanks AFD for nice job!!! :)

[prcolaco]

Fixed and pushed to develop. Please run the tests again and close if issue fix is confirmed.

[AnFengDe]

I have been tested, well done.
The newest test case be pushed in afd branch