[mythtv] lirc_client.c sending empty CODE cmd to LIRC -> segfault
Michael T. Dean
mtdean at thirdcontact.com
Wed Feb 10 03:39:11 UTC 2010
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:
>>> 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.
>>> lircrcd: received command: "CODE 01007f0000000000 1e Down
>>> lircrcd: received command: "CODE 01007f0000000000 22 Down
>>> lircrcd: 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
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.
More information about the mythtv-dev