0

I wrote java wrappers for LibClang API. Wrapper for clang_visitChildren works good for comparatively small c-source files (less than 200 first level childs). But it crashed for more large source file in area of 550-560 first level child. My callback returns 1 (i.e. one level loop, not recursive). The message is following:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f41a907adea, pid=21347, tid=139920175146752
#
# JRE version: OpenJDK Runtime Environment (7.0_95) (build 1.7.0_95-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.95-b01 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea 2.6.4
# Distribution: Ubuntu 14.04.3 LTS, package 7u95-2.6.4-0ubuntu0.14.04.1
# Problematic frame:
# J 63 C2 com.sun.jna.Native.getNativeSize(Ljava/lang/Class;Ljava/lang/Object;)I (145 bytes) @ 0x00007f41a907adea [0x00007f41a907aac0+0x32a]
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/itrub/ruslan/hs_err_pid21347.log
Compiled method (c2)     440   63   !         com.sun.jna.Native::getNativeSize (145 bytes)
 total in heap  [0x00007f41a907a850,0x00007f41a907c070] = 6176
 relocation     [0x00007f41a907a970,0x00007f41a907aac0] = 336
 main code      [0x00007f41a907aac0,0x00007f41a907b3e0] = 2336
 stub code      [0x00007f41a907b3e0,0x00007f41a907b428] = 72
 oops           [0x00007f41a907b428,0x00007f41a907b4c0] = 152
 scopes data    [0x00007f41a907b4c0,0x00007f41a907bca0] = 2016
 scopes pcs     [0x00007f41a907bca0,0x00007f41a907bff0] = 848
 dependencies   [0x00007f41a907bff0,0x00007f41a907bff8] = 8
 handler table  [0x00007f41a907bff8,0x00007f41a907c040] = 72
 nul chk table  [0x00007f41a907c040,0x00007f41a907c070] = 48
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
#

Could somebody give me good advice about possible ways of problem solution?

Iliya Trub
  • 1
  • 1
  • Perhaps you could share those wrappers/mappings and include the full stack trace ending in the call to `com.sun.jna.Native.getNativeSize()`? – technomage Feb 12 '16 at 15:58
  • I'd like to share solution, that I get. getNativeSize() is not a thing. I discovered, that fatal errors always occur at method isAssignableFrom(type) of class Class. https://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#isAssignableFrom%28java.lang.Class%29 I have changed some invocations in JNA by hardcoded 'false', when type is int, because int is elementary type and it can not have superclass. After that program reached the correct finish. May be, isAssignableFrom has memory leaks in OpenJDK. – Iliya Trub Feb 15 '16 at 12:20

0 Answers0