Damn you Linux/Java :(

lemmy101 · August 23, 2013

Can people who are having issues running the latest version please post your OS specs here? I think this is a long standing bug with the JVM on some Linux machines requiring a call to XInitThreads in the XWindowing system that's not getting called. It is COMPLETELY out of my power to call this, as it needs to be called effectively before the first line of 'main' in the PZ program, aka before the actual java code ever starts, so it's up to the JVM to do this not I.

You could try installing latest graphic drivers / version of java, if you've not already, perhaps the problem I read so many places was later solved in a JVM update? but sadly there's likely nothing I can do but remove the significant performance boosting render system that was added to 16 (which after months of moaning about FPS, not one person has mentioned btw )

Question is whether I need to remove it across entire Linux or if it needs to be a menu option. i.e. are there Linux people who don't get this error?

If I can figure out exactly what versions its affecting maybe I can better check for it?

Thanks!

Eggplanticus · August 23, 2013

I don't think it's an Ubuntu thing. Also, what makes you think it's a Java problem?

I run on gentoo, Oracle JDK 1.7.0.25. AMD64

I also tried IcedTea JDK 6.1.12.6 and I got the same crash.

Also, the bug is triggered by moving the mouse or pressing a key. If you keep the mouse still, everything runs.

CareBearCorpse · August 23, 2013

Linux i386 - Kubuntu 12.04

java version "1.7.0_25"

OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.12.04.2)

