Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

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

 

 

MythTV dev RSS feed   Index | Next | Previous | View Threaded


foceni at gmail

Feb 9, 2010, 12:42 PM

Post #1 of 8 (2597 views)
Permalink
lirc_client.c sending empty CODE cmd to LIRC -> segfault

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


--
David Kubicek
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Feb 9, 2010, 1:09 PM

Post #2 of 8 (2491 views)
Permalink
Re: lirc_client.c sending empty CODE cmd to LIRC -> segfault [In reply to]

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)?

Thanks,
Mike

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


foceni at gmail

Feb 9, 2010, 2:42 PM

Post #3 of 8 (2486 views)
Permalink
Re: lirc_client.c sending empty CODE cmd to LIRC -> segfault [In reply to]

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...

See you,

--
David Kubicek
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Feb 9, 2010, 7:39 PM

Post #4 of 8 (2487 views)
Permalink
Re: lirc_client.c sending empty CODE cmd to LIRC -> segfault [In reply to]

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
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Feb 13, 2010, 10:09 AM

Post #5 of 8 (2384 views)
Permalink
Re: lirc_client.c sending empty CODE cmd to LIRC -> segfault [In reply to]

On 02/09/2010 10:39 PM, Michael T. Dean wrote:
> 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.
> >>>
> >>> LOG:
> >>>
> >>> lircrcd[3673]: received command: "CODE 01007f0000000000 1e Down
> >>> imon_ultrabay_pad"
> >>>
> >> 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.

So the only place we're dealing with LIRC's CODE is in
libs/libmythui/lirc_client.{h,c} , which comes from LIRC's
tools/lirc_client.{h,c}. I can see that LIRC's "official" lirc_client.c
doesn't yet include a line feed character at the end of the CODE line
(see
http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/tools/lirc_client.c?revision=5.29.2.1&view=markup
on line 1672 ).

It seems Daniel K modified our version of lirc_client.{h,c} for thread
safety before importing it so it has quite a few differences to the
upstream version, but I'd still like to see the linefeed fix sent
upstream. Also, is your patch for LIRC for the tools/lirc_client.{h,c}
code? If so, once it's in the upstream copy, we could easily pull an
update from them.

Attached is a (completely untested) patch that upgrades our version of
lirc_client to be in line with the version in LIRC 0.8.6 (and a patch
showing the differences in LIRC's unmodified lirc_client tool). Feel
free to test out the patch, but it likely won't help with the issue
you're seeing. I probably won't look at updating lirc_client until
after 0.23 is released so the changes can get some testing before being
backported to stable. If you can push some changes (including the line
feed change) into the upstream copy, it will make it easier to get those
changes into our copy. :)

Thanks,
Mike
Attachments: mythtv-upgrade_lirc_client_to_0_8_6.patch (1.92 KB)
  lirc_client-upgrade_from_0_8_4a_to_0_8_6.patch (2.43 KB)


foceni at gmail

Feb 28, 2010, 6:40 AM

Post #6 of 8 (1979 views)
Permalink
Re: lirc_client.c sending empty CODE cmd to LIRC -> segfault [In reply to]

On 02/13/2010 07:09 PM, Michael T. Dean wrote:
> On 02/09/2010 10:39 PM, Michael T. Dean wrote:
> It seems Daniel K modified our version of lirc_client.{h,c} for thread
> safety before importing it so it has quite a few differences to the
> upstream version, but I'd still like to see the linefeed fix sent
> upstream. Also, is your patch for LIRC for the tools/lirc_client.{h,c}
> code? If so, once it's in the upstream copy, we could easily pull an
> update from them.
>

Hi, I just talked with Christoph Bartelmus of LIRC and we cleared up the
newline issue. Remember us talking about this? You said I should let
LIRC know about the missing newline and the other bug, because you pull
their version and you'd like to have the newline fixed upstream instead
of myth.

It appears the issue is not related to original LIRC code at all, it's
just in myth. The thing is their read function leaves newlines in the
buffer and that's why their lirc_code2char FMT string cannot have "\n".
Christoph said you're using your own read function which removes
newlines. Because of this custom read function, you're missing a newline
in the CODE command.

The newline should be added to other changes you apply to upstream
lirc_client - well, or change the read function. Let me know if you need
more, this is the original post:

Christoph Bartelmus wrote:
> The problem is that they don't use lirc_nextcode() in their lirc.cpp but
> have their own read function, which throws away the newline.
> lirc_client is the wrong place to add it.
> lirc_code2char simply expects the newline still to be in the code string.

Best regards,

--
David Kubicek
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mtdean at thirdcontact

Feb 28, 2010, 11:33 AM

Post #7 of 8 (1975 views)
Permalink
Re: lirc_client.c sending empty CODE cmd to LIRC -> segfault [In reply to]

On 02/28/2010 09:40 AM, David Kubicek wrote:
> On 02/13/2010 07:09 PM, Michael T. Dean wrote:
>> On 02/09/2010 10:39 PM, Michael T. Dean wrote:
>> It seems Daniel K modified our version of lirc_client.{h,c} for thread
>> safety before importing it so it has quite a few differences to the
>> upstream version, but I'd still like to see the linefeed fix sent
>> upstream. Also, is your patch for LIRC for the tools/lirc_client.{h,c}
>> code? If so, once it's in the upstream copy, we could easily pull an
>> update from them.
>>
>
> Hi, I just talked with Christoph Bartelmus of LIRC and we cleared up
> the newline issue. Remember us talking about this? You said I should
> let LIRC know about the missing newline and the other bug, because you
> pull their version and you'd like to have the newline fixed upstream
> instead of myth.
>
> It appears the issue is not related to original LIRC code at all, it's
> just in myth. The thing is their read function leaves newlines in the
> buffer and that's why their lirc_code2char FMT string cannot have
> "\n". Christoph said you're using your own read function which removes
> newlines. Because of this custom read function, you're missing a
> newline in the CODE command.
>
> The newline should be added to other changes you apply to upstream
> lirc_client - well, or change the read function. Let me know if you
> need more, this is the original post:
>
> Christoph Bartelmus wrote:
>> The problem is that they don't use lirc_nextcode() in their lirc.cpp but
>> have their own read function, which throws away the newline.
>> lirc_client is the wrong place to add it.
>> lirc_code2char simply expects the newline still to be in the code string.

Thanks for following through and for the update. I probably should have
looked deeper into the changes we had in our version--I didn't notice
the difference in the read.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


foceni at gmail

Feb 28, 2010, 12:13 PM

Post #8 of 8 (1974 views)
Permalink
Re: lirc_client.c sending empty CODE cmd to LIRC -> segfault [In reply to]

On 02/28/2010 08:33 PM, Michael T. Dean wrote:
> On 02/28/2010 09:40 AM, David Kubicek wrote:
> Thanks for following through and for the update. I probably should have
> looked deeper into the changes we had in our version--I didn't notice
> the difference in the read.
>

Thank you for cooperation!

--
David Kubicek
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.