Is Ubuntu 8.04/Perl 5.8.8 no longer supported ?

[erland]

I just tried to get latest 8.0 and 7.9 from git running on my Ubuntu 8.04.4 development machine running perl 5.8.8 and both fails immediately with Segmentation fault.

erland@squeezedev:~$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04.4 LTS"
erland@squeezedev:~$ uname -a
Linux squeezedev 2.6.24-28-virtual #1 SMP Wed Nov 24 10:38:58 UTC 2010 i686 GNU/Linux
erland@squeezedev:~$ perl -v

This is perl, v5.8.8 built for i486-linux-gnu-thread-multi

I checked out like this:

git clone git://github.com/Logitech/slimserver.git server
cd server
git checkout --track -b public/7.9 origin/public/7.9

I'm starting LMS with a command with:

slimserver.pl --cachedir /var/lib/squeezecenter/Cache80 --prefsdir /home/erland/Configurations/Prefs80 --logdir /var/lib/squeezecenter/Logs80 --d_startup

(Each directory is empty and the current user have read/write access to them)

The console output is in the attached log file squeezecenter.log.

I've installed LMS in a directory /media/disk2/squeezecenter/8.0/server which might be confusing since it's really 7.9 that it runs at the moment. I planned to run 8.0 but switched to 7.9 when I saw 8.0 didn't work. I get the same problem with 8.0.

I tried going back and if I go back to the following revision from September 27 2018 it starts properly:

git checkout e7e0cc89414dd62c25ab699a71c5bbf5fc8f05e1

But if I checkout the revision after that one, it fails with segmentation fault:

git checkout 6a22053ab80130ae380828ff4ed681096fe6c884

Not sure if I'm missing something but from the look of that revision (https://github.com/Logitech/slimserv...d681096fe6c884) it doesn't seem to introduce any changes that can cause segmentation fault before LMS even writes any log files.

Is my Linux version no longer supported by LMS or do I need to manually rebuild some binaries or similar to make it work ?
(Yes, I know Ubuntu 8.04 is old, but since I don't have much time these days I figured the easiest way to get 8.0 up and running so I could verify my plugins was to use my already existing machine which happens to run Ubuntu 8.04)

Is there any way to easily debug it to see what's causing the problem if Ubuntu 8.04 and perl 5.8.8 is supposed to work ?

[mherger]

> I just tried to get latest 8.0 and 7.9 from git running on my Ubuntu
> 8.04.4 development machine running perl 5.8.8 and both fails immediately
> with Segmentation fault.

Segfault is odd, as we certainly didn't modify 5.8 binaries.

The revision you mentioned is 7.7, isn't it? I'd only go back in the
straight 7.9 line, or 7.8 if that was breaking already.

I wouldn't be surprised if LMS 8 did use some instruction or Perl
feature which wasn't available in 5.8.8 yet. I remember discussing the
topic a few weeks ago with somebody, as a PR was using a construct which
was experimental in a much more recent Perl, and I didn't want to merge
that.

All that said I'd say 7.9 should still work with Perl 5.8.8. The commit
you mentioned definitely can't be the breaking change, as it's not code
which would be run at startup time.

--

Michael

[erland]

> I just tried to get latest 8.0 and 7.9 from git running on my Ubuntu
> 8.04.4 development machine running perl 5.8.8 and both fails immediately
> with Segmentation fault.

Segfault is odd, as we certainly didn't modify 5.8 binaries.

The revision you mentioned is 7.7, isn't it? I'd only go back in the
straight 7.9 line, or 7.8 if that was breaking already.

It was merged from 7.7, will take a look if I see the same issue in 7.7 and get back to you.

The commit
you mentioned definitely can't be the breaking change, as it's not code
which would be run at startup time.

Yes, I thought it looked strange too, but I tried git checkout back and forward between the two revisions I mentioned and it worked with one and not with the other. According to github web interface commit log they were after each other.

I wonder if it could be related to something installed on my machine ?

It’s just strange that it breaks with this specific commit for some reason.

[mherger]

>> The revision you mentioned is 7.7, isn't it? I'd only go back in the
>> straight 7.9 line, or 7.8 if that was breaking already.
>>
> It was merged from 7.7, will take a look if I see the same issue in 7.7
> and get back to you.

It's my understanding that the revision you mentioned was the commit in
7.7 which then got merged. Therefore there would be many more changes in
between, even though chronologically they might be adjacent commits, but
on different branches.

But your LMS would certainly tell you whether it's 7.7 or not :-).

--

Michael

[erland]

>> The revision you mentioned is 7.7, isn't it? I'd only go back in the
>> straight 7.9 line, or 7.8 if that was breaking already.
>>
> It was merged from 7.7, will take a look if I see the same issue in 7.7
> and get back to you.

It's my understanding that the revision you mentioned was the commit in
7.7 which then got merged. Therefore there would be many more changes in
between, even though chronologically they might be adjacent commits, but
on different branches.

But your LMS would certainly tell you whether it's 7.7 or not :-).

The commit I mentioned was the one in 7.9, but I’ll get back to you when I’ve tried if I see the same problem with the corresponding commit in 7.7.

I suspect it’s something with my setup that’s causing it.

In worst case I’ll have to setup a newer development machine, it’s just that it’s hard to get the time when trying to take care of my 11 months child at the same time :-)