OpenJDK Server VM (build 23.7-b01, mixed mode

(in the process of upgrading the whole system, which seems to be required to be able to install latest linux Intel drivers)

I don't think it's an Ubuntu thing. Also, what makes you think it's a Java problem?

It doesn't seem to be a Java problem per se, but as Lemmy said above a failure from the JVM linux (not only Ubuntu it seems) implementation to call a Linux low level rendering function. (see http://forums.wxwidgets.org/viewtopic.php?f=23&t=32346).

Now i'm naively wondering, since the game crashes on main screen (for me at least), is it already too late to call this function in the main; or is it just not possible to call it at all ?

Eggplanticus · August 23, 2013

Maybe it has to do with XInitThreads()? It has to be called (and complete) before any other xlib functions are called.

Is this because of java / awt not calling XinitThreads() ? This appears to be a common complaint... if that's the case then it's a pretty bad bug.

Edited August 23, 2013 by Eggplanticus

harakka · August 23, 2013

Is this an issue with both OpenJDK and Oracle JVMs?

lemmy101 · August 23, 2013

Maybe it has to do with XInitThreads()? It has to be called (and complete) before any other xlib functions are called.

Is this because of java / awt not calling XinitThreads() ? This appears to be a common complaint... if that's the case then it's a pretty bad bug.

yep this is it exactly. We changed the game rendering system to be multithreaded, which has resulted in a 20-30 FPS improvement for more or less everyone who had FPS issues. Obviously this was needed due to the FPS complaints lately

Obv I can go back to how it was for linux (tho a pain in the ass obv getting both systems running on a switch ) but those affected will just have to deal with that slower framerate, since there is literally nothing else I can do without a COMPLETE rewrite of the sprite engine (don't hold your breath), given the bottleneck is in vertex/index buffer mapping. That has to happen, and if it can't happen on another thread then it'll cost the FPS due to how much is drawn.

Eggplanticus · August 23, 2013

Maybe it has to do with XInitThreads()? It has to be called (and complete) before any other xlib functions are called.

Is this because of java / awt not calling XinitThreads() ? This appears to be a common complaint... if that's the case then it's a pretty bad bug.

yep this is it exactly. We changed the game rendering system to be multithreaded, which has resulted in a 20-30 FPS improvement for more or less everyone who had FPS issues. Obviously this was needed due to the FPS complaints lately

Obv I can go back to how it was for linux (tho a pain in the ass obv getting both systems running on a switch ) but those affected will just have to deal with that slower framerate, since there is literally nothing else I can do without a COMPLETE rewrite of the sprite engine (don't hold your breath), given the bottleneck is in vertex/index buffer mapping. That has to happen, and if it can't happen on another thread then it'll cost the FPS due to how much is drawn.

Would putting an xinitthreads() call in the very first line of the launchdialog constructor fix it (before the call to super())?

Eggplanticus · August 23, 2013

Or, better, in the first line of main?

harakka · August 23, 2013

Maybe it has to do with XInitThreads()? It has to be called (and complete) before any other xlib functions are called.

Is this because of java / awt not calling XinitThreads() ? This appears to be a common complaint... if that's the case then it's a pretty bad bug.

yep this is it exactly. We changed the game rendering system to be multithreaded, which has resulted in a 20-30 FPS improvement for more or less everyone who had FPS issues. Obviously this was needed due to the FPS complaints lately

Obv I can go back to how it was for linux (tho a pain in the ass obv getting both systems running on a switch ) but those affected will just have to deal with that slower framerate, since there is literally nothing else I can do without a COMPLETE rewrite of the sprite engine (don't hold your breath), given the bottleneck is in vertex/index buffer mapping. That has to happen, and if it can't happen on another thread then it'll cost the FPS due to how much is drawn.

Would putting an xinitthreads() call in the very first line of the launchdialog constructor fix it (before the call to super())?

super() always has to be called first, either implicitly or explicitly, so that isn't an option.

lemmy101 · August 23, 2013

Or, better, in the first line of main?

no, it needs to be created before the java main thread is created. AKA before main() which is the earliest possible time you could call it. Much better programmers than I with a ton more linux experience than I have said this is not fixable, the makers of lwjgl expressed their frustration and lack of power to do anything, so am inclined to believe that.

Eggplanticus · August 23, 2013

I managed to get 2.9.9.16 to run by calling XInitThreads() on the first line of main.

I'm not saying that this is necessarily a good or reliable way to do things, since, as you said, others before us have tried and failed, but in my case it works.

Edited August 23, 2013 by Eggplanticus

lemmy101 · August 23, 2013

Really? well I take that back then and wonder why in hell everyone's so pissed off about it in the OGL / LWJGL communities.

OK so question 2) How in fuck do I call XInitThreads?

lemmy101 · August 23, 2013

I mean, it's a native function, C right? how did you call it?

Eggplanticus · August 23, 2013

OK, saying this is a hack is an understatement, but I did the following:

1) I made a small library in C whose sole purpose is to call XInitThreads

//--------------------------------------------------------------------------------------------------//xdll.cpp//--------------------------------------------------------------------------------------------------// compile with g++ -o libxx.so -shared -fPIC -Wl,-soname,libxx.so -L/usr/lib/X11 -I/usr/include/X11 xdll.cpp -lX11#include <Xlib.h>#include <stdio.h>class a{public:  a() { XInitThreads(); }};a X;

2) I compiled it and copied it to my projectzomboid directory (libxx.so).

3) Then I put a breakpoint in the first line of main of my decompiled pz source.

When the breakpoint triggered I evaluated the expression System.loadLibrary("xx");

This loaded the library and caused XInitThreads() to get called.

Then I continued the program, and to my suprise, it didn't crash and I created a new world and ran around for a bit.

lemmy101 · August 23, 2013

any chance I can get a copy of that so I'm not in a position to build one myself. We will give you a lovely contributor credit if it works for everyone (also it seems perfectly reasonable thing to do imo, not really a hack at all)

Eggplanticus · August 23, 2013

No problem - I built it for AMD64. I'm not totally sure how to cross-compile it at the moment, but I can look into it.

libxx64.zip

WonkyLegs · August 23, 2013

The game runs on my system:

Kernel: Linux desktop 3.10.6-2-ARCH #1 SMP PREEMPT Tue Aug 13 10:20:52 CEST 2013 i686 GNU/Linux

Graphics Driver: Nvidia 325.15

OpenJDK Runtime Environment (IcedTea 2.4.1) (ArchLinux build 7.u40_2.4.1-2-i686)

