New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
An error when trying to open a video file on 32 bit Ubuntu #62
Comments
|
Forget about vlc 1.1.x and vlcj 1.1.x. You should always use the latest version. I see you say already that you tried that, so... Start your application with -Dvlcj.log=DEBUG and post the log file. I only develop vlcj on Linux (64bit Ubuntu 12.04), and I test both JDK 1.6 and 1.7 so I know for a fact it works properly if your environment is set up correctly. Maybe there's some problem with running vlc under VMWare. Does the vlc application itself play videos on your platform? |
|
Thanks for your fast support. This time, I used 32bit Ubuntu 12.04 installed separately from Windows not in VMWare, used vlc 2.0.2, and vlcj which I just cloned from this github. The independent vlc application itself plays video without any problem. Anyway, this is the result with the DEBUG option. |
|
Is it just one video file that fails? Does it fail with an audio only file? What do you mean "installed separately from Windows" - I thought your problem was on Ubuntu? Anyway, I noticed this: Instead of that JRE, I would suggest you install a JDK into e.g. ~/jdk1.7.0_15, and invoke your application explicitly using that version of the JDK, e,g, ~/jdk1.7.0_15/bin/java [whatever]. At least try it and see if that makes any difference. Also try JDK 1.6, just to narrow down the problem a bit. The segfault is in native code somewhere, specifically in libc. So the only other thing I can think of is that you use gdb to debug the JVM, catch the breakpoint and dump out a full thread-dump. I'm afraid I have nothing else to add, this works for me, and I've never had any other report of it failing for anyone else. |
|
So far, it hasn't failed with an audio only file. I wanted to say Ubuntu was installed independently, not in VMWare. I tried it with jdk1.7.0_05 with a new path(~/jdk.1.7.0_05) and an explicit invocation, but it failed with the same error. I used jdk1.6.0_33 and it worked!! I didn't change anything but just jdk as you suggested. I'm not a c programmer, so I don't think I could debug this big project. |
|
Hi, this is Lee again. I said that before to mean I have no idea how to dump out a full thread-dump. But I'm willing to find out a way if I really have to. Anyway, I have done a couple more of tests to narrow down and want your advice one more time. With Ubuntu 12.04 64 bit and JDK 1.7.0_05, it worked for me as well. As you mentioned, I used the latest versions of vlc and vlcj. It seems to me that it only crashes when JDK 1.7.0_05 is applied to Ubuntu 32 bit. I'm not trying to avoid your suggestion. I just want to know what I need to do to make vlcj work in 32 bit. Do you still think I need to debug JVM with gdb? |
|
Well, I dug out an old laptop and put 32-bit Xubuntu 12.04 on it. I get a segfault when i play a video. So, I can now reproduce your problem. Basically the libvlc_media_player_play call is ultimately triggering a segfault for some reason. |
|
I can also confirm on that platform that JDK 1.6.0_33 works, same as you. I could be somehow related to changes in the Java loader in JDK 1.7 as discussed here: http://www.capricasoftware.co.uk/wiki/index.php?title=Vlcj_Java7_On_Linux Unfortunately, the suggestions on that page don't help. |
|
I'm glad you confirmed my problem too. The suggestions didn't help me either. Actually I've decided to exclude 32 bit Ubuntu for now because I have other priorities. I hope this problem is solved soon. Thank you for taking your time. |
|
The problem seems quite fundamental. I can actually eliminate vlcj from this and just use the raw bindings to demonstrate this failure under 32bit Ubuntu: The above class is basically using NO vlcj framework classes - it simply uses the "raw" bindings in the LibVlc native interface. This class causes the same fatal crash when invoking play(). This class works on JDK 1.6.0. This class works on 64 bit Ubuntu. I suspect it will also work on the same platforms you tried, with the exception of 32 bit Ubuntu. So whatever this problem is, it is not caused by a higher level vlcj framework class, it is something fundamental going wrong on Java7 on a 32bit Linux platform. |
|
And here is a native thread dump when it crashes: |
|
Debugging native issues like this usually leads you up and down a few garden paths, however this time we're right on the money... The thing that stands out about this native thread dump for the failing thread is this: So my first inclination is to somehow disable LUA and see what happens. And indeed, if you move the vlc lua plugin out of the way, video playback works. The downside is you lose the lua support, which means things like YouTube won't work. So I guess there's some problem with vlc 2.0.x and the lua library on Java1.7 on 32-bit Ubuntu 12.04 (lua is version 5.04 on my Xubuntu installation). |
|
I also built vlc 2.0.x latest from git, and it still fails as described above on 32-bit Ubuntu. The only solution right now for (vlcj + Java7 + 32-bit Ubuntu) is to disable/remove lua from vlc. |
|
This also seems pertinent: So something is wrong with executing lua scripts generally, or this particular script is causing the problem. |
|
Is vlclua enabled/disabled globally or there is any way to disable it only for my vlcj application? |
|
As far as I know, vlc lua is enabled/disabled at the source code level. |
|
Further findings: If you remove /lib/vlc/lua/meta/reader/filename.luac then it will work. The 32-bit Linux I tested this on is an Ubuntu/Debian derivative with LUA 5.1. If you build and install LUA from the lua.org homepage, then this combination of java7+vlc+lua+Ubuntu32 will work. If you look at the source of the LUA package for the Linux distribution, you will see various patches that have been applied - something here is causing the failure. So something is wrong with the 32-but LUA distribution package on Ubuntu 32-bit, not LUA itself. |
|
I spent some more time looking at this, since Ubuntu-32bit is a popular enough platform, and was hoping that the 12.10 release of Ubuntu would fix it. I narrowed down the segfault a bit more by looking more inside the LUA code, specifically in the luaL_loadfile method inside the lauxlib.c source file: It actually fails on the FIRST getc() invocation inside the while loop... right after freopen is called a valid file handle (non-NULL) is returned, but the very first getc() invocation causes the IO_file_underflow segfault. So, the same problem exists on 32-bit Ubuntu 12.10 - something in the Ubuntu/Debian LUA patches triggers this crash. It still works just fine on Java6 on 32-bit Ubuntu, or on Java6 or Java7 on 64-bit Ubuntu, and it still works just fine with a standard LUA build rather than the Ubuntu/Debian patched LUA build. |
|
Created a minimal test case using the "raw" bindings. This is 100% reproducible when running on Java7 on 32-bit Ubuntu. But it works fine on Java6 on all platforms, and on Java7 on 64-bit Ubuntu. |
|
Made a custom build of the latest OpenJdk7 on 32bit Ubuntu 12.10, making sure "_IO_stdin_used" was declared and exported - same fatal JVM crash ensues. This flag was exported anyway as far I as can tell. |
|
So I am still investigating this from time to time... I created a simple test class that embeds LUA directly inside a Java application by using the C API: In theory, the luaL_loadfile call should trigger the same crash bug when run under Java7 on 32-bit Ubuntu. In actuality, it works just fine and does not trigger the crash bug. What does it mean, is it relevant? I don't know. The referenced "test.lua" is just a file in the current directory that does this: See comment below, you need to first compile test.lua with the "luac" compiler, then use that compiled version rather than the source version. |
|
If you compile the test.lua file and then try and execute that, the same crash bug IS indeed triggered. This basically rules out vlc/libvlc as part of the problem. |
|
I have the same problem. You said disabling lua fixes the problem, but stops things like youtube from working. I'm trying to use vlcj to receive an rtsp stream, will that also stop working if I remove lua? |
|
It depends. If your RTSP stream is simply a URL that you go to directly, it will still work. If it is in a playlist that needs to be parsed, or some web page that needs to be parsed to find the actual streaming URL, then of couse it won't work without LUA. I would basically recommend you use Java6 on 32-bit Ubuntu and then the problem goes away. |
|
I see, awesome, I'll try out Java6. Thanks caprica! Brilliant, that worked perfectly :) |
|
I think I've exhausted what I can do on this issue. If you want to see any action on it, perhaps vote on the Ubuntu bug I created in LaunchPad (see a few comments up). |
|
This has some background information that may or may not be relevant: http://debian.2.n7.nabble.com/Bug-634261-Debian-634261-Is-it-actually-a-n-RC-bug-td2832431.html |
|
This is still broken in Ubuntu 13.04 beta. |
|
The same problem I had on Russian Fedora Remix 18 LINUX 32-bit and jdk 1.7.0_09. Disabling LUA fixes the problem as caprica suggested. For my application purpose, I don't need the LUA. Also, it is good point to try JDK 1.6_33, as some people did, probably it will work. Anyway, Russian Fedora Remix 18 seems to have the same problem as Ubuntu does |
|
Interesting, thanks. I really don't know what to do about this. The latest comments on the Ubuntu LaunchPad bug report suggest that LUA is not the problem, rather it is some sort of shared library pre-load artefact. It could be that the JVM is at fault, but how to track it down and fix it I have no idea. |
|
rm /usr/lib/vlc/lua/ -r |
|
Yes, and that will work for most use cases just fine, but some potentially useful things are no longer available - like YouTube. Personally for my own projects I couldn't care less about playing YouTube videos, but some users need it. |
|
This also seems similar: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/810214 |
|
After more research I still don't see a way forward on this issue. If the _IO_STDIN_USED export is the right track, which can not be confirmed, then it implies something like a mismatch between versions of libc/glibc and/or libio somewhere. But diving deeper into this is way outside the scope of this project. |
Hello, my name is Lee, studying Computer Science in South Korea and trying to use vlcj project for some reason.
After conducting many tests and searching Google hours, I figured out this problem has never happened to others.
I need to run vlcj in both Windows and Ubuntu.
I have no problem running it in Windows while in Ubuntu it always terminates with a SIGSEGV error.
The exact moment programs terminate is right after I open a video file with a provided example, TestPlayer(in package uk.co.caprica.vlcj.test.basic)
(Of course, the TestPlayer with the video file worked completely fine in Windows)
I've tried to run the TestPlayer in both command-line and eclipse with as many combination of the following Ubuntu, vlc, and vlcj versions as possible.
I even tried some on my friend's laptop and ended up in the same situation.
Details of my tests and a log file are as in the following
OS Ubuntu 10.04 (Linux 2.6.32-21-generic) in VMWare
Ubuntu 12.04 (linux 3.2.0-23-generic-pae) in VMWare and in direct installation
JDK 1.7.0_05
Eclipse Juno 20120614-1722
Path to the
vlc libraries /home/prosopher/vlc/lib (I gave it when I typed configure command)
vlc version 1.1.10 / 2.0.2 (I mannually installed these in the above path)
vlcj version 1.1.5 / 1.2.2 / 2.1.0
I tried every combination of the above Ubuntu, vlc, and vlcs versions.
In command-line I typed the following line.
java –jar –Djna.library.path=”/home/prosopher/vlc/lib” vlcj-1.1.5-test.jar
In eclipse I gave the VM arguments –Djna.library.path.
Let me know if you need more information or don’t understand anything in my writing.
Sincerely,
The text was updated successfully, but these errors were encountered: