JVM crash in libc.so

The worst monsters in the Hearthlands warp the fabric of space and time...

JVM crash in libc.so

Postby mvgulik » Wed Oct 21, 2020 1:55 am

(Moderation note: I split this off from the JVM crash thread, since i'd like that thread to be about JVM crashes themselves, rather than a place to discuss any particular problem that results in a JVM crash.)

So that's what this stuff is.
Image

Are there any part of particular interest ... as direct posting some of those seems a bit awkward.
([i]can see about PM with archive-file link
)
Last edited by loftar on Wed Oct 21, 2020 6:02 pm, edited 2 times in total.
Reason: Split thread
mvgulik
 
Posts: 3742
Joined: Fri May 21, 2010 2:29 am

Re: Information about JVM crashes

Postby loftar » Wed Oct 21, 2020 2:06 am

mvgulik wrote:Are there any part of particular interest ... as direct posting some of those seems a bit awkward.

Those are some really huge crash logs. They aren't usually anywhere near that huge; I wonder if they've added some new information to the logs. Anyway, the most interesting part is the first part up until and including the (native) stackframe of the crashing thread.
"Object-oriented design is the roman numerals of computing." -- Rob Pike
User avatar
loftar
 
Posts: 8926
Joined: Fri Apr 03, 2009 7:05 am

Re: Information about JVM crashes

Postby mvgulik » Wed Oct 21, 2020 2:27 am

Huge: The big ones contain large sections with stuff like this.
Code: Select all
---------------  P R O C E S S  ---------------
...
Dynamic libraries:
...
7f8f83f90000-7f8f84000000 rw-s 00000000 00:1b 640                        /i915 (deleted)
...
7f7a8b800000-7f7a8c000000 rw-p 00000000 00:00 0
...
7f7ad749f000-7f7ad74a5000 r--p 00000000 08:11 2495755                    /lib/x86_64-linux-gnu/libselinux.so.1
7f7ad74a5000-7f7ad74be000 r-xp 00006000 08:11 2495755                    /lib/x86_64-linux-gnu/libselinux.so.1
7f7ad74be000-7f7ad74c5000 r--p 0001f000 08:11 2495755                    /lib/x86_64-linux-gnu/libselinux.so.1
...


loftar wrote:most interesting part is the first part up until and including the (native) stackframe of the crashing thread.

Would that be the
Code: Select all
---------------  P R O C E S S  ---------------
Java Threads: ( => current thread )
part ? (ie: clipping "Other Threads:" section and below ?)
mvgulik
 
Posts: 3742
Joined: Fri May 21, 2010 2:29 am

Re: Information about JVM crashes

Postby loftar » Wed Oct 21, 2020 4:21 pm

mvgulik wrote:Would that be the
Code: Select all
---------------  P R O C E S S  ---------------
Java Threads: ( => current thread )
part ? (ie: clipping "Other Threads:" section and below ?)

To cite the report above, it would be this part:
Code: Select all
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x5b601367, pid=3156, tid=0x00002b68
#
# JRE version: Java(TM) SE Runtime Environment (8.0_251-b08) (build 1.8.0_251-b08)
# Java VM: Java HotSpot(TM) Client VM (25.251-b08 mixed mode windows-x86 )
# Problematic frame:
# C [ig7icd32.dll+0x3f1367]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

--------------- T H R E A D ---------------

Current thread (0x45bcc000): JavaThread "AWT-EventQueue-0" [_thread_in_native, id=11112, stack(0x46a00000,0x46a50000)]

siginfo: ExceptionCode=0xc00000fd, ExceptionInformation=0x00000000 0x46a00000

Registers:
EAX=0x46a00000, EBX=0x46a4e5a0, ECX=0x469f27cc, EDX=0x00be0000
ESP=0x46a10ea8, EBP=0x46a10ebc, ESI=0x46a49bf8, EDI=0x4994a288
EIP=0x5b601367, EFLAGS=0x00010206

Top of Stack: (sp=0x46a10ea8)
0x46a10ea8: 4994a288 5b4b2642 46a2f5b8 5b65e63e
0x46a10eb8: ffffffff 46a2f5c4 5b4b2c97 00000077
0x46a10ec8: 46a2c378 46a2f564 4994a288 499a0ae8
0x46a10ed8: 00000000 00000000 00000000 00000000
0x46a10ee8: 00000000 00000000 00000000 00000000
0x46a10ef8: 00000000 00000000 00000000 00000000
0x46a10f08: 00000000 00000000 00000000 00000000
0x46a10f18: 00000000 00000000 00000000 00000000

Instructions: (pc=0x5b601367)
0x5b601347: 1b c0 f7 d0 23 c8 8b c4 25 00 f0 ff ff 3b c8 72
0x5b601357: 0a 8b c1 59 94 8b 00 89 04 24 c3 2d 00 10 00 00
0x5b601367: 85 00 eb e9 cc cc cc cc cc 55 8b ec 56 33 c0 50
0x5b601377: 50 50 50 50 50 50 50 8b 55 0c 8d 49 00 8a 02 0a


Register to memory mapping:

EAX=0x46a00000 is an unknown value
EBX=0x46a4e5a0 is pointing into the stack for thread: 0x45bcc000
ECX=0x469f27cc is an unknown value
EDX=0x00be0000 is an unknown value
ESP=0x46a10ea8 is pointing into the stack for thread: 0x45bcc000
EBP=0x46a10ebc is pointing into the stack for thread: 0x45bcc000
ESI=0x46a49bf8 is pointing into the stack for thread: 0x45bcc000
EDI=0x4994a288 is an unknown value


Stack: [0x46a00000,0x46a50000], sp=0x46a10ea8, free space=67k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [ig7icd32.dll+0x3f1367]
C [ig7icd32.dll+0x2a2c97]
C [ig7icd32.dll+0x2a5358]
C [ig7icd32.dll+0x38e6ac]
C [ig7icd32.dll+0x38ed2a]
C [ig7icd32.dll+0x120697]
C [ig7icd32.dll+0x38f76a]
C [ig7icd32.dll+0x120686]
C [ig7icd32.dll+0x38ea8f]
C [ig7icd32.dll+0x120697]
C [ig7icd32.dll+0x38c967]
C [ig7icd32.dll+0x38ec36]
C [ig7icd32.dll+0x120697]
C [ig7icd32.dll+0x38ed06]
C [ig7icd32.dll+0x120697]
C [ig7icd32.dll+0x38f3ec]
C [ig7icd32.dll+0x120697]
C [ig7icd32.dll+0x38f738]
C [ig7icd32.dll+0x120686]
C [ig7icd32.dll+0x38ea8f]
C [ig7icd32.dll+0x1207c5]
C [ig7icd32.dll+0x38f14d]
C [ig7icd32.dll+0x120697]
C [ig7icd32.dll+0x38ea8f]
C [ig7icd32.dll+0x120697]
C [ig7icd32.dll+0x34d805]
C [ig7icd32.dll+0x34d72a]
C [ig7icd32.dll+0x1a9cc7]
C [ig7icd32.dll+0x11daaf]
C [ig7icd32.dll+0x11ea2a]
C [ig7icd32.dll+0x11ebd2]
C [ig7icd32.dll+0x238592]
C [jogl_desktop.dll+0x2883f]
j jogamp.opengl.gl4.GL4bcImpl.dispatch_glLinkProgram1(IJ)V+0
j jogamp.opengl.gl4.GL4bcImpl.glLinkProgram(I)V+34
j haven.render.gl.GLProgram$ProgOb.create(Ljavax/media/opengl/GL3;)V+99
j haven.render.gl.BGL$2.run(Ljavax/media/opengl/GL3;)V+5
J 744 C1 haven.render.gl.BufferBGL.run(Ljavax/media/opengl/GL3;)V (47 bytes) @ 0x02c90a04 [0x02c909b0+0x54]
j haven.render.gl.GLEnvironment.process(Ljavax/media/opengl/GL3;)V+134
j haven.JOGLPanel.redraw(Ljavax/media/opengl/GL3;)V+95
j haven.JOGLPanel.access$000(Lhaven/JOGLPanel;Ljavax/media/opengl/GL3;)V+2
j haven.JOGLPanel$1.display(Ljavax/media/opengl/GLAutoDrawable;)V+15
j jogamp.opengl.GLDrawableHelper.displayImpl(Ljavax/media/opengl/GLAutoDrawable;)V+81
j jogamp.opengl.GLDrawableHelper.display(Ljavax/media/opengl/GLAutoDrawable;)V+2
j javax.media.opengl.awt.GLCanvas$9.run()V+118
j jogamp.opengl.GLDrawableHelper.invokeGLImpl(Ljavax/media/opengl/GLDrawable;Ljavax/media/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V+206
j jogamp.opengl.GLDrawableHelper.invokeGL(Ljavax/media/opengl/GLDrawable;Ljavax/media/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V+80
j javax.media.opengl.awt.GLCanvas$10.run()V+73
j java.awt.event.InvocationEvent.dispatch()V+11
j java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V+21
j java.awt.EventQueue.access$500(Ljava/awt/EventQueue;Ljava/awt/AWTEvent;Ljava/lang/Object;)V+3
j java.awt.EventQueue$3.run()Ljava/lang/Void;+32
j java.awt.EventQueue$3.run()Ljava/lang/Object;+1
v ~StubRoutines::call_stub
V [jvm.dll+0x15c725]
V [jvm.dll+0x228b6e]
V [jvm.dll+0x15c7be]
V [jvm.dll+0x10c45f]
C [java.dll+0x102f]
j java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/security/AccessControlContext;)Ljava/lang/Object;+18
j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+46
j java.awt.EventDispatchThread.pumpOneEventForFilters(I)V+140
j java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35
j java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j java.awt.EventDispatchThread.run()V+9
v ~StubRoutines::call_stub
V [jvm.dll+0x15c725]
V [jvm.dll+0x228b6e]
V [jvm.dll+0x15c7be]
V [jvm.dll+0x15c946]
V [jvm.dll+0x15c9b7]
V [jvm.dll+0x1003df]
V [jvm.dll+0x17f940]
V [jvm.dll+0x1801ba]
V [jvm.dll+0x1c6ea6]
C [msvcr100.dll+0x5c556]
C [msvcr100.dll+0x5c600]
C [KERNEL32.DLL+0x20419]
C [ntdll.dll+0x666dd]
C [ntdll.dll+0x666ad]
C 0x00000000

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j jogamp.opengl.gl4.GL4bcImpl.dispatch_glLinkProgram1(IJ)V+0
j jogamp.opengl.gl4.GL4bcImpl.glLinkProgram(I)V+34
j haven.render.gl.GLProgram$ProgOb.create(Ljavax/media/opengl/GL3;)V+99
j haven.render.gl.BGL$2.run(Ljavax/media/opengl/GL3;)V+5
J 744 C1 haven.render.gl.BufferBGL.run(Ljavax/media/opengl/GL3;)V (47 bytes) @ 0x02c90a04 [0x02c909b0+0x54]
j haven.render.gl.GLEnvironment.process(Ljavax/media/opengl/GL3;)V+134
j haven.JOGLPanel.redraw(Ljavax/media/opengl/GL3;)V+95
j haven.JOGLPanel.access$000(Lhaven/JOGLPanel;Ljavax/media/opengl/GL3;)V+2
j haven.JOGLPanel$1.display(Ljavax/media/opengl/GLAutoDrawable;)V+15
j jogamp.opengl.GLDrawableHelper.displayImpl(Ljavax/media/opengl/GLAutoDrawable;)V+81
j jogamp.opengl.GLDrawableHelper.display(Ljavax/media/opengl/GLAutoDrawable;)V+2
j javax.media.opengl.awt.GLCanvas$9.run()V+118
j jogamp.opengl.GLDrawableHelper.invokeGLImpl(Ljavax/media/opengl/GLDrawable;Ljavax/media/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V+206
j jogamp.opengl.GLDrawableHelper.invokeGL(Ljavax/media/opengl/GLDrawable;Ljavax/media/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V+80
j javax.media.opengl.awt.GLCanvas$10.run()V+73
j java.awt.event.InvocationEvent.dispatch()V+11
j java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V+21
j java.awt.EventQueue.access$500(Ljava/awt/EventQueue;Ljava/awt/AWTEvent;Ljava/lang/Object;)V+3
j java.awt.EventQueue$3.run()Ljava/lang/Void;+32
j java.awt.EventQueue$3.run()Ljava/lang/Object;+1
v ~StubRoutines::call_stub
j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0
j java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/security/AccessControlContext;)Ljava/lang/Object;+18
j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+46
j java.awt.EventDispatchThread.pumpOneEventForFilters(I)V+140
j java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35
j java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j java.awt.EventDispatchThread.run()V+9
v ~StubRoutines::call_stub
"Object-oriented design is the roman numerals of computing." -- Rob Pike
User avatar
loftar
 
Posts: 8926
Joined: Fri Apr 03, 2009 7:05 am

Re: Information about JVM crashes

Postby mvgulik » Wed Oct 21, 2020 5:38 pm

hs_err_pid179439.log (most recent log)
Code: Select all
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f90a56596c3, pid=179439, tid=0x00007f9078f31700
#
# JRE version: OpenJDK Runtime Environment (8.0_265-b01) (build 1.8.0_265-8u265-b01-0ubuntu2~20.04-b01)
# Java VM: OpenJDK 64-Bit Server VM (25.265-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libc.so.6+0x18e6c3]
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x00007f90a0bcf800):  JavaThread "AWT-EventQueue-1" [_thread_in_native, id=179473, stack(0x00007f9078e31000,0x00007f9078f32000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x00007f8fc0481000

Registers:
RAX=0x00007f8f6d869000, RBX=0x0000000000016443, RCX=0x000000000003b450, RDX=0x000000000010b330
RSP=0x00007f9078f2f438, RBP=0x00007f8fc03b1120, RSI=0x00007f8fc0481000, RDI=0x00007f8f6d938ee0
R8 =0x0000000000000000, R9 =0x0000000000000000, R10=0x00007f9078f2f3f0, R11=0x0000000000000246
R12=0x00007f900403a248, R13=0x000000000000000c, R14=0x0000000000000001, R15=0x000000000010b330
RIP=0x00007f90a56596c3, EFLAGS=0x0000000000010283, CSGSFS=0x002b000000000033, ERR=0x0000000000000004
  TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007f9078f2f438)
0x00007f9078f2f438:   00007f90727e547b 0000000000000000
0x00007f9078f2f448:   0001644472d59e6d 0000000000000000
0x00007f9078f2f458:   00007f9004039e48 00007f9078f2f830
0x00007f9078f2f468:   00007f9004027880 00007f900403a248
0x00007f9078f2f478:   0000000000000001 00007f9004047a48
0x00007f9078f2f488:   00007f90727e5d98 000000000000000c
0x00007f9078f2f498:   00007f90727e5951 0000132c0000132c
0x00007f9078f2f4a8:   0001644300000cc8 0000000000000000
0x00007f9078f2f4b8:   0000000000000000 0000000200000000
0x00007f9078f2f4c8:   0000000000016443 0000000000000000
0x00007f9078f2f4d8:   00007f9078f2f5f0 0101000100000000
0x00007f9078f2f4e8:   0000000000000002 00007f9078f2f6a0
0x00007f9078f2f4f8:   00007f900403d094 00007f8f6eb98ae0
0x00007f9078f2f508:   0000000000000000 00007f9004039b80
0x00007f9078f2f518:   00007f90727f9d45 00000000000000c7
0x00007f9078f2f528:   0000000000000000 0000000000000ad8
0x00007f9078f2f538:   00007f9000000000 0000002000000000
0x00007f9078f2f548:   0000000000000000 0000000000000000
0x00007f9078f2f558:   0000000000000000 00007f90084b3090
0x00007f9078f2f568:   0000000000000000 00007f9078f2f740
0x00007f9078f2f578:   0000000000000003 00007f8f6eb98c40
0x00007f9078f2f588:   00007f9072d5a0b5 0000000000000001
0x00007f9078f2f598:   00000000000018ff 00000000000000c7
0x00007f9078f2f5a8:   000000c700000000 0101000100000000
0x00007f9078f2f5b8:   0000000000000000 0706050100000004
0x00007f9078f2f5c8:   0000000000000001 0000000000000000
0x00007f9078f2f5d8:   0000046f00000000 200000000000063f
0x00007f9078f2f5e8:   0000000000000000 00007f9004039e48
0x00007f9078f2f5f8:   00007f9004039e68 0000000000000c58
0x00007f9078f2f608:   00007f9072801276 0000002000000080
0x00007f9078f2f618:   e74c89b000000009 00007f9005f44fb0
0x00007f9078f2f628:   00007f9004027880 00007f9078f2f7e0

Instructions: (pc=0x00007f90a56596c3)
0x00007f90a56596a3:   2a 06 00 0f 83 25 01 00 00 48 39 f7 72 0f 74 12
0x00007f90a56596b3:   4c 8d 0c 16 4c 39 cf 0f 82 c5 01 00 00 48 89 d1
0x00007f90a56596c3:   f3 a4 c3 80 fa 10 73 17 80 fa 08 73 27 80 fa 04
0x00007f90a56596d3:   73 33 80 fa 01 77 3b 72 05 0f b6 0e 88 0f c3 c5

Register to memory mapping:

RAX=0x00007f8f6d869000 is an unknown value
RBX=0x0000000000016443 is an unknown value
RCX=0x000000000003b450 is an unknown value
RDX=0x000000000010b330 is an unknown value
RSP=0x00007f9078f2f438 is pointing into the stack for thread: 0x00007f90a0bcf800
RBP=0x00007f8fc03b1120 is an unknown value
RSI=0x00007f8fc0481000 is an unknown value
RDI=0x00007f8f6d938ee0 is an unknown value
R8 =0x0000000000000000 is an unknown value
R9 =0x0000000000000000 is an unknown value
R10=0x00007f9078f2f3f0 is pointing into the stack for thread: 0x00007f90a0bcf800
R11=0x0000000000000246 is an unknown value
R12=0x00007f900403a248 is an unknown value
R13=0x000000000000000c is an unknown value
R14=0x0000000000000001 is an unknown value
R15=0x000000000010b330 is an unknown value


Stack: [0x00007f9078e31000,0x00007f9078f32000],  sp=0x00007f9078f2f438,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x18e6c3]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 6290  jogamp.opengl.gl4.GL4bcImpl.dispatch_glDrawArrays1(IIIJ)V (0 bytes) @ 0x00007f909169d038 [0x00007f909169d000+0x38]
J 6990 C2 haven.BGL$46.run(Ljavax/media/opengl/GL2;)V (19 bytes) @ 0x00007f9091e7d93c [0x00007f9091e7d8c0+0x7c]
J 9000 C2 javax.media.opengl.awt.GLCanvas$9.run()V (122 bytes) @ 0x00007f9091f59b78 [0x00007f9091f595e0+0x598]
J 9366 C2 jogamp.opengl.GLDrawableHelper.invokeGLImpl(Ljavax/media/opengl/GLDrawable;Ljavax/media/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V (481 bytes) @ 0x00007f90927143dc [0x00007f9092714140+0x29c]
J 12649 C2 java.awt.EventQueue$3.run()Ljava/lang/Object; (5 bytes) @ 0x00007f9092e9eca8 [0x00007f9092e9ea80+0x228]
v  ~StubRoutines::call_stub
J 1605  java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object; (0 bytes) @ 0x00007f90914f24a3 [0x00007f90914f2440+0x63]
J 8746 C2 org.GNOME.Accessibility.AtkWrapper$6.dispatchEvent(Ljava/awt/AWTEvent;)V (104 bytes) @ 0x00007f9092532c6c [0x00007f90925328a0+0x3cc]
J 8749 C2 java.awt.EventDispatchThread.pumpOneEventForFilters(I)V (190 bytes) @ 0x00007f90920ef880 [0x00007f90920ef320+0x560]
J 11388% C2 java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V (47 bytes) @ 0x00007f909152fabc [0x00007f909152f9c0+0xfc]
j  java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j  java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j  java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j  java.awt.EventDispatchThread.run()V+9
v  ~StubRoutines::call_stub


Other log's also start with "jogamp.opengl.gl4.GL4bcImpl.dispatch_glDrawArrays1" in the Java frames section.
(some have a virtual identical Java frames section, others have some other/extra lines in there)
mvgulik
 
Posts: 3742
Joined: Fri May 21, 2010 2:29 am

Re: JVM crash in libc.so

Postby loftar » Wed Oct 21, 2020 6:04 pm

That looks an awful lot like an OpenGL driver bug, seeing how it crashes in libc via a call to the OpenGL driver, in a call that shouldn't even be able to touch any potentially invalid memory.

What hardware and drivers are you using?
"Object-oriented design is the roman numerals of computing." -- Rob Pike
User avatar
loftar
 
Posts: 8926
Joined: Fri Apr 03, 2009 7:05 am

Re: JVM crash in libc.so

Postby mvgulik » Wed Oct 21, 2020 6:48 pm

OS: Linux Mint 20 Cinnamon (v4.6.7)
- Kernel: 5.4.0-48-generic
CPU: Intel© Core(TM) i7-4790 CPU @ 3.60GHz × 4
Video:
- Onboard: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
- Plugin: Advanced Micro Devices, Inc. [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] (prog-if 00 [VGA controller])
-- At this moment I'm not sure which is the active video. I think its the Radeon.

Drivers: Not sure how to pull explicit data on that.
For the video is seems to use the default drivers that come with the OS. (ie: no proprietary drivers are in use)
mvgulik
 
Posts: 3742
Joined: Fri May 21, 2010 2:29 am

Re: JVM crash in libc.so

Postby MagicManICT » Wed Oct 21, 2020 11:34 pm

mvgulik wrote:For the video is seems to use the default drivers that come with the OS. (ie: no proprietary drivers are in use)

Seems like that could be a problem itself. Generic driver is trying to access memory the graphics device memory controller isn't allowing or something along that as a possible issue. I'm not even close to a Linux geek (not even much of a Windows one anymore). (Additional thoughts--it is a bit of a universal problem no matter the OS as different hardware manufacturers, even between model numbers, let alone generations, can change the needs for memory allocation and patterning.)
Opinions expressed in this statement are the authors alone and in no way reflect on the game development values of the actual developers.
User avatar
MagicManICT
 
Posts: 18437
Joined: Tue Aug 17, 2010 1:47 am

Re: JVM crash in libc.so

Postby loftar » Wed Oct 21, 2020 11:45 pm

mvgulik wrote:For the video is seems to use the default drivers that come with the OS. (ie: no proprietary drivers are in use)

If I were you, I'd make sure to install the debug symbols for libc and see if that expands the stack trace down into the driver. Since you are using the open source drivers, you should be able to install the debug symbols for those as well when you see from the expanded stack trace what file they come from. One of the problems with the log-file right now is that it stops directly at the first frame, in libc, which is, in all likelihood, due to a lack of debug symbols.

Also, I know next to nothing about Mint, but the drivers likely come from the Mesa package (which is commonly split up among several distro packages by the distro maintainers), so I'd check to see if they're using the latest version. Or contrariwise, perhaps, if they're using a too new, experimental version.

MagicManICT wrote:Seems like that could be a problem itself. Generic driver is trying to access memory the graphics device memory controller isn't allowing or something along that as a possible issue. I'm not even close to a Linux geek (not even much of a Windows one anymore).

From my (admittedly somewhat limited) knowledge of the Linux GPU driver stack, there shouldn't be any room for any such issue.
"Object-oriented design is the roman numerals of computing." -- Rob Pike
User avatar
loftar
 
Posts: 8926
Joined: Fri Apr 03, 2009 7:05 am

Re: JVM crash in libc.so

Postby mvgulik » Thu Oct 22, 2020 7:39 am

Roger. I'll see what I can do.
Might just switch that Radeon for a other/faster video card I have, which I was putting off.
(suspect there is a potentially chance it might be related to how the shared intel-video memory is handles on this Dell computer. well see)
mvgulik
 
Posts: 3742
Joined: Fri May 21, 2010 2:29 am

Next

Return to Bugs

Who is online

Users browsing this forum: No registered users and 10 guests