#420 CanRead() asserts an error in java wrapper

[Hossam Mohammed]

The function CanRead() asserts an error in java wrapper

[Mathieu Malaterre]

Could you please add the backtrace.

[Hossam Mohammed]

sorry I can't understand you

On 18 May 2017 at 12:26, Mathieu Malaterre malat@users.sf.net wrote:

Could you please add the backtrace.

• [bugs:#420] https://sourceforge.net/p/gdcm/bugs/420/ CanRead() asserts
  an error in java wrapper*

Status: open
Group: 2.7
Created: Thu May 18, 2017 09:28 AM UTC by Hossam Mohammed
Last Updated: Thu May 18, 2017 09:28 AM UTC
Owner: Mathieu Malaterre

The function CanRead() asserts an error in java wrapper

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/gdcm/bugs/420/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Mathieu Malaterre]

Could you copy/paste the functions stack pointing to the assert() call. Under gdb, simply type 'bt'. On visual studio you can go up down the stack of functions from the UI.

[Hossam Mohammed]

In C++ no problem but using java wrapper the CanRead() function terminates
the program

On 18 May 2017 at 21:33, Mathieu Malaterre malat@users.sf.net wrote:

Could you copy/paste the functions stack pointing to the assert() call.
Under gdb, simply type 'bt'. On visual studio you can go up down the stack
of functions from the UI.

---

• [bugs:#420] https://sourceforge.net/p/gdcm/bugs/420/ CanRead() asserts
  an error in java wrapper*

Status: open
Group: 2.7
Created: Thu May 18, 2017 09:28 AM UTC by Hossam Mohammed
Last Updated: Thu May 18, 2017 10:25 AM UTC
Owner: Mathieu Malaterre

The function CanRead() asserts an error in java wrapper

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/gdcm/bugs/420/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Mathieu Malaterre]

well then just attach the debugger to your java program.

[Hossam Mohammed]

Here is the back trace :

A fatal error has been detected by the Java Runtime Environment:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffa7c3b8b08, pid=6964, tid=0x0000000000001d80

JRE version: Java(TM) SE Runtime Environment (8.0_121-b13) (build 1.8.0_121-b13)

Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode windows-amd64 compressed oops)

Problematic frame:

C [gdcmDSED.dll+0x58b08] gdcm::Reader::CanRead+0x58

Failed to write core dump. Minidumps are not enabled by default on client versions of Windows

An error report file with more information is saved as:

E:\Hossam\Source Code\OsseoView Beta 5\ov\hs_err_pid6964.log

If you would like to submit a bug report, please visit:

http://bugreport.java.com/bugreport/crash.jsp

The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug.

[Mathieu Malaterre]

you forgot to attach the file: hs_err_pid6964.log

[Hossam Mohammed]

Here you are

[Mathieu Malaterre]

well this log file is extremely hard to read, I would have prefered a neat backtrace. Anyway, I found it suspcious that you have : C:\Program Files\Java\jdk1.8.0_121\jre\bin\gdcmDSED.dll

Are you sure you've installed the latest gdcm over there as well ?

[Hossam Mohammed]

I build the solution after Cmake and get all dlls and gdcm.jar and put them in C:\Program Files\Java\jdk1.8.0_121\jre\bin so what is the problem of gdcmDSED.dll

[Mathieu Malaterre]

So in summary:

• I do not know how to reproduce the issue
• I do not know what version of gdcm your building
• I do not understand why you can reproduce the issue in Java but not in C++ (knowing that the crash happen in the native lib)
• You did not provide a backtrace (with debug symbol and line numbering) showing the issue

I cannot help much. So I am closing until you can provide meaningful inputs.

[Hossam Mohammed]

I got a new information, I am scanning a file which has name "Testkopf_Dr._Jürgens".

In C++ CanRead() returns false but in java it terminates the program but when I remove this letter "ü" from the file name every thing is ok.

for you information :
I am building the version of the branch called release where you remove assert from CanRead().
Concerning the backtrace I can't do this in java as I know.

Thanks very much.

[Mathieu Malaterre]

unicode support in java has been added in 2011, see commit: https://sourceforge.net/p/gdcm/gdcm/ci/24746bf1

[Hossam Mohammed]

so I don't know why this problem occurs although unicode is supported from 2011.

[Hossam Mohammed]

I got the problem after debugging in Win32 mode.

In file gdcmJAVA_wrap.cxx the function JNU_GetStringNativeChars .
For file name "Testkopf_Dr.Jürgens" when we call this line

jmethodID MID_String_getBytes = env->GetMethodID(
Class_java_lang_String, "getBytes", "()[B");
bytes = (jbyteArray) env->CallObjectMethod(jstr,
MID_String_getBytes);

so we get two bytes for "ü" and after this lines

exc = env->ExceptionOccurred();
if (!exc) {
jint len = env->GetArrayLength(bytes);
result = (char )malloc(len + 1);
if (result == 0) {
JNUThrowByName(env, "java/lang/OutOfMemoryError",
0);
env->DeleteLocalRef(bytes);
return 0;
}
env->GetByteArrayRegion(bytes, 0, len,
(jbyte )result);
result[len] = 0; / NULL-terminate /*

so we end up by result = "Testkopf_Dr.Jürgens.ovx" so in CanRead function

std::istream &is = *Stream;
if( is.bad() ) return false;

so Stream=Null and we can't call is.bad().

This is the full description of the error.

[Hossam Mohammed]

What is your opinion?

[Mathieu Malaterre]

Great ! At least you are able to debug your dll now. Could you please add a breakboint in gdcm::Reader::SetFileName. And tell me what is going on there? I suspect std::ifstream::open does not work... technically it should since it is documented here:

http://www.cognaxon.com/cached/support/java/pitfalls.html

10.10 Disregarding Internationalization

Strings in the Java virtual machine consist of Unicode characters, whereas native strings are typically in a locale-specific encoding. Use utility functions such as JNU_NewStringNative (§8.2.1) and JNU_GetStringNativeChars (§8.2.2) to translate between Unicode jstrings and locale-specific native strings of the underlying host environment.

[Hossam Mohammed]

In gdcm::Reader::SetFileName

if( Ifstream->is_open() )

as you expect returns false

Ifstream = NULL;
Stream = NULL;

The problem as I see is in "getBytes" function in java

[Mathieu Malaterre]

I cannot help much from over here. Could you try the following dumb patch to see if the wchar_t API is working for you:

diff --git a/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx b/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx
index a3bc9bb..530daf6 100644
--- a/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx
+++ b/Source/DataStructureAndEncodingDefinition/gdcmReader.cxx
@@ -1005,7 +1005,8 @@ void Reader::SetFileName(const char *filename)
 {
   if(Ifstream) delete Ifstream;
   Ifstream = new std::ifstream();

-  Ifstream->open(filename, std::ios::binary);
+  wchar_t * wfilename =  (wchar_t*)filename;
+  Ifstream->open(wfilename, std::ios::binary);
   if( Ifstream->is_open() )
     {
     Stream = Ifstream;

The next step is to compare the series of bytes when using direct C++ code and when using the java/jstring conversion from unicode... good luck :)

[Hossam Mohammed]

The value of wfilename is "敔瑳潫晰䑟⹲䩟볃杲湥⹳癯x﷽﷽" which is incoreect.
For bytes comparison there is one extra byte when using the java/jstring conversion from unidode resulting from using "getBytes" function for the letter "ü".

[Mathieu Malaterre]

tons of unicode fix have been made lately.