Initialising LibX causes a fatal JVM crash when using the JVM splash-screen switch #353
Comments
|
Don't use a pre-release version of VLC. Your log has this: vlc: 2.2.0-rc2 Weatherwax, changeset 2.2.0-rc1-118-g22fda39 Use the final release version of VLC, not this release candidate. vlcj has conditional code depending on the version of VLC, but it can only identify 3.0.0, 2.2.0, 2.1.5, 2.1.0 and so on, it does not have conditional code depending on particular git revisions or pre-releases. vlcj supports bleeding edge versions of VLC, that's true, but it's either the latest git version, or an actual release version that's supported. vlcj does not support arbitrary pre-releases. |
|
You can try vlcj 3.5.0 too as one bug was fixed in relation to the unknown event errors in your log. |
|
You also might have another problem as your _io_file_underflow error implicates #62 for which there is only a sub-optimal solution. |
|
i removed the pre-release (installed from repo rpmfusion-free-release-rawhide) and installed the stable release but it seems the same release is installed from rpmfusion-free-release-stable i believe there is some issue in the OS now so i will reinstall fresh OS and comeback. |
|
Please refer to #62, as I think this will impact you. |
|
thanks, it was really about Lua. it is working now after I rename the folder in fedora 21:
but this is somehow not practical. if you are distributing your application, you need to ask the user to do this as a prerequisite assuming your application does not need root access as in my case. also this might disable few features in the VLC itself as you have highlighted it in the other thread. |
|
Well, yes, it's not a great solution. It means things like YouTube won't work. I did a lot of investigation on this as is evidenced by #62. My own suspicion is it's a problem with the build of the 32-bit JVM being linked against a wrong libc, or at least a mismatched libc, but this is not something that can be fixed in this project. It affects both the Oracle 32-bit JVM and the OpenJDK one. |
|
now the same thing is happening again after updating fedora (even with removing lua). i tried to replace the jna/jna-platform to the latest 4.1.0 and the same (even removing lua folder from 64bit): |
|
Your most recent log shows vlc: 2.2.0-rc2 Weatherwax. vlcj supports final release versions, not release candidates. |
|
In any case, this is not the same error (this is not related to LUA). |
|
it is rc version of VLC but i just took the standard one from software center. i believe it will start at least without supporting new features. is it correct ? |
|
In a comment above, I said:
What happened was between VLC 2.2.0 rc2 and VLC 2.2.0 final, amongst other things new meta data fields were added. So this conditional code is not fine-grained enough to work out the difference between 2.2.0 rc2 and 2.2.0 and it can break. I am not adding code to vlcj to conditionally check for specific git revisions to enable/disable features. The only thing I can reasonably do is support final release versions. Now, it might be the case that this issue you've just reported is not due to using the release candidate of VLC, but it might be, and until it's proven that it's not I don't see any reason to change anything in vlcj. |
|
All I can add is I run Kubuntu 14.10 (15.04 is still not released by the way), 64-bit, Java8, VLC 2.2.0 final, and I don't see crashes. |
|
i have tried it with sample code as in the tutorial page and it works fine. on the other hand my code crashes every time. tracing the problem, the crash is happening exactly when calling the main JFrame setVisible(true). is there anything that can affect L&F. i tried to increase the heap size but no luck. any hints on this case is appreciated. is there anything common between the LaF and vlcj e.g. related to Mixing Heavyweight and Lightweight. any option that we can try to tune in this area. |
|
Is that a different problem or is the same as this one? Please don't mix up another problem in the same issue report. Anyway... Do you now use the final release version of VLC? You've basically confirmed yourself that the problem is in your own code. The only thing I can suggest is to check what your code does differently to the vlcj examples, which all work... I will be amazed if the LaF is a problem. I will be amazed if the problem relates to mixing heavyweight and lightweight components. |
|
it is the same case. I'm using 3.6.0 in all cases, thanks for your support. i need to check my code line by line. |
|
Or you can post a minimal test case that fails and I'll have a look at it. It's just too much like guesswork at the moment. |
|
I can reproduce the problem now with any code. it is with splashscreen ! the following sample will crash with me: command line should have splash screen: On: i have installed many libraries so i do not know if it has any effect. please try to include the splash on any of your code. |
|
You should not call |
|
Also, your |
|
this is not the problem here, you can ignore the playmedia and the reference, it will still crash. change it to this and it will still crash: the problem is with splash screen and when the frame.setVisible is called, the splash screen should disappear but it crashes at this stage. i do not know if it is something with JDK implementation or JNA or VLCJ. |
|
So now that we have eliminated the garden paths... This is the reason it breaks: The MediaPlayerFactory static initialise does this: For some reason, this is interfering with the splash-screen, like maybe LibX is already initialised if using a splash-screen. |
caprica
changed the title
|
That LibX call is needed with recent versions of VLC otherwise errors are dumped to the native log. So I can't remove the call. The only thing I can think of doing is adding a new system property to disable that call - by default it would be enabled. |
|
After further testing with latest VLC, it seems it may no longer be the case that an application running on Linux must invoke LibX11.initialise() - so it might now be OK to remove it from vlcj. I'm really not sure. |
|
Having the option to disable it will give us the flexibility to use it or not when needed; at least at this stage. |
|
Added VLCJ_INITX system property. When starting your JVM, use... ...to prevent the automatic invocation of LibX11.initialise(). |
Hi caprica,
Appreciate your support for the following crash, i have installed libX11-devel, vlc-devel, since it was complaining about them but still showing errors about libc.so.6.
To get the path I'm using the default NativeDiscovery().discover();
the terminal output is:
i have tried to avoid the previous mistakes as suggested in #334
The dump file:
The text was updated successfully, but these errors were encountered: