Discussions
Categories
- 197.1K All Categories
- 2.5K Data
- 546 Big Data Appliance
- 1.9K Data Science
- 450.7K Databases
- 221.9K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 552 MySQL Community Space
- 479 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.1K ORDS, SODA & JSON in the Database
- 555 SQLcl
- 4K SQL Developer Data Modeler
- 187.2K SQL & PL/SQL
- 21.3K SQL Developer
- 296.3K Development
- 17 Developer Projects
- 139 Programming Languages
- 293K Development Tools
- 110 DevOps
- 3.1K QA/Testing
- 646.1K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 158 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.2K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 19 Java Essentials
- 162 Java 8 Questions
- 86K Java Programming
- 81 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
- 466 LiveLabs
- 39 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 175 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 233 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.