Archived

This topic is now archived and is closed to further replies.

  • 0

Damn you Linux/Java :(

Question

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 :P)

 

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!

Share this post


Link to post
Share on other sites

25 answers to this question

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. 

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. :(

Share this post


Link to post
Share on other sites

 

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())?

Share this post


Link to post
Share on other sites

 

 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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? :D

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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)
 

Share this post


Link to post
Share on other sites

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 :) 

Share this post


Link to post
Share on other sites

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 likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 ?  :???:

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites