Discussions
Categories
- 196.9K All Categories
- 2.2K Data
- 239 Big Data Appliance
- 1.9K Data Science
- 450.4K Databases
- 221.7K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 550 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 546 SQLcl
- 4K SQL Developer Data Modeler
- 187.1K SQL & PL/SQL
- 21.3K SQL Developer
- 295.9K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.6K Development Tools
- 107 DevOps
- 3.1K QA/Testing
- 646K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 155 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 18 Java Essentials
- 160 Java 8 Questions
- 86K Java Programming
- 80 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 443 LiveLabs
- 38 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 232 Portuguese
Invocation API and -Xss Issues?

Are there any known issues with using -Xss to set thread stack size when embedding the JVM in a native process via JNI_CreateJavaVM? We are seeing SEGV raised by non-Java threads when -Xss is used. The crashes stop when -Xss is removed.
Answers
-
One alternative could be that there is a bug in the JNI code. The use of the option ends up allowing the bug to impact the application space in a way that the OS detects it - and thus the SEGV.
-
While a user level bug is certainly a possibility what's strange about this case is there are no user level threads making JNI calls at the time of the crash. We've also determined the crash occurs on OEL but not on Solaris Sparc, other platforms to be tested soon. The question here is simply if there are any known issues. My queries of bugdb did not yield any.
-
> there are no user level threads making JNI calls at the time of the crash.
Irrelevant.
SEGV occurs because the OS detected that the application did something bad. That can occur any time once the bug occurs. It might be immediately or hundreds of lines later. For example if the code corrupts the native heap then the fault might not occur until the native heap manager attempts to compress the heap which can occur much later.
> We've also determined the crash occurs on OEL but not on Solaris Sparc
Different execution paths which means the potential for different behavior. So in one case it does something the OS sees in the other it doesn't.