I'm still unable to walk through crafted doors in this version (on a version 15 save game). Is this bug supposed to be already fixed in version 16?

snipertyler · August 23, 2013

I got the common Main exception error and doing this got me to here

Also, the bug is triggered by moving the mouse or pressing a key. If you keep the mouse still, everything runs.

which output this when I moved the mouse over the screen: AL lib: ReleaseALC: 1 device not closed

Doing it again got me this:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
java: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted

and a different message the next time..

[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
java: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
Aborted

The bolded part sounds like the posts above ^^

Edit: This isn't important, and I don't know if anyone has noticed this, but in the projectzomboid.sh file, the line containing:

INSTDIR="`dirname $0`" ; cd "${INSTDIR}" ; INSTDIR="`pwd`"

looks like a long way of just doing this:

INSTDIR=$(pwd)

I run the Amd64 version

Kernel: 3.8.0-19-generic x86_64 (64 bit, gcc: 4.7.3) ; Linux Mint 15 Olivia (derived from Ubuntu)
Graphics: Card: Intel 3rd Gen Core processor Graphics Controller

Java version "1.7.0_25"

OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.13.04.2)

lemmy101 · August 24, 2013

No problem - I built it for AMD64. I'm not totally sure how to cross-compile it at the moment, but I can look into it.

thanks

CareBearCorpse · August 27, 2013

Here is the 32 bit version of Eggplanticus's library if it's any use to anyone :

EDIT : removed my build link for 32-bit, use Eggplanticus's instead

(damn add attachment button where have you gone ?)

And here is a link to Eggplanticus's real helpful thread about how to decompile/debug PZ with eclipse :

http://theindiestone.com/forums/index.php/topic/1156-pz-source-code-spelunking-debugging-and-decompiling/

Eggplanticus · August 28, 2013

Thank you CareBearCorpse for testing this out on your platform. Just for the sake of consistency (same tools, same versions of various libraries, etc) I am trying to cross-compile my own version of libxx for 32-bit. So far I have a working cross-compiler, but I am having problems cross-compiling libX11 which is a dependency of libxx. Hopefully I can get it built soon.

CareBearCorpse · August 28, 2013

Thank you CareBearCorpse for testing this out on your platform. Just for the sake of consistency (same tools, same versions of various libraries, etc) I am trying to cross-compile my own version of libxx for 32-bit. So far I have a working cross-compiler, but I am having problems cross-compiling libX11 which is a dependency of libxx. Hopefully I can get it built soon.

Shouldn't libX11 already be present on the user system ? :???:

Eggplanticus · August 28, 2013

Yes it should. I also need my own 32-bit version so that I can compile libxx and link against libX11, and making my own version is the problem.

Eggplanticus · September 2, 2013

Thank you CareBearCorpse for testing this out on your platform. Just for the sake of consistency (same tools, same versions of various libraries, etc) I am trying to cross-compile my own version of libxx for 32-bit. So far I have a working cross-compiler, but I am having problems cross-compiling libX11 which is a dependency of libxx. Hopefully I can get it built soon.
Shouldn't libX11 already be present on the user system ?

Hey CareBearCorpse! Could you test the 32-bit libxx.so file I have compiled?

Thank you in advance for your help.

Oops, wrong file! Try again.

libxx.zip

CareBearCorpse · September 2, 2013

Working ! Good job.

Removed my build link.

Eggplanticus · September 2, 2013

Thank you ever so much!

Sign In

Damn you Linux/Java :(

Question

lemmy101

25 answers to this question

Recommended Posts

Eggplanticus

CareBearCorpse

Eggplanticus

harakka

lemmy101

Eggplanticus

Eggplanticus

harakka

lemmy101

Eggplanticus

lemmy101

lemmy101

Eggplanticus

lemmy101

Eggplanticus

WonkyLegs

snipertyler

lemmy101

CareBearCorpse

Eggplanticus

CareBearCorpse

Eggplanticus

Eggplanticus

CareBearCorpse

Eggplanticus

Create an account or sign in to comment

Create an account

Sign in

Browse

Activity