ir-keytable segfault when writing keymap from file

ir-keytable segfault when writing keymap from file

[camden lindsay]

Hello-
I had a working ir-keytable script that stopped working the other day.
Investigation led to finding that ir-keytable was segfaulting whenever
trying to write a keymap from a file.

[kodiuser@kodiarch ~]$ uname -a
Linux kodiarch 5.4.13-arch1-1 #1 SMP PREEMPT Fri, 17 Jan 2020 23:09:54
+0000 x86_64 GNU/Linux
[kodiuser@kodiarch ~]$

[kodiuser@kodiarch ~]$ ir-keytable -V
IR keytable control version 1.18.0
[kodiuser@kodiarch ~]$

Here's an example of grabbing an existing keytable entry, putting it
in a file, but showing that after clearing and trying to load that
file the segfault.  Segfault also occurs if not clearing first.

[kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -r | grep KEY_DOWN
Enabled kernel protocols: lirc nec
scancode 0x800f041f = KEY_DOWN (0x6c)
[kodiuser@kodiarch ir-keytable]$ cat /etc/ir-keytable/keymap.txt
scancode 0x800f041f = KEY_DOWN (0x6c)
[kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -c
Old keytable cleared
[kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -w /etc/ir-keytable/keymap.txt
Segmentation fault
[kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -r | grep KEY_DOWN
Enabled kernel protocols: lirc nec
[kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -r
Enabled kernel protocols: lirc nec
[kodiuser@kodiarch ir-keytable]$



And this shows that the segfault still occurs even if i don't clear
the keytable first (but of course the existing contents of the table
still exist)
[kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
Enabled kernel protocols: lirc nec
scancode 0x800f041f = KEY_DOWN (0x6c)
[kodiuser@kodiarch ~]$ cat /etc/ir-keytable/keymap.txt
scancode 0x800f041f = KEY_DOWN (0x6c)
[kodiuser@kodiarch ~]$ sudo ir-keytable -w /etc/ir-keytable/keymap.txt
Segmentation fault
[kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
Enabled kernel protocols: lirc nec
scancode 0x800f041f = KEY_DOWN (0x6c)
[kodiuser@kodiarch ~]$


Here is the example syslog output of the segfault:
Jan 20 18:15:33 kodiarch kernel: ir-keytable[817]: segfault at 0 ip
00007f1a958436f5 sp 00007ffe039a5aa8 error 4 in
libc-2.30.so[7f1a95707000+14d000]
Jan 20 18:15:33 kodiarch kernel: Code: 00 00 0f 1f 00 31 c0 c5 f8 77
c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 89 f9 48 89 fa c5 f9 ef
c0 83 e1 3f 83 f9 20 77 2b <c5> fd 74 0f c5 fd d7 c1 85 c0 0f 85 eb 00
00 00 48 83 c7 20 83 e1
Jan 20 18:15:33 kodiarch systemd[1]: Started Process Core Dump (PID 818/UID 0).
Jan 20 18:15:34 kodiarch systemd-coredump[819]: Process 817
(ir-keytable) of user 0 dumped core.

                                                Stack trace of thread 817:
                                                #0  0x00007f1a958436f5
__strlen_avx2 (libc.so.6 + 0x1616f5)
                                                #1  0x00007f1a95770be3
__strdup (libc.so.6 + 0x8ebe3)
                                                #2  0x0000563150aa43b7
n/a (ir-keytable + 0x83b7)
                                                #3  0x0000563150aa44c6
n/a (ir-keytable + 0x84c6)
                                                #4  0x00007f1a957edfc0
argp_parse (libc.so.6 + 0x10bfc0)
                                                #5  0x0000563150aa2099
n/a (ir-keytable + 0x6099)
                                                #6  0x00007f1a95709153
__libc_start_main (libc.so.6 + 0x27153)
                                                #7  0x0000563150aa325e
n/a (ir-keytable + 0x725e)
Jan 20 18:15:34 kodiarch systemd[1]: systemd-coredump@3-818-0.service:
Succeeded.


Thoughts/troiubleshooting suggestions?

Many thanks
Camden

Re: ir-keytable segfault when writing keymap from file

[Frantisek Rysanek]

On 20 Jan 2020 at 18:47, camden lindsay wrote:

> Hello-
> I had a working ir-keytable script that stopped working the other day.
> Investigation led to finding that ir-keytable was segfaulting whenever
> trying to write a keymap from a file.
> 
> [kodiuser@kodiarch ~]$ uname -a
> Linux kodiarch 5.4.13-arch1-1 #1 SMP PREEMPT Fri, 17 Jan 2020 23:09:54
> +0000 x86_64 GNU/Linux
> [kodiuser@kodiarch ~]$
> 
> [kodiuser@kodiarch ~]$ ir-keytable -V
> IR keytable control version 1.18.0
> [kodiuser@kodiarch ~]$
> 
> Here's an example of grabbing an existing keytable entry, putting it
> in a file, but showing that after clearing and trying to load that
> file the segfault.  Segfault also occurs if not clearing first.
> 
> [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -r | grep KEY_DOWN
> Enabled kernel protocols: lirc nec
> scancode 0x800f041f = KEY_DOWN (0x6c)
> [kodiuser@kodiarch ir-keytable]$ cat /etc/ir-keytable/keymap.txt
> scancode 0x800f041f = KEY_DOWN (0x6c)
> [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -c
> Old keytable cleared
> [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -w /etc/ir-keytable/keymap.txt
> Segmentation fault
> [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -r | grep KEY_DOWN
> Enabled kernel protocols: lirc nec
> [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -r
> Enabled kernel protocols: lirc nec
> [kodiuser@kodiarch ir-keytable]$
> 
> 
> 
> And this shows that the segfault still occurs even if i don't clear
> the keytable first (but of course the existing contents of the table
> still exist)
> [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> Enabled kernel protocols: lirc nec
> scancode 0x800f041f = KEY_DOWN (0x6c)
> [kodiuser@kodiarch ~]$ cat /etc/ir-keytable/keymap.txt
> scancode 0x800f041f = KEY_DOWN (0x6c)
> [kodiuser@kodiarch ~]$ sudo ir-keytable -w /etc/ir-keytable/keymap.txt
> Segmentation fault
> [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> Enabled kernel protocols: lirc nec
> scancode 0x800f041f = KEY_DOWN (0x6c)
> [kodiuser@kodiarch ~]$
> 
> 
> Here is the example syslog output of the segfault:
> Jan 20 18:15:33 kodiarch kernel: ir-keytable[817]: segfault at 0 ip
> 00007f1a958436f5 sp 00007ffe039a5aa8 error 4 in
> libc-2.30.so[7f1a95707000+14d000]
> Jan 20 18:15:33 kodiarch kernel: Code: 00 00 0f 1f 00 31 c0 c5 f8 77
> c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 89 f9 48 89 fa c5 f9 ef
> c0 83 e1 3f 83 f9 20 77 2b <c5> fd 74 0f c5 fd d7 c1 85 c0 0f 85 eb 00
> 00 00 48 83 c7 20 83 e1
> Jan 20 18:15:33 kodiarch systemd[1]: Started Process Core Dump (PID 818/UID 0).
> Jan 20 18:15:34 kodiarch systemd-coredump[819]: Process 817
> (ir-keytable) of user 0 dumped core.
> 
>                                                 Stack trace of thread 817:
>                                                 #0  0x00007f1a958436f5
> __strlen_avx2 (libc.so.6 + 0x1616f5)
>                                                 #1  0x00007f1a95770be3
> __strdup (libc.so.6 + 0x8ebe3)
>                                                 #2  0x0000563150aa43b7
> n/a (ir-keytable + 0x83b7)
>                                                 #3  0x0000563150aa44c6
> n/a (ir-keytable + 0x84c6)
>                                                 #4  0x00007f1a957edfc0
> argp_parse (libc.so.6 + 0x10bfc0)
>                                                 #5  0x0000563150aa2099
> n/a (ir-keytable + 0x6099)
>                                                 #6  0x00007f1a95709153
> __libc_start_main (libc.so.6 + 0x27153)
>                                                 #7  0x0000563150aa325e
> n/a (ir-keytable + 0x725e)
> Jan 20 18:15:34 kodiarch systemd[1]: systemd-coredump@3-818-0.service:
> Succeeded.

Initially I was wondering if the format of the keytable file was 
correct for your version of ir-keytable (because I believe I've seen 
two different formats in the recent past) but looking at that stack 
trace, currently I'm wondering about two possible theories:

a) either ir-keytable is using strlen (by calling strdup(), actually) 
in an unsafe way, trying to find a null character in a buffer that is 
not null-terminated for some reason

b) or, avx2 sounds like something rather hot off the press. Sounds 
like the libc contains several versions of the strlen function and 
patches the fastest flavour in at runtime, depending on the hardware 
it finds itself running on. But... is this avx2-based strlen() 
variant the culprit here? Who knows... I am assuming that your CPU is 
capable of avx2 = that the CPU feature detection in libc works 
fine... And I'm assuming that strlen() is so ubiquitous throughout 
the user space, that it's hardly the culprit here. Your distro 
probably wouldn't be able to boot if this was the problem.

Unfortunately I have no hard data :-) just guesses.

Also, at a more superficial level, what distro is this? Arch? I don't 
know Arch, I'm conservative, most of my machines run Debian oldstable 
:-)  You seem to be using a pretty new kernel, that's why I'm asking. 
Not that the kernel would seem to be implicated in this misbehavior.
But if you're using some bleeding-edge "rolling release", that might 
be a part of the explanation (= perhaps not as thoroughly tested as 
my favourite late-adopter relics).

Frank

Re: ir-keytable segfault when writing keymap from file

[Sean Young]

Hello,

On Mon, Jan 20, 2020 at 06:47:17PM -0800, camden lindsay wrote:
> Hello-
> I had a working ir-keytable script that stopped working the other day.
> Investigation led to finding that ir-keytable was segfaulting whenever
> trying to write a keymap from a file.
> 
> [kodiuser@kodiarch ~]$ uname -a
> Linux kodiarch 5.4.13-arch1-1 #1 SMP PREEMPT Fri, 17 Jan 2020 23:09:54
> +0000 x86_64 GNU/Linux
> [kodiuser@kodiarch ~]$
> 
> [kodiuser@kodiarch ~]$ ir-keytable -V
> IR keytable control version 1.18.0
> [kodiuser@kodiarch ~]$
> 
> Here's an example of grabbing an existing keytable entry, putting it
> in a file, but showing that after clearing and trying to load that
> file the segfault.  Segfault also occurs if not clearing first.
> 
> [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -r | grep KEY_DOWN
> Enabled kernel protocols: lirc nec
> scancode 0x800f041f = KEY_DOWN (0x6c)
> [kodiuser@kodiarch ir-keytable]$ cat /etc/ir-keytable/keymap.txt
> scancode 0x800f041f = KEY_DOWN (0x6c)
> [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -c
> Old keytable cleared
> [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -w /etc/ir-keytable/keymap.txt
> Segmentation fault
> [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -r | grep KEY_DOWN
> Enabled kernel protocols: lirc nec
> [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -r
> Enabled kernel protocols: lirc nec
> [kodiuser@kodiarch ir-keytable]$
> 
> 
> 
> And this shows that the segfault still occurs even if i don't clear
> the keytable first (but of course the existing contents of the table
> still exist)
> [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> Enabled kernel protocols: lirc nec
> scancode 0x800f041f = KEY_DOWN (0x6c)
> [kodiuser@kodiarch ~]$ cat /etc/ir-keytable/keymap.txt
> scancode 0x800f041f = KEY_DOWN (0x6c)
> [kodiuser@kodiarch ~]$ sudo ir-keytable -w /etc/ir-keytable/keymap.txt
> Segmentation fault
> [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> Enabled kernel protocols: lirc nec
> scancode 0x800f041f = KEY_DOWN (0x6c)
> [kodiuser@kodiarch ~]$

I suspect ir-keytable is segfaulting in the code that reads the file; would
you be able to share the keymap.txt file please? That way I can see if I
can reproduce the problem.

Parsing of the keymap is done in C which can be prone to these sorts of
problems.

> Here is the example syslog output of the segfault:
> Jan 20 18:15:33 kodiarch kernel: ir-keytable[817]: segfault at 0 ip
> 00007f1a958436f5 sp 00007ffe039a5aa8 error 4 in
> libc-2.30.so[7f1a95707000+14d000]
> Jan 20 18:15:33 kodiarch kernel: Code: 00 00 0f 1f 00 31 c0 c5 f8 77
> c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 89 f9 48 89 fa c5 f9 ef
> c0 83 e1 3f 83 f9 20 77 2b <c5> fd 74 0f c5 fd d7 c1 85 c0 0f 85 eb 00
> 00 00 48 83 c7 20 83 e1
> Jan 20 18:15:33 kodiarch systemd[1]: Started Process Core Dump (PID 818/UID 0).
> Jan 20 18:15:34 kodiarch systemd-coredump[819]: Process 817
> (ir-keytable) of user 0 dumped core.
> 
>                                                 Stack trace of thread 817:
>                                                 #0  0x00007f1a958436f5
> __strlen_avx2 (libc.so.6 + 0x1616f5)
>                                                 #1  0x00007f1a95770be3
> __strdup (libc.so.6 + 0x8ebe3)
>                                                 #2  0x0000563150aa43b7
> n/a (ir-keytable + 0x83b7)
>                                                 #3  0x0000563150aa44c6
> n/a (ir-keytable + 0x84c6)
>                                                 #4  0x00007f1a957edfc0
> argp_parse (libc.so.6 + 0x10bfc0)
>                                                 #5  0x0000563150aa2099
> n/a (ir-keytable + 0x6099)
>                                                 #6  0x00007f1a95709153
> __libc_start_main (libc.so.6 + 0x27153)
>                                                 #7  0x0000563150aa325e
> n/a (ir-keytable + 0x725e)
> Jan 20 18:15:34 kodiarch systemd[1]: systemd-coredump@3-818-0.service:
> Succeeded.

This would have to be done a in debug build.

Thanks
Sean

Re: ir-keytable segfault when writing keymap from file

[camden lindsay]

On Tue, Jan 21, 2020 at 12:33 AM Frantisek Rysanek
<Frantisek.Rysanek@post.cz> wrote:

> Initially I was wondering if the format of the keytable file was
> correct for your version of ir-keytable (because I believe I've seen
> two different formats in the recent past) but looking at that stack
> trace, currently I'm wondering about two possible theories:
>
> a) either ir-keytable is using strlen (by calling strdup(), actually)
> in an unsafe way, trying to find a null character in a buffer that is
> not null-terminated for some reason
>
> b) or, avx2 sounds like something rather hot off the press. Sounds
> like the libc contains several versions of the strlen function and
> patches the fastest flavour in at runtime, depending on the hardware
> it finds itself running on. But... is this avx2-based strlen()
> variant the culprit here? Who knows... I am assuming that your CPU is
> capable of avx2 = that the CPU feature detection in libc works
> fine... And I'm assuming that strlen() is so ubiquitous throughout
> the user space, that it's hardly the culprit here. Your distro
> probably wouldn't be able to boot if this was the problem.
>
> Unfortunately I have no hard data :-) just guesses.
>
> Also, at a more superficial level, what distro is this? Arch? I don't
> know Arch, I'm conservative, most of my machines run Debian oldstable
> :-)  You seem to be using a pretty new kernel, that's why I'm asking.
> Not that the kernel would seem to be implicated in this misbehavior.
> But if you're using some bleeding-edge "rolling release", that might
> be a part of the explanation (= perhaps not as thoroughly tested as
> my favourite late-adopter relics).
>
> Frank
>

Hello, Frank-

CPU is
[kodiuser@kodiarch ~]$ grep "model name" /proc/cpuinfo | head -1
model name    : Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz
[kodiuser@kodiarch ~]$

/proc/cpuinfo shows cpu is capable of it, i believe
[kodiuser@kodiarch ~]$ grep flags /proc/cpuinfo | head -1 | grep avx2
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid
sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx
f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single
pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust
bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap
clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln
pts hwp hwp_notify hwp_act_window hwp_epp
[kodiuser@kodiarch ~]$

Any pointers on how to check to see if the feature detection for that
is working correctly in libc?

Yes, this is Arch.  Problem was first noticed while running a slightly
older kernel, but don't know if that is the initial cause.  Did a full
upgrade before posting this bug (where it picked up the current
kernel).

Thank you for the input :)

c

Re: ir-keytable segfault when writing keymap from file

[camden lindsay]

[-- Attachment #1: Type: text/plain, Size: 4583 bytes --]

On Tue, Jan 21, 2020 at 1:20 AM Sean Young <sean@mess.org> wrote:
>
> Hello,
>
> On Mon, Jan 20, 2020 at 06:47:17PM -0800, camden lindsay wrote:
> > Hello-
> > I had a working ir-keytable script that stopped working the other day.
> > Investigation led to finding that ir-keytable was segfaulting whenever
> > trying to write a keymap from a file.
> >
> > [kodiuser@kodiarch ~]$ uname -a
> > Linux kodiarch 5.4.13-arch1-1 #1 SMP PREEMPT Fri, 17 Jan 2020 23:09:54
> > +0000 x86_64 GNU/Linux
> > [kodiuser@kodiarch ~]$
> >
> > [kodiuser@kodiarch ~]$ ir-keytable -V
> > IR keytable control version 1.18.0
> > [kodiuser@kodiarch ~]$
> >
> > Here's an example of grabbing an existing keytable entry, putting it
> > in a file, but showing that after clearing and trying to load that
> > file the segfault.  Segfault also occurs if not clearing first.
> >
> > [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -r | grep KEY_DOWN
> > Enabled kernel protocols: lirc nec
> > scancode 0x800f041f = KEY_DOWN (0x6c)
> > [kodiuser@kodiarch ir-keytable]$ cat /etc/ir-keytable/keymap.txt
> > scancode 0x800f041f = KEY_DOWN (0x6c)
> > [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -c
> > Old keytable cleared
> > [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -w /etc/ir-keytable/keymap.txt
> > Segmentation fault
> > [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -r | grep KEY_DOWN
> > Enabled kernel protocols: lirc nec
> > [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -r
> > Enabled kernel protocols: lirc nec
> > [kodiuser@kodiarch ir-keytable]$
> >
> >
> >
> > And this shows that the segfault still occurs even if i don't clear
> > the keytable first (but of course the existing contents of the table
> > still exist)
> > [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> > Enabled kernel protocols: lirc nec
> > scancode 0x800f041f = KEY_DOWN (0x6c)
> > [kodiuser@kodiarch ~]$ cat /etc/ir-keytable/keymap.txt
> > scancode 0x800f041f = KEY_DOWN (0x6c)
> > [kodiuser@kodiarch ~]$ sudo ir-keytable -w /etc/ir-keytable/keymap.txt
> > Segmentation fault
> > [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> > Enabled kernel protocols: lirc nec
> > scancode 0x800f041f = KEY_DOWN (0x6c)
> > [kodiuser@kodiarch ~]$
>
> I suspect ir-keytable is segfaulting in the code that reads the file; would
> you be able to share the keymap.txt file please? That way I can see if I
> can reproduce the problem.
>
> Parsing of the keymap is done in C which can be prone to these sorts of
> problems.
>
> > Here is the example syslog output of the segfault:
> > Jan 20 18:15:33 kodiarch kernel: ir-keytable[817]: segfault at 0 ip
> > 00007f1a958436f5 sp 00007ffe039a5aa8 error 4 in
> > libc-2.30.so[7f1a95707000+14d000]
> > Jan 20 18:15:33 kodiarch kernel: Code: 00 00 0f 1f 00 31 c0 c5 f8 77
> > c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 89 f9 48 89 fa c5 f9 ef
> > c0 83 e1 3f 83 f9 20 77 2b <c5> fd 74 0f c5 fd d7 c1 85 c0 0f 85 eb 00
> > 00 00 48 83 c7 20 83 e1
> > Jan 20 18:15:33 kodiarch systemd[1]: Started Process Core Dump (PID 818/UID 0).
> > Jan 20 18:15:34 kodiarch systemd-coredump[819]: Process 817
> > (ir-keytable) of user 0 dumped core.
> >
> >                                                 Stack trace of thread 817:
> >                                                 #0  0x00007f1a958436f5
> > __strlen_avx2 (libc.so.6 + 0x1616f5)
> >                                                 #1  0x00007f1a95770be3
> > __strdup (libc.so.6 + 0x8ebe3)
> >                                                 #2  0x0000563150aa43b7
> > n/a (ir-keytable + 0x83b7)
> >                                                 #3  0x0000563150aa44c6
> > n/a (ir-keytable + 0x84c6)
> >                                                 #4  0x00007f1a957edfc0
> > argp_parse (libc.so.6 + 0x10bfc0)
> >                                                 #5  0x0000563150aa2099
> > n/a (ir-keytable + 0x6099)
> >                                                 #6  0x00007f1a95709153
> > __libc_start_main (libc.so.6 + 0x27153)
> >                                                 #7  0x0000563150aa325e
> > n/a (ir-keytable + 0x725e)
> > Jan 20 18:15:34 kodiarch systemd[1]: systemd-coredump@3-818-0.service:
> > Succeeded.
>
> This would have to be done a in debug build.
>
> Thanks
> Sean



Hello, Sean-
I'd be happy to share the files, I greatly appreciate you looking into
this.  I'll try attaching them to this email.
There are two files- one was my original file, the other was my
attempt to make the most basic file based on a single line of
ir-keytable -r.

many thanks
Camden

[-- Attachment #2: keymap.txt --]
[-- Type: text/plain, Size: 38 bytes --]

scancode 0x800f041f = KEY_DOWN (0x6c)

[-- Attachment #3: keymap.txt.wasworking --]
[-- Type: application/octet-stream, Size: 2600 bytes --]

scancode 0x800f0400 = KEY_NUMERIC_0 (0x200)
scancode 0x800f0401 = KEY_NUMERIC_1 (0x201)
scancode 0x800f0402 = KEY_NUMERIC_2 (0x202)
scancode 0x800f0403 = KEY_NUMERIC_3 (0x203)
scancode 0x800f0404 = KEY_NUMERIC_4 (0x204)
scancode 0x800f0405 = KEY_NUMERIC_5 (0x205)
scancode 0x800f0406 = KEY_NUMERIC_6 (0x206)
scancode 0x800f0407 = KEY_NUMERIC_7 (0x207)
scancode 0x800f0408 = KEY_NUMERIC_8 (0x208)
scancode 0x800f0409 = KEY_NUMERIC_9 (0x209)
scancode 0x800f040a = KEY_DELETE (0x6f)
scancode 0x847490 = KEY_ENTER (0x1c)
scancode 0x800f040c = KEY_SLEEP (0x8e)
scancode 0x800f040d = KEY_MEDIA (0xe2)
scancode 0x800f040e = KEY_MUTE (0x71)
scancode 0x800f040f = KEY_INFO (0x166)
scancode 0x800f0410 = KEY_VOLUMEUP (0x73)
scancode 0x800f0411 = KEY_VOLUMEDOWN (0x72)
scancode 0x800f0412 = KEY_CHANNELUP (0x192)
scancode 0x800f0413 = KEY_CHANNELDOWN (0x193)
scancode 0x84748a = KEY_FASTFORWARD (0xd0)
scancode 0x84747e = KEY_REWIND (0xa8)
scancode 0x84747f = KEY_PLAY (0xcf)
scancode 0x847499 = KEY_RECORD (0xa7)
scancode 0x84748c = KEY_PAUSE (0x77)
scancode 0x84747c = KEY_X (0x2d) 
scancode 0x84747d = KEY_NEXTSONG (0x197)
scancode 0x84747b = KEY_PREVIOUSSONG (0x19c)
scancode 0x800f041c = KEY_NUMERIC_POUND (0x20b)
scancode 0x800f041d = KEY_NUMERIC_STAR (0x20a)
scancode 0x84748e = KEY_UP (0x67)
scancode 0x847492 = KEY_DOWN (0x6c)
scancode 0x84748f = KEY_LEFT (0x69)
scancode 0x847491 = KEY_RIGHT (0x6a)
scancode 0x800f0424 = KEY_DVD (0x185)
scancode 0x800f0425 = KEY_TUNER (0x182)
scancode 0x800f0426 = KEY_EPG (0x16d)
scancode 0x800f0427 = KEY_ZOOM (0x174)
scancode 0x800f0432 = KEY_MODE (0x175)
scancode 0x800f0433 = KEY_PRESENTATION (0x1a9)
scancode 0x800f0434 = KEY_EJECTCD (0xa1)
scancode 0x800f043a = KEY_BRIGHTNESSUP (0xe1)
scancode 0x800f0446 = KEY_TV (0x179)
scancode 0x800f0447 = KEY_AUDIO (0x188)
scancode 0x800f0448 = KEY_PVR (0x16e)
scancode 0x800f0449 = KEY_CAMERA (0xd4)
scancode 0x800f044a = KEY_VIDEO (0x189)
scancode 0x800f044c = KEY_LANGUAGE (0x170)
scancode 0x800f044d = KEY_TITLE (0x171)
scancode 0x800f044e = KEY_PRINT (0xd2)
scancode 0x800f0450 = KEY_RADIO (0x181)
scancode 0x800f045a = KEY_SUBTITLE (0x172)
scancode 0x800f045b = KEY_RED (0x18e)
scancode 0x800f045c = KEY_GREEN (0x18f)
scancode 0x800f045d = KEY_YELLOW (0x190)
scancode 0x800f045e = KEY_BLUE (0x191)
scancode 0x800f0465 = KEY_POWER2 (0x164)
scancode 0x800f046e = KEY_PLAYPAUSE (0xa4)
scancode 0x800f046f = KEY_PLAYER (0x183)
scancode 0x800f0480 = KEY_BRIGHTNESSDOWN (0xe0)
scancode 0x800f0481 = KEY_PLAYPAUSE (0xa4)
scancode 0x847497 = KEY_BACKSPACE (0x0e)
scancode 0x847496 = KEY_MENU
scancode 0x80d864 = KEY_POWER

Re: ir-keytable segfault when writing keymap from file

[Sean Young]

Hi Camden,

On Tue, Jan 21, 2020 at 07:57:35AM -0800, camden lindsay wrote:
> On Tue, Jan 21, 2020 at 1:20 AM Sean Young <sean@mess.org> wrote:
> > On Mon, Jan 20, 2020 at 06:47:17PM -0800, camden lindsay wrote:
> > > And this shows that the segfault still occurs even if i don't clear
> > > the keytable first (but of course the existing contents of the table
> > > still exist)
> > > [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> > > Enabled kernel protocols: lirc nec
> > > scancode 0x800f041f = KEY_DOWN (0x6c)
> > > [kodiuser@kodiarch ~]$ cat /etc/ir-keytable/keymap.txt
> > > scancode 0x800f041f = KEY_DOWN (0x6c)
> > > [kodiuser@kodiarch ~]$ sudo ir-keytable -w /etc/ir-keytable/keymap.txt
> > > Segmentation fault
> > > [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> > > Enabled kernel protocols: lirc nec
> > > scancode 0x800f041f = KEY_DOWN (0x6c)
> > > [kodiuser@kodiarch ~]$
> >
> > I suspect ir-keytable is segfaulting in the code that reads the file; would
> > you be able to share the keymap.txt file please? That way I can see if I
> > can reproduce the problem.
> >
> > Parsing of the keymap is done in C which can be prone to these sorts of
> > problems.
> >
> > > Here is the example syslog output of the segfault:
> > > Jan 20 18:15:33 kodiarch kernel: ir-keytable[817]: segfault at 0 ip
> > > 00007f1a958436f5 sp 00007ffe039a5aa8 error 4 in
> > > libc-2.30.so[7f1a95707000+14d000]
> > > Jan 20 18:15:33 kodiarch kernel: Code: 00 00 0f 1f 00 31 c0 c5 f8 77
> > > c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 89 f9 48 89 fa c5 f9 ef
> > > c0 83 e1 3f 83 f9 20 77 2b <c5> fd 74 0f c5 fd d7 c1 85 c0 0f 85 eb 00
> > > 00 00 48 83 c7 20 83 e1
> > > Jan 20 18:15:33 kodiarch systemd[1]: Started Process Core Dump (PID 818/UID 0).
> > > Jan 20 18:15:34 kodiarch systemd-coredump[819]: Process 817
> > > (ir-keytable) of user 0 dumped core.
> > >
> > >                                                 Stack trace of thread 817:
> > >                                                 #0  0x00007f1a958436f5
> > > __strlen_avx2 (libc.so.6 + 0x1616f5)
> > >                                                 #1  0x00007f1a95770be3
> > > __strdup (libc.so.6 + 0x8ebe3)
> > >                                                 #2  0x0000563150aa43b7
> > > n/a (ir-keytable + 0x83b7)
> > >                                                 #3  0x0000563150aa44c6
> > > n/a (ir-keytable + 0x84c6)
> > >                                                 #4  0x00007f1a957edfc0
> > > argp_parse (libc.so.6 + 0x10bfc0)
> > >                                                 #5  0x0000563150aa2099
> > > n/a (ir-keytable + 0x6099)
> > >                                                 #6  0x00007f1a95709153
> > > __libc_start_main (libc.so.6 + 0x27153)
> > >                                                 #7  0x0000563150aa325e
> > > n/a (ir-keytable + 0x725e)
> > > Jan 20 18:15:34 kodiarch systemd[1]: systemd-coredump@3-818-0.service:
> > > Succeeded.
> >
> > This would have to be done a in debug build.
> >
> > Thanks
> > Sean
> 
> 
> 
> Hello, Sean-
> I'd be happy to share the files, I greatly appreciate you looking into
> this.  I'll try attaching them to this email.
> There are two files- one was my original file, the other was my
> attempt to make the most basic file based on a single line of
> ir-keytable -r.

Ok, ir-keytable segfaults because there is no protocol specified. You'll
need something like "# table foobar, type: RC6-MCE" as a first line. Of
course, ir-keytable should not segfault if this is missing. I'll write
a fix for this.

Secondly, there is a new format for rc keymaps written in toml. A new format
was needed to support BPF keymaps and keymaps with multiple protocols
are better supported. See man rc_keymap

It looks like the keymap you are trying to load contains two different
protocols, rc6-mce and something else (nec-x?). Please let me know what
you are trying to do so I can help write a toml keymap.


Sean

Re: ir-keytable segfault when writing keymap from file

[camden lindsay]

Sean-

Ah, it is possible that the keymap has multiple protocols.  I'm using
an A/V receiver remote that has had other remote information
programmed into it so it can control my sony tv as well as kodi, and
in controlling kodi i did some hackish stuff i'm sure (don't really
remember what).

I don't have any idea how to identify what lines in the keymap are nec
and what are RC6-MCU.. let alone what variant the nec protocol is
using. Suggestions for finding this info?
Thank you for finding the problem- indeed, once adding the following
to the top of the keyfile, no more segfault- and the keymap is written
(to ...kernel?) from file. :)
[kodiuser@kodiarch ir-keytable]$ head -1 /etc/ir-keytable/keymap.txt.wasworking
# table foobar, type: RC6-MCE
[kodiuser@kodiarch ir-keytable]$

However, maybe something weird with my distribution-  it doesn't seem
to find the RC6-MCE bpf protocol (i've also tried lower case, since
the man page has rc6-mce in lower case)
[kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -w
/etc/ir-keytable/keymap.txt.wasworking
Read foobar table
Wrote 64 keycode(s) to driver
Protocols changed to
Can't find RC6-MCE bpf protocol in /etc/rc_keymaps/protocols or
/usr/lib/udev/rc_keymaps/protocols
[kodiuser@kodiarch ir-keytable]$

the file 'protocols' doesn't seem to exist in either of those
locations on my distribution.

Thank you for the pointer to the man page that includes the new format
of keymap.  Seems the best path forward is to identify the protocols
of scancodes i have, then  write a new keymap in a new format with
both protocols in it.

Your help is greatly appreciated-
Camden

On Tue, Jan 21, 2020 at 8:49 AM Sean Young <sean@mess.org> wrote:
>
> Hi Camden,
>
> On Tue, Jan 21, 2020 at 07:57:35AM -0800, camden lindsay wrote:
> > On Tue, Jan 21, 2020 at 1:20 AM Sean Young <sean@mess.org> wrote:
> > > On Mon, Jan 20, 2020 at 06:47:17PM -0800, camden lindsay wrote:
> > > > And this shows that the segfault still occurs even if i don't clear
> > > > the keytable first (but of course the existing contents of the table
> > > > still exist)
> > > > [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> > > > Enabled kernel protocols: lirc nec
> > > > scancode 0x800f041f = KEY_DOWN (0x6c)
> > > > [kodiuser@kodiarch ~]$ cat /etc/ir-keytable/keymap.txt
> > > > scancode 0x800f041f = KEY_DOWN (0x6c)
> > > > [kodiuser@kodiarch ~]$ sudo ir-keytable -w /etc/ir-keytable/keymap.txt
> > > > Segmentation fault
> > > > [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> > > > Enabled kernel protocols: lirc nec
> > > > scancode 0x800f041f = KEY_DOWN (0x6c)
> > > > [kodiuser@kodiarch ~]$
> > >
> > > I suspect ir-keytable is segfaulting in the code that reads the file; would
> > > you be able to share the keymap.txt file please? That way I can see if I
> > > can reproduce the problem.
> > >
> > > Parsing of the keymap is done in C which can be prone to these sorts of
> > > problems.
> > >
> > > > Here is the example syslog output of the segfault:
> > > > Jan 20 18:15:33 kodiarch kernel: ir-keytable[817]: segfault at 0 ip
> > > > 00007f1a958436f5 sp 00007ffe039a5aa8 error 4 in
> > > > libc-2.30.so[7f1a95707000+14d000]
> > > > Jan 20 18:15:33 kodiarch kernel: Code: 00 00 0f 1f 00 31 c0 c5 f8 77
> > > > c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 89 f9 48 89 fa c5 f9 ef
> > > > c0 83 e1 3f 83 f9 20 77 2b <c5> fd 74 0f c5 fd d7 c1 85 c0 0f 85 eb 00
> > > > 00 00 48 83 c7 20 83 e1
> > > > Jan 20 18:15:33 kodiarch systemd[1]: Started Process Core Dump (PID 818/UID 0).
> > > > Jan 20 18:15:34 kodiarch systemd-coredump[819]: Process 817
> > > > (ir-keytable) of user 0 dumped core.
> > > >
> > > >                                                 Stack trace of thread 817:
> > > >                                                 #0  0x00007f1a958436f5
> > > > __strlen_avx2 (libc.so.6 + 0x1616f5)
> > > >                                                 #1  0x00007f1a95770be3
> > > > __strdup (libc.so.6 + 0x8ebe3)
> > > >                                                 #2  0x0000563150aa43b7
> > > > n/a (ir-keytable + 0x83b7)
> > > >                                                 #3  0x0000563150aa44c6
> > > > n/a (ir-keytable + 0x84c6)
> > > >                                                 #4  0x00007f1a957edfc0
> > > > argp_parse (libc.so.6 + 0x10bfc0)
> > > >                                                 #5  0x0000563150aa2099
> > > > n/a (ir-keytable + 0x6099)
> > > >                                                 #6  0x00007f1a95709153
> > > > __libc_start_main (libc.so.6 + 0x27153)
> > > >                                                 #7  0x0000563150aa325e
> > > > n/a (ir-keytable + 0x725e)
> > > > Jan 20 18:15:34 kodiarch systemd[1]: systemd-coredump@3-818-0.service:
> > > > Succeeded.
> > >
> > > This would have to be done a in debug build.
> > >
> > > Thanks
> > > Sean
> >
> >
> >
> > Hello, Sean-
> > I'd be happy to share the files, I greatly appreciate you looking into
> > this.  I'll try attaching them to this email.
> > There are two files- one was my original file, the other was my
> > attempt to make the most basic file based on a single line of
> > ir-keytable -r.
>
> Ok, ir-keytable segfaults because there is no protocol specified. You'll
> need something like "# table foobar, type: RC6-MCE" as a first line. Of
> course, ir-keytable should not segfault if this is missing. I'll write
> a fix for this.
>
> Secondly, there is a new format for rc keymaps written in toml. A new format
> was needed to support BPF keymaps and keymaps with multiple protocols
> are better supported. See man rc_keymap
>
> It looks like the keymap you are trying to load contains two different
> protocols, rc6-mce and something else (nec-x?). Please let me know what
> you are trying to do so I can help write a toml keymap.
>
>
> Sean
>

Re: ir-keytable segfault when writing keymap from file

[Sean Young]

Hi Camden,

On Tue, Jan 21, 2020 at 11:18:30AM -0800, camden lindsay wrote:
> Sean-
> 
> Ah, it is possible that the keymap has multiple protocols.  I'm using
> an A/V receiver remote that has had other remote information
> programmed into it so it can control my sony tv as well as kodi, and
> in controlling kodi i did some hackish stuff i'm sure (don't really
> remember what).
> 
> I don't have any idea how to identify what lines in the keymap are nec
> and what are RC6-MCU.. let alone what variant the nec protocol is
> using. Suggestions for finding this info?

You can figure out what the remote is sending using the command:
ir-keytable -p all -t

Then test your remote. Look for "lirc protocol" in the output.

> Thank you for finding the problem- indeed, once adding the following
> to the top of the keyfile, no more segfault- and the keymap is written
> (to ...kernel?) from file. :)
> [kodiuser@kodiarch ir-keytable]$ head -1 /etc/ir-keytable/keymap.txt.wasworking
> # table foobar, type: RC6-MCE
> [kodiuser@kodiarch ir-keytable]$
> 
> However, maybe something weird with my distribution-  it doesn't seem
> to find the RC6-MCE bpf protocol (i've also tried lower case, since
> the man page has rc6-mce in lower case)
> [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -w
> /etc/ir-keytable/keymap.txt.wasworking
> Read foobar table
> Wrote 64 keycode(s) to driver
> Protocols changed to
> Can't find RC6-MCE bpf protocol in /etc/rc_keymaps/protocols or
> /usr/lib/udev/rc_keymaps/protocols

Ah, my bad. That should be simply rc6, not rc6-mce.

> [kodiuser@kodiarch ir-keytable]$
> 
> the file 'protocols' doesn't seem to exist in either of those
> locations on my distribution.

That's odd. Looks like arch doesn't include them. Also, the kernel is built
without IR BPF decoding (CONFIG_BPF_LIRC_MODE2).

> Thank you for the pointer to the man page that includes the new format
> of keymap.  Seems the best path forward is to identify the protocols
> of scancodes i have, then  write a new keymap in a new format with
> both protocols in it.

Please let us know how you get on.

Sean

> 
> Your help is greatly appreciated-
> Camden
> 
> On Tue, Jan 21, 2020 at 8:49 AM Sean Young <sean@mess.org> wrote:
> >
> > Hi Camden,
> >
> > On Tue, Jan 21, 2020 at 07:57:35AM -0800, camden lindsay wrote:
> > > On Tue, Jan 21, 2020 at 1:20 AM Sean Young <sean@mess.org> wrote:
> > > > On Mon, Jan 20, 2020 at 06:47:17PM -0800, camden lindsay wrote:
> > > > > And this shows that the segfault still occurs even if i don't clear
> > > > > the keytable first (but of course the existing contents of the table
> > > > > still exist)
> > > > > [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> > > > > Enabled kernel protocols: lirc nec
> > > > > scancode 0x800f041f = KEY_DOWN (0x6c)
> > > > > [kodiuser@kodiarch ~]$ cat /etc/ir-keytable/keymap.txt
> > > > > scancode 0x800f041f = KEY_DOWN (0x6c)
> > > > > [kodiuser@kodiarch ~]$ sudo ir-keytable -w /etc/ir-keytable/keymap.txt
> > > > > Segmentation fault
> > > > > [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> > > > > Enabled kernel protocols: lirc nec
> > > > > scancode 0x800f041f = KEY_DOWN (0x6c)
> > > > > [kodiuser@kodiarch ~]$
> > > >
> > > > I suspect ir-keytable is segfaulting in the code that reads the file; would
> > > > you be able to share the keymap.txt file please? That way I can see if I
> > > > can reproduce the problem.
> > > >
> > > > Parsing of the keymap is done in C which can be prone to these sorts of
> > > > problems.
> > > >
> > > > > Here is the example syslog output of the segfault:
> > > > > Jan 20 18:15:33 kodiarch kernel: ir-keytable[817]: segfault at 0 ip
> > > > > 00007f1a958436f5 sp 00007ffe039a5aa8 error 4 in
> > > > > libc-2.30.so[7f1a95707000+14d000]
> > > > > Jan 20 18:15:33 kodiarch kernel: Code: 00 00 0f 1f 00 31 c0 c5 f8 77
> > > > > c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 89 f9 48 89 fa c5 f9 ef
> > > > > c0 83 e1 3f 83 f9 20 77 2b <c5> fd 74 0f c5 fd d7 c1 85 c0 0f 85 eb 00
> > > > > 00 00 48 83 c7 20 83 e1
> > > > > Jan 20 18:15:33 kodiarch systemd[1]: Started Process Core Dump (PID 818/UID 0).
> > > > > Jan 20 18:15:34 kodiarch systemd-coredump[819]: Process 817
> > > > > (ir-keytable) of user 0 dumped core.
> > > > >
> > > > >                                                 Stack trace of thread 817:
> > > > >                                                 #0  0x00007f1a958436f5
> > > > > __strlen_avx2 (libc.so.6 + 0x1616f5)
> > > > >                                                 #1  0x00007f1a95770be3
> > > > > __strdup (libc.so.6 + 0x8ebe3)
> > > > >                                                 #2  0x0000563150aa43b7
> > > > > n/a (ir-keytable + 0x83b7)
> > > > >                                                 #3  0x0000563150aa44c6
> > > > > n/a (ir-keytable + 0x84c6)
> > > > >                                                 #4  0x00007f1a957edfc0
> > > > > argp_parse (libc.so.6 + 0x10bfc0)
> > > > >                                                 #5  0x0000563150aa2099
> > > > > n/a (ir-keytable + 0x6099)
> > > > >                                                 #6  0x00007f1a95709153
> > > > > __libc_start_main (libc.so.6 + 0x27153)
> > > > >                                                 #7  0x0000563150aa325e
> > > > > n/a (ir-keytable + 0x725e)
> > > > > Jan 20 18:15:34 kodiarch systemd[1]: systemd-coredump@3-818-0.service:
> > > > > Succeeded.
> > > >
> > > > This would have to be done a in debug build.
> > > >
> > > > Thanks
> > > > Sean
> > >
> > >
> > >
> > > Hello, Sean-
> > > I'd be happy to share the files, I greatly appreciate you looking into
> > > this.  I'll try attaching them to this email.
> > > There are two files- one was my original file, the other was my
> > > attempt to make the most basic file based on a single line of
> > > ir-keytable -r.
> >
> > Ok, ir-keytable segfaults because there is no protocol specified. You'll
> > need something like "# table foobar, type: RC6-MCE" as a first line. Of
> > course, ir-keytable should not segfault if this is missing. I'll write
> > a fix for this.
> >
> > Secondly, there is a new format for rc keymaps written in toml. A new format
> > was needed to support BPF keymaps and keymaps with multiple protocols
> > are better supported. See man rc_keymap
> >
> > It looks like the keymap you are trying to load contains two different
> > protocols, rc6-mce and something else (nec-x?). Please let me know what
> > you are trying to do so I can help write a toml keymap.
> >
> >
> > Sean
> >

Re: ir-keytable segfault when writing keymap from file

[camden lindsay]

Will do.

To do a quick test, i copied the sample config file out of the man
page and tried loading it:
[kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -w /etc/ir-keytable/test.toml
Read iMON Station RSC table
/etc/ir-keytable/test.toml: keycode `KEY_MAX' not recognised, no
mapping for scancode 8392834
Wrote 42 keycode(s) to driver
Protocols changed to nec
Can't find imon_rsc bpf protocol in /etc/rc_keymaps/protocols or
/usr/lib/udev/rc_keymaps/protocols
[kodiuser@kodiarch ir-keytable]$


Looks like perhaps i should file a bug against arch for the missing
protocol file?

I have no idea what IR BPF decoding does.. but the pages i have
skimmed about it (including running across your ramblings and  bpf man
page description) seem to indicate it is more complex that what i'll
need, given i'll be using the kernel IR decoders.  I think? heh.

thank you
Camden

On Tue, Jan 21, 2020 at 11:29 AM Sean Young <sean@mess.org> wrote:
>
> Hi Camden,
>
> On Tue, Jan 21, 2020 at 11:18:30AM -0800, camden lindsay wrote:
> > Sean-
> >
> > Ah, it is possible that the keymap has multiple protocols.  I'm using
> > an A/V receiver remote that has had other remote information
> > programmed into it so it can control my sony tv as well as kodi, and
> > in controlling kodi i did some hackish stuff i'm sure (don't really
> > remember what).
> >
> > I don't have any idea how to identify what lines in the keymap are nec
> > and what are RC6-MCU.. let alone what variant the nec protocol is
> > using. Suggestions for finding this info?
>
> You can figure out what the remote is sending using the command:
> ir-keytable -p all -t
>
> Then test your remote. Look for "lirc protocol" in the output.
>
> > Thank you for finding the problem- indeed, once adding the following
> > to the top of the keyfile, no more segfault- and the keymap is written
> > (to ...kernel?) from file. :)
> > [kodiuser@kodiarch ir-keytable]$ head -1 /etc/ir-keytable/keymap.txt.wasworking
> > # table foobar, type: RC6-MCE
> > [kodiuser@kodiarch ir-keytable]$
> >
> > However, maybe something weird with my distribution-  it doesn't seem
> > to find the RC6-MCE bpf protocol (i've also tried lower case, since
> > the man page has rc6-mce in lower case)
> > [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -w
> > /etc/ir-keytable/keymap.txt.wasworking
> > Read foobar table
> > Wrote 64 keycode(s) to driver
> > Protocols changed to
> > Can't find RC6-MCE bpf protocol in /etc/rc_keymaps/protocols or
> > /usr/lib/udev/rc_keymaps/protocols
>
> Ah, my bad. That should be simply rc6, not rc6-mce.
>
> > [kodiuser@kodiarch ir-keytable]$
> >
> > the file 'protocols' doesn't seem to exist in either of those
> > locations on my distribution.
>
> That's odd. Looks like arch doesn't include them. Also, the kernel is built
> without IR BPF decoding (CONFIG_BPF_LIRC_MODE2).
>
> > Thank you for the pointer to the man page that includes the new format
> > of keymap.  Seems the best path forward is to identify the protocols
> > of scancodes i have, then  write a new keymap in a new format with
> > both protocols in it.
>
> Please let us know how you get on.
>
> Sean
>
> >
> > Your help is greatly appreciated-
> > Camden
> >
> > On Tue, Jan 21, 2020 at 8:49 AM Sean Young <sean@mess.org> wrote:
> > >
> > > Hi Camden,
> > >
> > > On Tue, Jan 21, 2020 at 07:57:35AM -0800, camden lindsay wrote:
> > > > On Tue, Jan 21, 2020 at 1:20 AM Sean Young <sean@mess.org> wrote:
> > > > > On Mon, Jan 20, 2020 at 06:47:17PM -0800, camden lindsay wrote:
> > > > > > And this shows that the segfault still occurs even if i don't clear
> > > > > > the keytable first (but of course the existing contents of the table
> > > > > > still exist)
> > > > > > [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> > > > > > Enabled kernel protocols: lirc nec
> > > > > > scancode 0x800f041f = KEY_DOWN (0x6c)
> > > > > > [kodiuser@kodiarch ~]$ cat /etc/ir-keytable/keymap.txt
> > > > > > scancode 0x800f041f = KEY_DOWN (0x6c)
> > > > > > [kodiuser@kodiarch ~]$ sudo ir-keytable -w /etc/ir-keytable/keymap.txt
> > > > > > Segmentation fault
> > > > > > [kodiuser@kodiarch ~]$ sudo ir-keytable -r | grep KEY_DOWN
> > > > > > Enabled kernel protocols: lirc nec
> > > > > > scancode 0x800f041f = KEY_DOWN (0x6c)
> > > > > > [kodiuser@kodiarch ~]$
> > > > >
> > > > > I suspect ir-keytable is segfaulting in the code that reads the file; would
> > > > > you be able to share the keymap.txt file please? That way I can see if I
> > > > > can reproduce the problem.
> > > > >
> > > > > Parsing of the keymap is done in C which can be prone to these sorts of
> > > > > problems.
> > > > >
> > > > > > Here is the example syslog output of the segfault:
> > > > > > Jan 20 18:15:33 kodiarch kernel: ir-keytable[817]: segfault at 0 ip
> > > > > > 00007f1a958436f5 sp 00007ffe039a5aa8 error 4 in
> > > > > > libc-2.30.so[7f1a95707000+14d000]
> > > > > > Jan 20 18:15:33 kodiarch kernel: Code: 00 00 0f 1f 00 31 c0 c5 f8 77
> > > > > > c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 89 f9 48 89 fa c5 f9 ef
> > > > > > c0 83 e1 3f 83 f9 20 77 2b <c5> fd 74 0f c5 fd d7 c1 85 c0 0f 85 eb 00
> > > > > > 00 00 48 83 c7 20 83 e1
> > > > > > Jan 20 18:15:33 kodiarch systemd[1]: Started Process Core Dump (PID 818/UID 0).
> > > > > > Jan 20 18:15:34 kodiarch systemd-coredump[819]: Process 817
> > > > > > (ir-keytable) of user 0 dumped core.
> > > > > >
> > > > > >                                                 Stack trace of thread 817:
> > > > > >                                                 #0  0x00007f1a958436f5
> > > > > > __strlen_avx2 (libc.so.6 + 0x1616f5)
> > > > > >                                                 #1  0x00007f1a95770be3
> > > > > > __strdup (libc.so.6 + 0x8ebe3)
> > > > > >                                                 #2  0x0000563150aa43b7
> > > > > > n/a (ir-keytable + 0x83b7)
> > > > > >                                                 #3  0x0000563150aa44c6
> > > > > > n/a (ir-keytable + 0x84c6)
> > > > > >                                                 #4  0x00007f1a957edfc0
> > > > > > argp_parse (libc.so.6 + 0x10bfc0)
> > > > > >                                                 #5  0x0000563150aa2099
> > > > > > n/a (ir-keytable + 0x6099)
> > > > > >                                                 #6  0x00007f1a95709153
> > > > > > __libc_start_main (libc.so.6 + 0x27153)
> > > > > >                                                 #7  0x0000563150aa325e
> > > > > > n/a (ir-keytable + 0x725e)
> > > > > > Jan 20 18:15:34 kodiarch systemd[1]: systemd-coredump@3-818-0.service:
> > > > > > Succeeded.
> > > > >
> > > > > This would have to be done a in debug build.
> > > > >
> > > > > Thanks
> > > > > Sean
> > > >
> > > >
> > > >
> > > > Hello, Sean-
> > > > I'd be happy to share the files, I greatly appreciate you looking into
> > > > this.  I'll try attaching them to this email.
> > > > There are two files- one was my original file, the other was my
> > > > attempt to make the most basic file based on a single line of
> > > > ir-keytable -r.
> > >
> > > Ok, ir-keytable segfaults because there is no protocol specified. You'll
> > > need something like "# table foobar, type: RC6-MCE" as a first line. Of
> > > course, ir-keytable should not segfault if this is missing. I'll write
> > > a fix for this.
> > >
> > > Secondly, there is a new format for rc keymaps written in toml. A new format
> > > was needed to support BPF keymaps and keymaps with multiple protocols
> > > are better supported. See man rc_keymap
> > >
> > > It looks like the keymap you are trying to load contains two different
> > > protocols, rc6-mce and something else (nec-x?). Please let me know what
> > > you are trying to do so I can help write a toml keymap.
> > >
> > >
> > > Sean
> > >

Re: ir-keytable segfault when writing keymap from file

[Sean Young]

Hi Camden,

On Tue, Jan 21, 2020 at 02:48:45PM -0800, camden lindsay wrote:
> Will do.
> 
> To do a quick test, i copied the sample config file out of the man
> page and tried loading it:
> [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -w /etc/ir-keytable/test.toml
> Read iMON Station RSC table
> /etc/ir-keytable/test.toml: keycode `KEY_MAX' not recognised, no

The KEY_MAX problem is fixed in master.

> mapping for scancode 8392834
> Wrote 42 keycode(s) to driver
> Protocols changed to nec
> Can't find imon_rsc bpf protocol in /etc/rc_keymaps/protocols or
> /usr/lib/udev/rc_keymaps/protocols
> [kodiuser@kodiarch ir-keytable]$
> 
> 
> Looks like perhaps i should file a bug against arch for the missing
> protocol file?

That would be great, however I don't think it affects the problem you are
having. 

> I have no idea what IR BPF decoding does.. but the pages i have
> skimmed about it (including running across your ramblings and  bpf man
> page description) seem to indicate it is more complex that what i'll
> need, given i'll be using the kernel IR decoders.  I think? heh.

For the most common IR protocols, the kernel includes a set of hand-written
decoders. There are many more protocols, or slight variants. So rather
than having a decoder for each, we use BPF for those. BPF decoders are
stored in /usr/lib/udev/rc_keymaps/protocols 

Having said all of that, it's likely that you can make do with the kernel
decoders (non-BPF).

I would suggest you try the "ir-keytable -p all -t" and see if you can
identify all the protocols and scancodes of your remote.


Sean

Re: ir-keytable segfault when writing keymap from file

[camden lindsay]

[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]

On Wed, Jan 22, 2020 at 1:16 AM Sean Young <sean@mess.org> wrote:
>
> Hi Camden,
>
> On Tue, Jan 21, 2020 at 02:48:45PM -0800, camden lindsay wrote:
> > Will do.
> >
> > To do a quick test, i copied the sample config file out of the man
> > page and tried loading it:
> > [kodiuser@kodiarch ir-keytable]$ sudo ir-keytable -w /etc/ir-keytable/test.toml
> > Read iMON Station RSC table
> > /etc/ir-keytable/test.toml: keycode `KEY_MAX' not recognised, no
>
> The KEY_MAX problem is fixed in master.
>
> > mapping for scancode 8392834
> > Wrote 42 keycode(s) to driver
> > Protocols changed to nec
> > Can't find imon_rsc bpf protocol in /etc/rc_keymaps/protocols or
> > /usr/lib/udev/rc_keymaps/protocols
> > [kodiuser@kodiarch ir-keytable]$
> >
> >
> > Looks like perhaps i should file a bug against arch for the missing
> > protocol file?
>
> That would be great, however I don't think it affects the problem you are
> having.

Understood, and agreed.


>
> > I have no idea what IR BPF decoding does.. but the pages i have
> > skimmed about it (including running across your ramblings and  bpf man
> > page description) seem to indicate it is more complex that what i'll
> > need, given i'll be using the kernel IR decoders.  I think? heh.
>
> For the most common IR protocols, the kernel includes a set of hand-written
> decoders. There are many more protocols, or slight variants. So rather
> than having a decoder for each, we use BPF for those. BPF decoders are
> stored in /usr/lib/udev/rc_keymaps/protocols
>
> Having said all of that, it's likely that you can make do with the kernel
> decoders (non-BPF).
>
> I would suggest you try the "ir-keytable -p all -t" and see if you can
> identify all the protocols and scancodes of your remote.

Did this, and found that all of the remote commands were nec-x and I
must have been mapping the others for some other device.  Included my
mappings for the other device to test the toml file with multiple
protocols, and it all seems to work correctly

[kodiuser@kodiarch ~]$ sudo ir-keytable -c
Old keytable cleared
[kodiuser@kodiarch ~]$ sudo ir-keytable -w /etc/ir-keytable/test.toml
Read AVR54 Remote table
Wrote 64 keycode(s) to driver
Protocols changed to nec rc-6
[kodiuser@kodiarch ~]$ grep 0x /etc/ir-keytable/test.toml | wc -l
64
[kodiuser@kodiarch ~]$


Now have the toml file as attached, and seems to work for what I need
and load properly.

One question; the format  as called out in the man page seems strange-
that we set a name to the first [[protocols]] entry, which appears to
be for the entire file- but we don't in subsequent [[protocols]]
entries.   Is that by design/purposeful?  Or am I reading the man page
example wrong?




Many thanks for helping me getting this sorted- i can use my remote again!! :)
c
>
>
> Sean

[-- Attachment #2: keymap.toml --]
[-- Type: application/octet-stream, Size: 2395 bytes --]

       [[protocols]]
       name = "AVR54 Remote"
       protocol = "nec"
       variant = "necx"
       [protocols.scancodes]
        0x847490 = "KEY_ENTER"
        0x84748a = "KEY_FASTFORWARD"
        0x84747e = "KEY_REWIND"
        0x84747f = "KEY_PLAY"
        0x847499 = "KEY_RECORD"
        0x84748c = "KEY_PAUSE"
        0x84747c = "KEY_X"
        0x84747d = "KEY_NEXTSONG"
        0x84747b = "KEY_PREVIOUSSONG"
        0x84748e = "KEY_UP"
        0x847492 = "KEY_DOWN"
        0x84748f = "KEY_LEFT"
        0x847491 = "KEY_RIGHT"
        0x847497 = "KEY_BACKSPACE"
        0x847496 = "KEY_MENU"
        0x80d864 = "KEY_POWER"

       [[protocols]]
       protocol = "rc-6"
       [protocols.scancodes]
        0x800f0400 = "KEY_NUMERIC_0"
        0x800f0401 = "KEY_NUMERIC_1"
        0x800f0402 = "KEY_NUMERIC_2"
        0x800f0403 = "KEY_NUMERIC_3"
        0x800f0404 = "KEY_NUMERIC_4"
        0x800f0405 = "KEY_NUMERIC_5"
        0x800f0406 = "KEY_NUMERIC_6"
        0x800f0407 = "KEY_NUMERIC_7"
        0x800f0408 = "KEY_NUMERIC_8"
        0x800f0409 = "KEY_NUMERIC_9"
        0x800f040a = "KEY_DELETE"
        0x800f040c = "KEY_SLEEP"
        0x800f040d = "KEY_MEDIA"
        0x800f040e = "KEY_MUTE"
        0x800f040f = "KEY_INFO"
        0x800f0410 = "KEY_VOLUMEUP"
        0x800f0411 = "KEY_VOLUMEDOWN"
        0x800f0412 = "KEY_CHANNELUP"
        0x800f0413 = "KEY_CHANNELDOWN"
        0x800f041c = "KEY_NUMERIC_POUND"
        0x800f041d = "KEY_NUMERIC_STAR"
        0x800f0424 = "KEY_DVD"
        0x800f0425 = "KEY_TUNER"
        0x800f0426 = "KEY_EPG"
        0x800f0427 = "KEY_ZOOM"
        0x800f0432 = "KEY_MODE"
        0x800f0433 = "KEY_PRESENTATION"
        0x800f0434 = "KEY_EJECTCD"
        0x800f043a = "KEY_BRIGHTNESSUP"
        0x800f0446 = "KEY_TV"
        0x800f0447 = "KEY_AUDIO"
        0x800f0448 = "KEY_PVR"
        0x800f0449 = "KEY_CAMERA"
        0x800f044a = "KEY_VIDEO"
        0x800f044c = "KEY_LANGUAGE"
        0x800f044d = "KEY_TITLE"
        0x800f044e = "KEY_PRINT"
        0x800f0450 = "KEY_RADIO"
        0x800f045a = "KEY_SUBTITLE"
        0x800f045b = "KEY_RED"
        0x800f045c = "KEY_GREEN"
        0x800f045d = "KEY_YELLOW"
        0x800f045e = "KEY_BLUE"
        0x800f0465 = "KEY_POWER2"
        0x800f046e = "KEY_PLAYPAUSE"
        0x800f046f = "KEY_PLAYER"
        0x800f0480 = "KEY_BRIGHTNESSDOWN"
        0x800f0481 = "KEY_PLAYPAUSE"

Re: ir-keytable segfault when writing keymap from file

[Sean Young]

On Wed, Jan 22, 2020 at 07:32:41PM -0800, camden lindsay wrote:
> Did this, and found that all of the remote commands were nec-x and I
> must have been mapping the others for some other device.  Included my
> mappings for the other device to test the toml file with multiple
> protocols, and it all seems to work correctly
> 
> [kodiuser@kodiarch ~]$ sudo ir-keytable -c
> Old keytable cleared
> [kodiuser@kodiarch ~]$ sudo ir-keytable -w /etc/ir-keytable/test.toml
> Read AVR54 Remote table
> Wrote 64 keycode(s) to driver
> Protocols changed to nec rc-6
> [kodiuser@kodiarch ~]$ grep 0x /etc/ir-keytable/test.toml | wc -l
> 64
> [kodiuser@kodiarch ~]$
> 
> 
> Now have the toml file as attached, and seems to work for what I need
> and load properly.
> 
> One question; the format  as called out in the man page seems strange-
> that we set a name to the first [[protocols]] entry, which appears to
> be for the entire file- but we don't in subsequent [[protocols]]
> entries.   Is that by design/purposeful?  Or am I reading the man page
> example wrong?

That man page could do with some re-wording. I'm not great at writing
documentation.

Your attached keymap looks like:

       [[protocols]]
       name = "AVR54 Remote"
       protocol = "nec"
       variant = "necx"
       [protocols.scancodes]
        0x847490 = "KEY_ENTER"
        0x84748a = "KEY_FASTFORWARD"
        0x84747e = "KEY_REWIND"
        0x84747f = "KEY_PLAY"
        0x847499 = "KEY_RECORD"
        0x84748c = "KEY_PAUSE"
        0x84747c = "KEY_X"
        0x84747d = "KEY_NEXTSONG"
        0x84747b = "KEY_PREVIOUSSONG"
        0x84748e = "KEY_UP"
        0x847492 = "KEY_DOWN"
        0x84748f = "KEY_LEFT"
        0x847491 = "KEY_RIGHT"
        0x847497 = "KEY_BACKSPACE"
        0x847496 = "KEY_MENU"
        0x80d864 = "KEY_POWER"

       [[protocols]]

Here is the second [[protocols]] entry. Is that what you mean?

       protocol = "rc-6"
       [protocols.scancodes]
        0x800f0400 = "KEY_NUMERIC_0"
        0x800f0401 = "KEY_NUMERIC_1"
        0x800f0402 = "KEY_NUMERIC_2"
        0x800f0403 = "KEY_NUMERIC_3"
        0x800f0404 = "KEY_NUMERIC_4"
        0x800f0405 = "KEY_NUMERIC_5"
        0x800f0406 = "KEY_NUMERIC_6"
        0x800f0407 = "KEY_NUMERIC_7"
        0x800f0408 = "KEY_NUMERIC_8"
        0x800f0409 = "KEY_NUMERIC_9"
        0x800f040a = "KEY_DELETE"
        0x800f040c = "KEY_SLEEP"
        0x800f040d = "KEY_MEDIA"
        0x800f040e = "KEY_MUTE"
        0x800f040f = "KEY_INFO"
        0x800f0410 = "KEY_VOLUMEUP"
        0x800f0411 = "KEY_VOLUMEDOWN"
        0x800f0412 = "KEY_CHANNELUP"
        0x800f0413 = "KEY_CHANNELDOWN"
        0x800f041c = "KEY_NUMERIC_POUND"
        0x800f041d = "KEY_NUMERIC_STAR"
        0x800f0424 = "KEY_DVD"
        0x800f0425 = "KEY_TUNER"
        0x800f0426 = "KEY_EPG"
        0x800f0427 = "KEY_ZOOM"
        0x800f0432 = "KEY_MODE"
        0x800f0433 = "KEY_PRESENTATION"
        0x800f0434 = "KEY_EJECTCD"
        0x800f043a = "KEY_BRIGHTNESSUP"
        0x800f0446 = "KEY_TV"
        0x800f0447 = "KEY_AUDIO"
        0x800f0448 = "KEY_PVR"
        0x800f0449 = "KEY_CAMERA"
        0x800f044a = "KEY_VIDEO"
        0x800f044c = "KEY_LANGUAGE"
        0x800f044d = "KEY_TITLE"
        0x800f044e = "KEY_PRINT"
        0x800f0450 = "KEY_RADIO"
        0x800f045a = "KEY_SUBTITLE"
        0x800f045b = "KEY_RED"
        0x800f045c = "KEY_GREEN"
        0x800f045d = "KEY_YELLOW"
        0x800f045e = "KEY_BLUE"
        0x800f0465 = "KEY_POWER2"
        0x800f046e = "KEY_PLAYPAUSE"
        0x800f046f = "KEY_PLAYER"
        0x800f0480 = "KEY_BRIGHTNESSDOWN"
        0x800f0481 = "KEY_PLAYPAUSE"

> Many thanks for helping me getting this sorted- i can use my remote again!! :)

No problem, glad it is working.


Sean