[mherger]

> In worst case I’ll have to setup a newer development machine, it’s just
> that it’s hard to get the time when trying to take care of my 11 months
> child at the same time :-)

Just wait until he's 2+ :-D

--

Michael

[erland]

>> The revision you mentioned is 7.7, isn't it? I'd only go back in the
>> straight 7.9 line, or 7.8 if that was breaking already.
>>
> It was merged from 7.7, will take a look if I see the same issue in 7.7
> and get back to you.

It's my understanding that the revision you mentioned was the commit in
7.7 which then got merged. Therefore there would be many more changes in
between, even though chronologically they might be adjacent commits, but
on different branches.

But your LMS would certainly tell you whether it's 7.7 or not :-).

I'm a bit confused (feel stupid), how do I know which commit that's before another on a specific branch ?

I thought I could checkout the branch and then do git log and then git checkout with the commit hash but that doesn't work because according to git log I see the following:

commit 6a22053ab80130ae380828ff4ed681096fe6c884
Merge: 6ed5cca... e7e0cc8...
Author: Michael Herger <mherger@logitech.com>
Date:   Thu Sep 27 07:40:25 2018 +0200

    Merge branch 'public/7.7' into public/7.9

commit e7e0cc89414dd62c25ab699a71c5bbf5fc8f05e1
Author: Michael Herger <mherger@logitech.com>
Date:   Wed Sep 26 13:09:30 2018 +0200

    Issue 218 - fix station artwork mess left behind some undocumented TuneIn API change.

Where 6a22053ab80130ae380828ff4ed681096fe6c884 is on 7.9.2 and doesn't work and e7e0cc89414dd62c25ab699a71c5bbf5fc8f05e1 is 7.7.7 and does work.

How do I check which commit that's before 6a22053ab80130ae380828ff4ed681096fe6c884 on the public/7.9 branch ?

I tried latest 7.7 and 7.8 and both work while latest 7.9 and 8.0 result in Segmentation Fault.

[mherger]

TBH: I don't know how to do using command line tools. I'm using visual git client (SourceTree - free for personal use).



Following the lines I'd see that e7e0cc89414dd62c25ab699a71c5bbf5fc8f05e1 was the last commit in 7.7 that we merged in to 7.9.

[erland]

TBH: I don't know how to do using command line tools. I'm using visual git client (SourceTree - free for personal use).



Following the lines I'd see that e7e0cc89414dd62c25ab699a71c5bbf5fc8f05e1 was the last commit in 7.7 that we merged in to 7.9.

Can you see which commit that comes before
6a22053ab80130ae380828ff4ed681096fe6c884 in 7.9 branch ?

[mherger]

> Can you see which commit that comes before
> 6a22053ab80130ae380828ff4ed681096fe6c884 in 7.9 branch ?

6ed5ccac9c90ef48b4e78682026573971f1406d5

the --first-parent option might be what you're looking for:

git log --first-parent

This gives me the full history of commits to 7.9, with the merges, but
without the commits included in those merges.

commit cf39954b753d6148a2f20b6891439c03b76ffce3
Merge: 6a22053ab 8a129a0cd
Author: Michael Herger <mherger (AT) logitech (DOT) com>
Date: Fri Oct 5 08:08:29 2018 +0200

Merge pull request #220 from warthog9/public/7.9

Fix suprious error message relating to SSL_verify_mode

commit 6a22053ab80130ae380828ff4ed681096fe6c884
Merge: 6ed5ccac9 e7e0cc894
Author: Michael Herger <mherger (AT) logitech (DOT) com>
Date: Thu Sep 27 07:40:25 2018 +0200

Merge branch 'public/7.7' into public/7.9

commit 6ed5ccac9c90ef48b4e78682026573971f1406d5
Author: Michael Herger <mherger (AT) logitech (DOT) com>
Date: Wed Sep 26 13:09:30 2018 +0200

Issue 218 - fix station artwork mess left behind some undocumented
TuneIn API change.



--

Michael