[SOLVED] VLC 2.2.1 on current: 32-bit OK, segfault on 64-bit

kikinovak · 01-03-2016, 11:40 AM

Hi,

I just built VLC 2.2.1 on Slackware -current, on 32-bit as well as on 64-bit with multilib installed. Here's what I have so far.

1. Both version built perfectly.

2. The 32-bit version runs perfectly.

3. The 64-bit version immediately segfaults.

Here are the SlackBuild, sources and patches I used: they're pretty much Matteo Bernardini's unmodified source from his Github repo:

http://www.microlinux.fr/microlinux/...vlc.SlackBuild

Since I have a multilib system, I tried rebuilding it with the following modification:

Code:

CFLAGS="$SLKCFLAGS" \
CXXFLAGS="$SLKCFLAGS" \
LDFLAGS="-L/usr/lib${LIBDIRSUFFIX}" \
./configure \
  --prefix=/usr \

Note: I only uploaded the previous version of the SlackBuild, so this is only a local test.

This time I have a slight improvement. VLC starts up and I see the GUI... but as soon as I try to open a file with it, it segfaults again.

Any suggestions?

Niki

ponce · 01-03-2016, 11:55 AM

Hi Niki,

I just tried to build vlc with all the dependencies (included a full-featured ffmpeg) on a slackware64-current install (no multilib) using my unsupported repository for current and all went well: I just excluded avahi from the stuff I had listed in vlc.info's REQUIRED because I just can't stand it

I also tried using the resulting package with some movies encoded with different codecs and they played fine too with no segfaults.

frankly I don't know what went wrong with your package.

willysr · 01-03-2016, 12:40 PM

one of the deps requires changes due to multilib setup?

kikinovak · 01-03-2016, 01:19 PM

Quote:

Originally Posted by willysr

one of the deps requires changes due to multilib setup?

I've also come to that conclusion. Only to wonder how I could possibly find the needle in the haystack.

moesasji · 01-03-2016, 02:45 PM

Quote:

Originally Posted by kikinovak

I've also come to that conclusion. Only to wonder how I could possibly find the needle in the haystack.

It looks like a pointer bug to me as valgrind shows a memory read at address 0x0 when vlc segfaults. See:

Code:

==1210== Invalid read of size 8
==1210==    at 0x40131A0: __tls_get_addr (in /lib64/ld-2.22.so)
==1210==    by 0x339B5EF2: ??? (in /usr/lib64/libpixman-1.so.0.33.6)
==1210==    by 0x33971828: pixman_image_composite32 (in /usr/lib64/libpixman-1.so.0.33.6)
==1210==    by 0x33674AA4: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x336B73F0: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x336AA22F: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x336AAC09: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x336ABA52: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x33668A27: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x33679546: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x336AEAD6: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x3367093B: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1210== 
==1210== 
==1210== Process terminating with default action of signal 11 (SIGSEGV)
==1210==  Access not within mapped region at address 0x0
==1210==    at 0x40131A0: __tls_get_addr (in /lib64/ld-2.22.so)
==1210==    by 0x339B5EF2: ??? (in /usr/lib64/libpixman-1.so.0.33.6)
==1210==    by 0x33971828: pixman_image_composite32 (in /usr/lib64/libpixman-1.so.0.33.6)
==1210==    by 0x33674AA4: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x336B73F0: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x336AA22F: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x336AAC09: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x336ABA52: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x33668A27: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x33679546: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x336AEAD6: ??? (in /usr/lib64/libcairo.so.2.11400.6)
==1210==    by 0x3367093B: ??? (in /usr/lib64/libcairo.so.2.11400.6)

I don't really know how to read this output from valgrind, but my guess would be that it relates to a problem with cairo.

btw) I don't see why VLC would use multilib just to open a file-open menu; but if so it might be that cairomm requires a compat32?

andrew.46 · 01-04-2016, 12:18 AM

Probably not much help but I run the development version of vlc on 64bit -current multilib with no patches. (Using my own SlackBuild). And no seg faults there but I guess this is a long way down the track from the version that you are building.

You can get some odd results if the config files are screwed and often this helps:

Code:

cvlc --reset-config && cvlc --reset-plugins-cache

a very outside chance....

kikinovak · 01-04-2016, 10:03 AM

I've solved the problem by removing VLC and replacing it by UMPlayer. VLC is a nice multimedia, but it's a PITA to build and a nightmare to debug. Whenever I feel the need for it again, I'll just use Eric's statically built package.

Cheers,

Niki

bassmadrigal · 01-05-2016, 09:15 AM

Quote:

Originally Posted by kikinovak

I've solved the problem by removing VLC and replacing it by UMPlayer.

Might I suggest SMPlayer over UMPlayer? UMPlayer was originally a fork of SMPlayer because development of it ceased in 2009. However, the opposite is now true. UMPlayer hasn't been updated since 2011 while SMPlayer development started again in 2013 and is now actively maintained. I also prefer the UI of SMPlayer, however, it is themeable. There is also a SlackBuild on SBo for it.

SMPlayer also has support for mpv, for those who prefer it over mplayer.

kikinovak · 01-05-2016, 04:59 PM

Quote:

Originally Posted by bassmadrigal

Might I suggest SMPlayer over UMPlayer? UMPlayer was originally a fork of SMPlayer because development of it ceased in 2009. However, the opposite is now true. UMPlayer hasn't been updated since 2011 while SMPlayer development started again in 2013 and is now actively maintained. I also prefer the UI of SMPlayer, however, it is themeable. There is also a SlackBuild on SBo for it.

SMPlayer also has support for mpv, for those who prefer it over mplayer.

I hesitated over the two and decided to go for UMPlayer. SMplayer likes to nag with updates and does strange thinks like opening Firefox on the SMplayer homepage when you open your first video. I think with MPlayer frontends you have to go not for the best, but for the lesser evil.

_gin · 01-05-2016, 05:11 PM

@kikinovak

In 2013, the Smplayer team did release a corrected umplayer version, released as umplayer-0.98.2 .

Did you give it a try?

http://smplayer.sourceforge.net/fr/umplayer

kikinovak · 01-05-2016, 05:58 PM

Quote:

Originally Posted by _gin

@kikinovak

In 2013, the Smplayer team did release a corrected umplayer version, released as umplayer-0.98.2 .

Did you give it a try?

http://smplayer.sourceforge.net/fr/umplayer

Nope. Apparently, some developers love to play hide-and-seek with their sources.

Diantre · 01-06-2016, 01:16 PM

Quote:

Originally Posted by kikinovak

SMplayer likes to nag with updates and does strange thinks like opening Firefox on the SMplayer homepage when you open your first video. I think with MPlayer frontends you have to go not for the best, but for the lesser evil.

That behavior can be disabled in SMPlayer. Go to "Preferences -> Updates" and uncheck the two options there, "Check for updates" and "Open an informative page after an upgrade". And the evil goes away...

Also, if you prefer, it's possible to change the configuration file instead. Edit ~/.config/smplayer/smplayer.ini and look for these values:

Code:

[smplayer]
version=0.8.4
check_for_new_version=true
stable_version=15.9.0
check_if_upgraded=false

[update_checker]
checked_date="@Variant(\0\0\0\xe\0%\x7f,)"
last_known_version=15.11.0.7247
enabled=false
days_to_check=7

Setting the values in bold to false should stop the nagging.

bassmadrigal · 01-06-2016, 02:06 PM

Quote:

Originally Posted by Diantre

Also, if you prefer, it's possible to change the configuration file instead. Edit ~/.config/smplayer/smplayer.ini and look for these values:

Code:

[smplayer]
version=0.8.4
check_for_new_version=true
stable_version=15.9.0
check_if_upgraded=false

[update_checker]
checked_date="@Variant(\0\0\0\xe\0%\x7f,)"
last_known_version=15.11.0.7247
enabled=false
days_to_check=7

Setting the values in bold to false should stop the nagging.

If Niki wants to use smplayer due to it being newer and actively maintained, it might be worth trying to change the values before generating the package. I don't have access to the code right now, but you could probably change the default values in the code itself with a sed in the SlackBuild; then you don't need to change every individual user's config.ini files after they started the app.

Nille_kungen · 01-06-2016, 03:49 PM

You can also remove checking for updates in GUI Options>Preferences>Updates just tick out the boxes there.
"Check for updates" box is the update_checker enabled option in the config file.
"Open an informative page after an upgrade" box is the check_if_upgraded option in the config file.

Diantre · 01-06-2016, 06:31 PM

Quote:

Originally Posted by bassmadrigal

If Niki wants to use smplayer due to it being newer and actively maintained, it might be worth trying to change the values before generating the package. I don't have access to the code right now, but you could probably change the default values in the code itself with a sed in the SlackBuild; then you don't need to change every individual user's config.ini files after they started the app.

Yes, modifying the source is a possibility. Another approach would be to put a bare-bones .config/smplayer/smplayer.ini in /etc/skel, so every new user in the system get a default configuration. But that's just an idea, I haven't actually test it and I don't really know if this would work for Niki.