whatever kodi does here, mysql must not crash. So this is a mariadb bug.
Hello,
Unfortunately I may confirm that the OP might be right and that this may be a problem with either the new version of Kodi (Isengard) or the Arch Linux developers team.
I can confirm that I have the same problem with both ALArm (pi) and x86_64 latest versions of Arch Linux.
To reproduce it suffices to play the same music in library mode toggled on in any one of these machines.
The symptom of a crash is just the hanging of the Kodi request and the restart (eventually) of a random playing music, be it one of the album you were looking to play, or some other random music.
It may (or may not) be related to party mode being tested unsuccessfully. I don't know for sure.
Extra info:
- The server is located in the x86_64 machine, and yeah just crashes MariaDB server if using library mode.
- If I toggle off library mode, and I just try to play the music file, it plays well the chosen music.
If I can do anything further just let me know please,
hoping there will be some fix... signing out...
Nevermind ---> It seems the bug is really from MariaDB... Sorry for the mishap
More information here --->
https://mariadb.atlassian.net/browse/MDEV-8525
(2015-07-22, 17:58)wsnipex Wrote: [ -> ]whatever kodi does here, mysql must not crash. So this is a mariadb bug.
Hello, this is getting pretty embarrassing, but I am thinking I should take back what I've posted yesterday about the strong probability of this error being the responsibility of MariaDB. I have just one point as to sustain what I have said:
Version 14 of Kodi doesn't display such crashing 'temper' so... I should ask, whom might be responsible for the development of the new MyMusic52 database? Is it Kodi devel team, Arch, or MariaDB?
I did try several things (after cleaning all the db's from step a) onwards):
a) to replace mariadb with mysql (only on the server side). This worked on the server but prevented (still don't know exactly why) the proper connectivity from Arch Linux Arm (pi) to the server ArchLinux x86_64;
b) tried to get back to mariadb on the server (after having cleaned mysql databases again), and downgrade kodi to major version 14.2, on both of the architectures, which immediately rendered the systems usable again, and pointed me here again to raise the question of whom might be the responsible for the MyMusic52 database development. I strongly believe that It might be the reason why kodi 15 is facing these major problems on my systems.
Hope that
wsnipex may understand the logic behind my deduction and forgive me for apparently being so sure that this might be a Kodi (own or Kodi+Arch development) inconsistency. Or maybe I am wrong and mariadb should also be taken into account.
So I ask, finally, what exactly did change from versions 52 an 48 of MyMusic databases?
Yours,
I can only repeat myself: Kodi is just a sql client in this use case. We are sending valid SQL... Even if it wouldn't be valid SQL, a DB must NEVER crash because of it, but should just throw an error.
Ok
wsnipex I understand your point. Can you please, at least confirm that kodi version is using the socket protocol with mysql here?
By the logs that I have seen kodi shows errors when trying to connect to /run/mysqld/mysqld.sock (out of memory) and I assume that kodi is trying to connect using the socket protocol. I do not know if that is a correct assumption. Nonetheless mysql Mariadb server doesn't seem to be using it. After the crash, when I try to find that socket with command
as root user, nothing of the kind shows up.
Thanks again but kodi 15 is a no go yet, due to this. And I sure regret it is so, I was eager to try it out fresh but maybe that time is too much soon yet.
use mysql, we don't even officially support mariadb.
And since we use libmysqlclient, it should use whatever is configured there, I'm guessing TCP.
But tbh, I'm not sure, since I don't use it personally.
(2015-07-25, 17:18)wsnipex Wrote: [ -> ]use mysql, we don't even officially support mariadb.
And since we use libmysqlclient, it should use whatever is configured there, I'm guessing TCP.
But tbh, I'm not sure, since I don't use it personally.
Hello again
wsnipex.
I have already tried to use mysql at the server and (at least locally, in the server) the database doesn't falter. But then, when I try to access it from Kodi in the arch pi, then it is kodi who segfaults. Don't you think that might be odd? I think the problem may very well reside in me in being so ignorant as to try something that otherwise should be simple to work. I mean it was working before with previous stable version... go figure...
Either way, thank you very much for your pointers.
I will try to look harder both here at the forums and in a larger community.
Yours.
I am interested in the PI's segfault backtrace.
Hello.
Thank you both for the interest shown in this cause.
fritsch This is one of the crash logs. Although it might not be what you were looking for, maybe it will help. --->
sprunge link where the (scrapped for sensible info) crash log is
Meanwhile,
wsnipex and
fritsch. Following
wsnipex gentle advice, I've moved on to mysql. That was definitely one giant step to solve this problem (I suppose). The other might have been to add one particular setting on
Code:
/etc/nsswitch.conf
WAS---> hosts: files dns myhostname
BECAME --> hosts: files dns myhostname mdns
I am just guessing that this might have been needed since when I tried to build kodi from source, one of its dependencies was nss-mdns. Also my shares are on nfs filesystem. And finally, I thought that some warnings on mysql server about ip name resolution could be related to this issue.
Summing up:
- Migrating to mysql
- adding the 'mdns' tweak
May well have solved the issue.
Yours
that log shows access denied messages for the DB and NFS.
I can only second what @
wsnipex said.
See my comment on the mariadb bugtracker
https://mariadb.atlassian.net/browse/MDE...ment-73850
Mariadb crashes if the query is executed from shell or phpmyadmin.
This should never happen, ever, even if the query is bogus, even if I open a socket and pipe /dev/random into it it should NOT crash.
(2015-07-25, 19:43)fritsch Wrote: [ -> ]I am interested in the PI's segfault backtrace.
(2015-07-25, 22:22)mccurly Wrote: [ -> ]Meanwhile, wsnipex and fritsch. Following wsnipex gentle advice, I've moved on to mysql. That was definitely one giant step to solve this problem (I suppose). The other might have been to add one particular setting on Summing up:
- Migrating to mysql
- adding the 'mdns' tweak
May well have solved the issue.
Yours
(2015-07-25, 22:57)wsnipex Wrote: [ -> ]that log shows access denied messages for the DB and NFS.
(2015-07-26, 01:06)asavah Wrote: [ -> ]I can only second what @wsnipex said.
See my comment on the mariadb bugtracker https://mariadb.atlassian.net/browse/MDEV-8525?
@asavah
Thank you for your intervention here. I am also glad that you second
wsnipex because I did link your post@atlassian to this thread here, and that implies that I, too, know this problem, presently, happens with mariadb, and I know that because of
asavah's post @atlassian. I think an appreciation for your work may also be in order...
Moving on...
Now,
@wsnipex et al. I know that those logs are not stack traces... Even though, have you in fact had a look at them? At the top of it says:
Quote:############### STACK TRACE #################
gdb not installed, can't get stack trace.
############# END STACK TRACE ###############
And the facts are:
- I don't have gdb installed on ArchPI (yet);
- I truly believe that it is not only up to MariaDB developers to come up with every database design that is in fact used with their database API (?), or is it? I do know that recently mariadb has updated two or trhree times in Arch linux. Maybe that would be enough for breaking a great number of aspects that were mandatory for mysql feature of kodi 15 to work properly. And those aspects might not have been necessary for 14.2 version of kodi. Nevertheless this is a 'joint' problem. And should be solved accordingly. Who says that oracle's mysql won't suffer (or hasn't suffered already from the same glitches)?
Again thank you for your time. For now (on the oracle's mysql and kodi v.15 side), the problem is seems contained (perhaps it never existed or perhaps it won't ever come up... who knows?)
I am also positive that version 14.2 worked flawlessly... (with no problematic access from lan computers to any nfs share whatsoever)... I mean
@wsnipex and
@asavah, was that even a topic in this thread? Besides tweaking
/etc/nsswitch.conf file all the permissions to the databases and nfs shares remained the same...
Yours.
(2015-07-26, 17:57)mccurly Wrote: [ -> ][*]I don't have gdb installed on ArchPI (yet);
Then you might want to install it ASAP as your log is unfortunately worthless without it.
There is currently no indication from the log that the crash of Kodi is SQL related - all the log shows is an inability for Kodi to communicate with the SQL and NFS servers (network problems?), and then a crash (of Kodi) occurring as/after the Kodi application has shut down.
Also, you started out saying that the MariaDB server is crashing yet you are posting a Kodi crashlog. Which is it?
If the MariaDB process is crashing then you need to capture the stacktrace from the MariaDB process, however a flaky/buggy/unstable SQL server is not really a Kodi issue - as already explained, valid SQL should never result in the SQL server crashing. The fact your Kodi process is (also?) crashing on shutdown makes me wonder if there's a more general issue with your Arch system.
As you have a Pi, why not try an OpenELEC test build on a spare SD card (I'd suggest one of the
Kodi 15 series that matches your existing database versions) as 1) the test builds have automated gdb crashlog support and 2) are known to work reliably where MySQL is concerned.
If Kodi continues to crash in an OpenELEC test build then post the Kodi crashlog. If your MariaDB server continues to crash, I'd suggest sending the details to the MariaDB developers.