Bug 565974 – media-video/vlc-2.2.1-r1: can return non zero, propagating xdg-open file.mkv to command line browsers

• Product: Gentoo Linux
• Status: RESOLVED TEST-REQUEST

[Description Jelte Fennema 2015-11-16 19:30:07 UTC]

I'm very unsure how to file this exactly, since my issue is a combination of a couple of things. But the issue itself is pretty serious, resulting in a program eating up all my RAM.

When running "xdg-open video.mkv", xdg-open will first try to open it using vlc. it does this with "vlc --started-from-file video.mkv". This is where the initial issue arrises. If another vlc is already running, it will open the video in that instance. When this happens xdg-open will try to open it some other way, missing all the normal browsers (since they are called differently on Gentoo), eventually reaching text based browsers like links and w3m. 

For some reason this results in links or w3m eating up all my memory and starting on my swap, which freezes up my pc. The only way to stop it is killing the process.

This bugs stems from a couple of problems.
- vlc returning a non zero exit status when it succeeds in opening the file
- xdg-open trying to use text based browsers to open the mkv file (might not be an actual issue)
- links and w3m eating up all memmory (not sure how this happens)

Reproducible: Always

Steps to Reproduce:
1. Obtain an mkv file
2. open vlc
3. run xdg-open video.mkv
4. open htop to see memory is disappearing because of w3m or links
Actual Results:  
Computer freezes

Expected Results:  
Video gets opened by vlc and xdg-open is happy with that

My output of xdg-open:

$ xdg-open video.mkv
VLC media player 2.2.1 Terry Pratchett (Weatherwax) (revision 2.2.1-0-ga425c42)
Opening "video.mkv" with VLC media player  (video/x-matroska)
VLC media player 2.2.1 Terry Pratchett (Weatherwax) (revision 2.2.1-0-ga425c42)
/usr/bin/xdg-open: line 775: x-www-browser: command not found
/usr/bin/xdg-open: line 775: firefox: command not found
/usr/bin/xdg-open: line 775: iceweasel: command not found
/usr/bin/xdg-open: line 775: seamonkey: command not found
/usr/bin/xdg-open: line 775: mozilla: command not found
/usr/bin/xdg-open: line 775: epiphany: command not found
/usr/bin/xdg-open: line 775: konqueror: command not found
/usr/bin/xdg-open: line 775: chromium-browser: command not found
/usr/bin/xdg-open: line 775: google-chrome: command not found
/usr/bin/xdg-open: line 775: www-browser: command not found
/usr/bin/xdg-open: line 775: links2: command not found
/usr/bin/xdg-open: line 775: elinks: command not found

/usr/bin/xdg-open: line 765: 29879 Terminated              $browser "$1"
/usr/bin/xdg-open: line 775: lynx: command not found

[Comment 1 Jonas Stein 2015-11-21 11:45:30 UTC]

I could not reproduce this on my gentoo machine. 

I used 
MPEG-4 Content Testfile "Test 1"
http://download.wavetlan.com/SVV/Media/HTTP/http-mkv.htm

Can you evaluate, if the problem does only occur with a special video file?

Besides that it sounds rather like an upstream bug rather than a gentoo bug, but we will see.

[Comment 2 Jelte Fennema 2015-11-21 17:56:55 UTC]

Created attachment 417502 [details]
Links with the Test 1 file

VLC returned non zero as well when opening this file for a second time. However, When opening it with xdg-open, links did not eat up memory like it used to do. It did open it however and tried to display the contents. At the moment I'm downloading the larger file to see how that fares, but the transfer speed is very slow.

Also, you might very well be right about the issue being upstream. I'll file a bug report at the different involved software bugtrackers as well.

[Comment 3 Jelte Fennema 2015-11-21 18:15:53 UTC]

I just tried the larger file (Test 4) and again, links tried to open it. This time though, links used up about 500MB of RAM, for an 80MB file. My normal mkv files are at least about 1GB, which you can imagine would be quite a serious memory hog when multiplied by 6.

Opening files with w3m directly does not cause the issue, but it does when it is opened by xdg-open. Because both of these browsers suffer from the same problem I'm wondering if something deeper down is at the core of the issue.

PS I also created a bug report at the VLC bugtracker: https://trac.videolan.org/vlc/ticket/15947#ticket