[mythtv] lirc_client.c sending empty CODE cmd to LIRC -> segfault

[Michael T. Dean]

On 02/09/2010 05:42 PM, David Kubicek wrote:
> On 02/09/2010 10:09 PM, Michael T. Dean wrote:
>> On 02/09/2010 03:42 PM, David Kubicek wrote:
>>> Hello,
>>>
>>> I was just playing with the optional lircrcd LIRC daemon and it kept
>>> segfaulting on me. I found the bug in the daemon (latest CVS version),
>>> but the reason for this is MythTV sending an empty CODE command. Until
>>> the bug is fixed in either of these two applications, it'll break
>>> advanced LIRC configurations...
>>>
>>> I haven't looked into MythTV, so I have no patch for you, but I'll be
>>> sending a patch to LIRC people. If you actually want the patch and it
>>> would be integrated soon (e.i. not in 6 months:)) Well, the command
>>> packet is actually from lircd, but it really originates in MythTV.
>>>
>>> LOG:
>>>
>>> lircrcd[3673]: received command: "CODE 01007f0000000000 1e Down
>>> imon_ultrabay_pad"
>>> ...
>>> lircrcd[3673]: received command: "CODE 01007f0000000000 22 Down
>>> imon_ultrabay_pad"
>>> ...
>>> lircrcd[3673]: received command: "CODE "
>>>
>>> Segfault in lircrcd (not relevant for you):
>>>
>>> #0 0xb764af93 in strlen () from /lib/tls/i686/cmov/libc.so.6
>>> #1 0xb764acd5 in strdup () from /lib/tls/i686/cmov/libc.so.6
>>> #2 0x0804a121 in code_func (fd=-1217294348, message=0x0,
>>> arguments=0x0) at lircrcd.c:489
>>> #3 0x0804adbd in get_command (argc=2, argv=0xbfe70a04) at lircrcd.c:646
>>> #4 loop (argc=2, argv=0xbfe70a04) at lircrcd.c:737
>>> #5 main (argc=2, argv=0xbfe70a04) at lircrcd.c:1010
>>>
>>>
>>
>> Are you sure it's not: http://svn.mythtv.org/trac/ticket/7653 ? Can you
>> test that patch and provide feedback on it?
>>
>> Also, can you get a fix into lircrcd to accept line feeds properly (you
>> mentioned you're already planning to send a patch to the LIRC devs for
>> something else)?
>>
>
> That's right, the patch is finished and I'm going to notify LIRC 
> people tomorrow. I know about #7653 (found it via google), first I 
> made the change (added '\n'), but problem persisted.
>
> LIRC CVS checkout and gdb revealed a NULL dereference bug. The CODE 
> handler didn't have a NULL check after strtok() (message 'CODE ' 
> triggers it). The remaining command handlers are OK. So yes, this is 
> new and in both applications. In MythTV I can trigger 'CODE ' easily 
> by push-repeat of directional movement, like scrolling down the list. 
> Fast repeat rate possibly required. Sometimes it happens instantly, 
> sometimes I have to jiggle a few other buttons around and keep 
> scrolling up and down for a while.
>
> As for #7652, not including '\n' after CODE cmd is a protocol 
> violation to which lircrcd apparently react by exit. Either they 
> consider "lost sync" critical or it's just not handled very 
> gracefully. So there is no segfault in that case, just controlled 
> shutdown. It's still present in CVS and #7652 really should be fixed. 
> After all, it's just adding a '\n' at the end of one string in 
> libmythui/lirc_client.c...

Ah, I see...  I misread #7652--thought it was saying there was a 
DOS/*nix linefeed difference and it didn't like it, so I thought maybe 
you could fix it to accept either.  But, since we're sending neither, 
that's not the issue.  :)

Thanks for the info.  Maybe I can look at getting #7652 in tomorrow.

Mike