Segfaults when using a custom keymap

Submitted by bidinou on Sat, 2013-09-28 11:13

Forums:

Hi everyone !

I'm pretty happy with moc, and use it in a arcade cabinet with a Raspberry Pi : it only has sticks & buttons that are connected to an I-PAC interface (so they behave like keyboard keys).

I defined a custom keymap file where I changed almost everything and disabled many keys I do not need. It works well. (apart from the fact I cannot use the CTRL/ALT modifiers with the left/right/up/down keys, it works well :)

However, when my keymap is enabled, I get a segfault when starting moc, about 66% of the time (at launch time).

Do you have any idea what might be wrong ?

Here is my keymap file : http://pastebin.com/nfTKtBWq
Here is my config file : http://pastebin.com/u7n9NLC6

Cheers & thanks again !

jcf

Sat, 2013-09-28 21:18

... it worked fine for me every time. Firstly, a couple of notes:

  • The configuration files you posted used DOS line termination (<CR><LF>) rather than Unix (<NL>). I suspect this is a corruption introduced by PasteBin, but you should check and convert (using fromdos(1)) if necessary.
  • There were some warnings about the use of the changed OSSMixerChannel and AlsaMixer options. Either your version of MOC is somewhat out of date (and not issueing those warnings) or you need to update your configuration file to resolve them.

So, the first step would be to upgrade to the latest SVN HEAD and/or update the configuration files to fix the line termination and warnings.

If the problem still exists, then run MOC with the -D option and e-mail mocmaint the compressed mocp_*_log files. It's possible that if the problem is indeed in the configuration files then those log files will be empty, in which case it would be pointless e-mailing them.

It's also possible that the configuration files are a red herring, so are you able to try starting MOC using the supplied configuration files and report whether or not the segfault still occurs.

bidinou

Sun, 2013-09-29 08:18

Hi jcf ! Thanks again for your prompt reply !

Actually I'm using the version from Debian Wheezy (ARM), which is apparently (pretty strange for a stable distro) version : 2.5.0~alpha4+svn20120224-1

I'll let you know as soon as it's done.

riesebie

Mon, 2013-09-30 14:13

There is a fairly new version avilable in Jessie (testing).

Elimar

bidinou

Fri, 2013-10-04 11:00

Hi !

I took way too much time to test it :-)

1) couldn't use the packages from Debian testing because it needed too many dependencies from the testing repos

2) I compiled the 2.5 beta 1 : it segfaults as well

3) I compiled the SVN version (as of today) : bug seems to be fixed !! :-)

BTW : I know the Pi is a very slow computer, but I'm wondering if that's normal that I feel a slight delay when moving the cursor in the file manager / playlist ? Also the initial scan of the playlist takes a couple of seconds (more or less depending on the nomber of entries)

tomaszg

Fri, 2013-10-04 11:55

Hi, I'm using MOC on even slower machine (hacked TP-link router) and menu navigation is ok. However MOC startup and reading tags is slow. The worst situation is with mp3 as their tags require more computing power/disk read.

I also have some segfaults on this machine, but they are mostly related to various non-standard characters in file names or tags. I still didn't find the exact cause.

jcf

Fri, 2013-10-04 20:31

Glad to hear it's fixed in SVN. There have been several patches committed which fix potential segfaults although they seemed to have caused none in the wild. Given I couldn't reproduce your segfault, it may have been one of those which fixed it.

I haven't had cursor delay on RPi reported to me, and I do know several users are running MOC on those devices. You may wish to play with your ESCDELAY environment variable setting.

Delays caused by tag reading can mitigated by appropriate settings of the ReadTags and ShowTime configuration options. The reading of tags in MP3 is particularly painful because the ID3 tags can be scattered throughout the file and so forces the reading of the whole file to find their hidey-holes. FFmpeg/LibAV also reads large portions of the file in order to determine its format and codec.