[mythtv] RE: [Xmltv-users] Figured out problem with tv_grab_na and
long listings
David A. Mason
damason at redshift.com
Sat Sep 6 12:06:22 EDT 2003
I have little insight into your final question. I'll leave that to Curtis.
But I can present this one to everyone, and perhaps others will have ideas
on the same line.
With the rationale of shortening the string nondestructively, I've added
these lines to ZapListings.pm on my machine at 1011 and again at 1327:
$html=~s/<a href[^>]*>/<a>/og;
$html=~s/<font[^>]*>/<font>/og;
I imagine that xmltv isn't using anything in those particular tags.
And what's encouraging is that I just ran a test and I got my Nogin listings
back, so I can get back to recording my Pete and Pete collection. If there's
other dross to be yanked, perhaps we can get further.
I understand this is not a systemic solution, but just a kludge, but it
seems to be helping a little.
DAM
-----Original Message-----
From: xmltv-users-admin at lists.sourceforge.net
[mailto:xmltv-users-admin at lists.sourceforge.net] On Behalf Of Ed Avis
Sent: Saturday, September 06, 2003 03:53
To: David A. Mason
Cc: 'Curtis Stanford'; xmltv-users at lists.sourceforge.net; 'Discussion about
mythtv'; 'Development of mythtv'
Subject: RE: [Xmltv-users] Figured out problem with tv_grab_na and long
listings
(I think there may be some problem with the xmltv-users list; the message
quoted below seems to be intended for that list, but I'm a subscriber and I
haven't seen any of the messages until now. But thanks for cc'ing the list,
I hope it will work from now on.
I will reply to bits of the messages even though they may be questions asked
of somebody else.)
On Wed, 3 Sep 2003, David A. Mason wrote:
>I've noticed that's what actually happening is that tv_grab_na
>segfaults.
Yup. It sometimes produces some errors before segfaulting, but it crashes
in the end. This indicates a bug in perl, or at best, a bug in one of the C
extension libraries that is linked in.
>Is that what was going on,
Yes. I was in the middle of testing with the latest release candidate of
perl 5.8.1 (which still segfaults) and getting a backtrace.
>and was fixed for you by the below changes?
>So, would anyone be interested in a core file or two from tv_grab_na
>segfaults?
Probably not, I can reproduce the bug myself and do so with a debugging
build of perl. If it's a memory corruption bug, a stack trace may not be
that helpful anyway.
>-----Original Message-----
>From: Curtis Stanford [mailto:curtis at stanfordcomputing.com]
>Here's a diff. I'm not a perl dood so my apologies for any gaffs:
>
>--- ZapListings.pm 2003-09-02 17:42:41.000000000 -0600
>+++ ZapListings.pm.new 2003-09-02 17:42:56.000000000 -0600
>@@ -1012,6 +1012,8 @@
> for my $row (split(/<tr/, $html)) {
> # nuke everything leading up to first >
> # which amounts to html attributes of <tr used in split
>+ my $rowlen=length($row);
>+ next if ( $rowlen > 3526 );
> $row=~s/^[^>]*>//so;
> $row=~s/<\/tr>.*//so;
>
>@@ -1325,6 +1327,8 @@
> for my $row (split(/<tr/, $html)) {
> # nuke everything leading up to first >
> # which amounts to html attributes of <tr used in split
>+ my $rowlen=length($row);
>+ next if ( $rowlen > 3526 );
> $row=~s/^[^>]*>//so;
>
> # skipif the split didn't end with a row end </tr>
>>-----Original Message-----
>>[mailto:xmltv-users-admin at lists.sourceforge.net] On Behalf Of Curtis
>>Stanford
>>I think I've figured out this problem and fixed it in my version of
>>ZapListings. Check out this message:
>>
>>http://www.mail-archive.com/mon@linux.kernel.org/msg00853.html
>>
>>Seems there is a long standing bug with Perl's regexp code that chokes
>>on strings longer than 3526 characters. So, in ZapListings I checked
>>the length of $row and skipped it if it was over 3526.
Bu what makes you so sure that this particular bug is responsible? There
could be some other bug that (say) happens for all strings over 4000
characters long, and by skipping the long strings you avoided triggering
that. Or there could be some other feature of certain strings that causes
the crash, and by skipping the long ones it just so happens you are skipping
those that cause the problem.
Bear in mind that I was able to reproduce the crash with perl-5.8.1-RC4. I
don't know if the bug you mention has been fixed in that Perl release, I
will check that later. As I mentioned, a stack trace is probably not that
much use, but here it is for the record:
#0 0x80c4f83 in Perl_hv_free_ent (hv=0x8eb0b98, entry=0x8ee6e90) at
hv.c:1646
1646 if (val && isGV(val) && GvCVu(val) && HvNAME(hv))
(gdb) bt
#0 0x80c4f83 in Perl_hv_free_ent (hv=0x8eb0b98, entry=0x8ee6e90) at
hv.c:1646 #1 0x80c5341 in S_hfreeentries (hv=0x8eb0b98) at hv.c:1760 #2
0x80c53b1 in Perl_hv_undef (hv=0x8eb0b98) at hv.c:1787 #3 0x80dfd2b in
Perl_sv_clear (sv=0x8eb0b98) at sv.c:5157 #4 0x80e023a in Perl_sv_free
(sv=0x8eb0b98) at sv.c:5338 #5 0x80e545e in Perl_sv_unref_flags
(sv=0x87b7d18, flags=1) at sv.c:7908 #6 0x80ddf0d in
Perl_sv_force_normal_flags (sv=0x87b7d18, flags=1)
at sv.c:4258
#7 0x8100f0d in Perl_leave_scope (base=69) at scope.c:918
#8 0x80cace9 in Perl_pp_unstack () at pp_hot.c:130
#9 0x80b3941 in Perl_runops_debug () at dump.c:1434
#10 0x8062509 in S_run_body (oldscope=1) at perl.c:1827
#11 0x80620bb in perl_run (my_perl=0x8186ee8) at perl.c:1746 #12 0x805e713
in main (argc=5, argv=0xbffff534, env=0xbffff54c)
at perlmain.c:86
FWIW, I just tried again to reproduce the crash with my normal perl-5.8.0
and could not.
So - your patch might do the job, but can you explain why you think the
particular bug in perl with >3526 chars is responsible?
--
Ed Avis <ed at membled.com>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Xmltv-users mailing list
Xmltv-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xmltv-users
More information about the mythtv-dev
mailing list