yuanzhou
asked on
Why can this JNI Exception Access Violation Crash be avoided when some printf are plugged in C code?
C DLL connected with Java GUI. It runs well with some debugging printfs to DOS windows are plugged in C code while Exception Access Violation crashes when the debugging printfs are commented off. There are some pointers referred to a large size dynamic memory got from calloc().
Is JNI have some inner limit for dynamic memory referring?
When Crashes, I found the pointer to array in dynamic memory was corrupted unexplainably. When printfs are added back in, the pointers work OK.
Obviously I don't want to release the code with those printfs in the code and debugging outputs hanging over the screen.
Thanks a lot!
Is JNI have some inner limit for dynamic memory referring?
When Crashes, I found the pointer to array in dynamic memory was corrupted unexplainably. When printfs are added back in, the pointers work OK.
Obviously I don't want to release the code with those printfs in the code and debugging outputs hanging over the screen.
Thanks a lot!
CEHJ
Better post the code
ASKER
So many codes and functions interrelated. I guess my description was about the essense of problem. My colleagues also encounterred similar situations and tried to explain it by " printf may change memory and put off memory corruption" but still can't fix it or work around it.
>>So many codes and functions interrelated.
Are there that many commented-out printf statements?
Are there that many commented-out printf statements?
ASKER
Many commented-out statements includes printf. I use VC++ 6.0 to compile the DLL.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Anything commented off is not being accessed by the remaining codes.
ASKER
In JNI, will a JAVA garbage collector corrupt the C pointer to dynamic memory of C DLL?
If commenting out stuff causes it to fail, I'd immediately suspect that you are misusing an automatic variable, most likely a string.
ASKER
I just found one of the pointer reach beyond its define in the C world and corrupt another pointer though I don't quite understand why inserting printfs can put off the crash. Anyway thank you for the helpful discussion.
That's what I meant by automatic variables - when you have strings being displayed, they take up memory space, but if your pointers point to something that overflows into your printf stuff, it doesn't matter too much. When you remove your printfs, it now points into your instructions, corrupting your program and causing a crash.
ASKER
You gave me a very sound reasoning. Thank you very much!
>>but if your pointers point to something that overflows into your printf stuff
How does/can it 'overflow'?
How does/can it 'overflow'?
ASKER
This was a pointer to struct array of dim 300, but the pointer incremented to 20000 to build up a large than expected array, therefore corrupted its neighoring pointer value unless printfs were inserted to keep them isolated, from the understanding I've got now.