Native crash in jniwrap64.dll v 3.8.0.0. Can I get PDB?

[Arpi Jakab]

Native crash in jniwrap64.dll v3.8.0.0. Any chance I can get a PDB so I can see where it is crashing in jniwrap64.dll? : msvcr80.dll!__crt_debugger_hook(int _Reserved) Line 65 C msvcr80.dll!_invalid_parameter(const wchar_t * pszExpression, const wchar_t * pszFunction, const wchar_t * pszFile, unsigned int nLine, unsigned __int64 pReserved) Line 88 + 0x77 bytes C++ msvcr80.dll!strcat_s(char * _Dst, unsigned __int64 _SizeInBytes, const char * _Src) Line 42 + 0x23 bytes C jniwrap64.dll!000000001000262e() [Frames below may be incorrect and/or missing, no symbols loaded for jniwrap64.dll] jniwrap64.dll!00000000100027ee() 00000000025d23a8() 00000000d0aa8860() in

[Sergei Piletsky]

Most probably the problem that you are trying to debug is not in JNIWrapper function call. So, a PDB will not be helpful in this case, moreover we do not provide such information.

On Mon, Feb 25, 2013 at 11:35 PM, Arpi Jakab <arp...@gmail.com> wrote:

Native crash in jniwrap64.dll v3.8.0.0. Any chance I can get a PDB so I can see where it is crashing in jniwrap64.dll? : msvcr80.dll!__crt_debugger_hook(int _Reserved) Line 65 C msvcr80.dll!_invalid_parameter(const wchar_t * pszExpression, const wchar_t * pszFunction, const wchar_t * pszFile, unsigned int nLine, unsigned __int64 pReserved) Line 88 + 0x77 bytes C++ msvcr80.dll!strcat_s(char * _Dst, unsigned __int64 _SizeInBytes, const char * _Src) Line 42 + 0x23 bytes C jniwrap64.dll!000000001000262e() [Frames below may be incorrect and/or missing, no symbols loaded for jniwrap64.dll] jniwrap64.dll!00000000100027ee() 00000000025d23a8() 00000000d0aa8860() in

--
You received this message because you are subscribed to the Google Groups "JNIWrapper Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jniwrapper-for...@teamdev.com.
To post to this group, send email to jniwrapp...@teamdev.com.
Visit this group at http://groups.google.com/a/teamdev.com/group/jniwrapper-forum/?hl=en.
For more options, visit https://groups.google.com/a/teamdev.com/groups/opt_out.
 
 

[kha...@mathworks.com]

I too am seeing this in the same version of jniwrap64.
It looks like there's a routine in jniwrap64 that loops through a list of longwords calling ltoa_s and strcat_s. The problem is this list is growing larger than the 256-byte destination string buffer which is what is triggering the MSVC running time to generate the 0xC000000D exception inside strcat_s().

the calling routine is 0x262E off of where ever jniwrap64.dll is loaded (as the OP identified).

I would _really_ appreciate it if you could give us some sense of what this code is doing to help us figure out what's happening, where and why.

Another clue, if I set a bp at jniwrap64.dll + 0x262E, sometimes I never hit it...but when I do, it'll usually lead the invalid-parameter exception -- it looks like there's a list of 30 longs that are being appended into a comma separated list of string representations.

Thank you n advance,
-Ken

[Sergei Piletsky]

OK, let me state my point once again. Such JVM crashes are usually not caused by JNIWrapper itself. They rather indicate some issues in Java code that uses JNIWrapper library. They can be caused by different problems such as incorrect type mapping or usage, improper native resource management, etc. We can help you out with this issue, but only if you send us the complete Java application that reproduces the issue.

-Serge

[Arpi Jakab]

Sorry for not following up sooner. My problem turned out to be two threads calling wininet.dll!InternetQueryOptionW() using jniwrap64 wrapper. The InternetQueryOptionW has some global memory that needs to be cleared up between calls. So as Serge suspected, the problem showed up in jniwrap64.dll, although the memory corruption was caused by improper usage of WinAPI.

- Arpi

[Sergei Piletsky]

Hi Arpi,

Thank you for your feedback.

-Serge

[kha...@mathworks.com]

Hi Serge:

 I'm glad you helped Arpi find his issues. Our investigation has taken us in a different direction.
 We find that when jniwrap64.dll itself, or pointers passed into it are located above 0x7FFFFFFF, it crashes.
 
 Simplified reproduction requires two steps:

 1. Enable "TOP_DOWN" memory address allocation using the following registry modification: "HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\AllocationPreference REG_DWORD = 0x100000" then reboot the PC.

 2. Download and run the demo app (available here: http://www.teamdev.com/jxbrowser/onlinedemo/ ) -- (not the online demo -- it is a 32-bit app – you need the 64-bit demo behind the "DOWNLOAD 101.47 MB" button).
 
 Is there anything else we can provide to help you investigate this further?

 Thank you in advance,
 -Ken

[Sergei Piletsky]

Hi Ken,

Thanks for clarifying.

According to MSDN, the AllocationPreference option is designed to increase virtual address space for 32-bit applications to 4-GB: http://msdn.microsoft.com/en-us/library/windows/desktop/bb613473%28v=vs.85%29.aspx

We do not know why this option affects Java applications which run in 64-bit mode. I have added the request to investigate this issue in one of the next versions of JNIWrapper.

Given that you need to start your application in 64-bit mode, you can remove that option at all, and your 64-bit Java application should start working normally. However, removing that option probably can affect some 32-bit applications which rely on 4-GB tuning (this could be the explanation of why this setting is present in your system), so you can do it at your own risk.

-Serge

[kha...@mathworks.com]

Hi Serge,
Thank you very much for the reply.
I'll try to gather some more info and follow up.
-Ken