Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#5545 closed defect (fixed)

Mythbackend fills up memory till it crashes (~2GByte VSZ, 700MByte RSS)

Reported by: AntiCat (mythtv@… Owned by: Janne Grunau
Priority: major Milestone: 0.22
Component: mythtv Version: head
Severity: high Keywords:
Cc: danielk@… Ticket locked: no

Description

I have a memory leak on my mythtv. It started when I switched from an old fashion tv (analog) card to a DVB-C card. The amount of memory growth changes between idle and recording. If I am recording the leek is about 5-10x higher then in idle. (In Idle mode mythtv is scanning my channels for EIT data. I do not use any XML grabber as our broadcaster offers 7 Days of EPG on a transport stream.)

I tried to produce vallgrind logs, however I can not keep valgrind running for a long time as it kills the rest of my system: 99% CPU usage during recording -> frameloss and mythweb not working properly.

I hope all needed information is included. If you need any additional info let me know. The problem happens in the 21.fixes branch to. I just switched to trunk in the hope it would be less segnificant there.

Operating System:
=================
Gentoo  - Pentium 4 (without HT) 1GByte Ram.
Kernel  - 2.6.24-gentoo-r8
TV-Card - Teratec Cynergy DVB-C Card
g++ -v
======
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.2
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib
--disable-checking --disable-werror --enable-secureplt
--disable-libunwind-exceptions --disable-multilib --enable-libmudflap
--disable-libssp --disable-libgcj --with-arch=i686
--enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2)
MythTV Version
==============
Source: Trunk
Revision: 17733
Configured with:
--prefix=/usr --mandir=/usr/share/man --libdir-name=lib
--disable-audio-alsa --disable-altivec --disable-audio-jack
--enable-libx264 --enable-glx-procaddrarb --enable-dvb
--disable-firewire --disable-lirc --disable-audio-arts
--disable-directfb  --dvb-path=/usr/include --enable-xv
--enable-opengl-vsync --enable-xrandr --enable-x11 --enable-mmx
--with-bindings=perl,python --compile-type=debug --tune=i686
--disable-distcc --disable-ccache

Mythfrontend was not running during valgrind test.

I am currently restarting mythbackend with a cron job twice a week to guarantee proper operating. If I keep it open longer it is killed due to extensive memory allocation.

message lissted in kernel-ringbuffer:

"mythbackend[5177]: segfault at 000002ed eip b5177f12 esp a9dfea10 error 4" 

VSZ, RSS Statistic is (1 line every full hour):

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mythtv   10319  0.8  5.5 263340 57436 ?        Ssl  10:26   0:17 /usr/bin/mythbackend --verb...
mythtv   10319  0.4  5.2 260244 54872 ?        Ssl  10:26   0:25 /usr/bin/mythbackend --verb...
mythtv   10319  0.3  5.0 257548 52020 ?        Ssl  10:26   0:31 /usr/bin/mythbackend --verb...
mythtv   10319  0.3  4.7 254200 49108 ?        Ssl  10:26   0:43 /usr/bin/mythbackend --verb...
mythtv   10319  0.3  4.4 251104 45912 ?        Ssl  10:26   0:51 /usr/bin/mythbackend --verb...
mythtv   10319  0.2  4.1 248008 42660 ?        Ssl  10:26   0:57 /usr/bin/mythbackend --verb...
mythtv   10319  0.5 19.2 430296 199012 ?       Ssl  10:26   2:06 /usr/bin/mythbackend --verb...
mythtv   10319  0.2 20.3 433868 211160 ?       Ssl  10:26   1:15 /usr/bin/mythbackend --verb...
mythtv   10319  0.2 20.3 433868 211168 ?       Ssl  10:26   1:26 /usr/bin/mythbackend --verb...
mythtv   10319  0.2 20.3 434384 211212 ?       Ssl  10:26   1:36 /usr/bin/mythbackend --verb...
mythtv   10319  0.5 33.4 587320 346912 ?       Ssl  10:26   3:35 /usr/bin/mythbackend --verb...
mythtv   10319  0.4 40.5 652888 420360 ?       Ssl  10:26   2:49 /usr/bin/mythbackend --verb...
mythtv   10319  0.4 52.1 774624 540752 ?       Ssl  10:26   3:15 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.8 851948 620480 ?       Ssl  Jul14   2:34 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.6 852480 618476 ?       Ssl  Jul14   2:41 /usr/bin/mythbackend --verb...
mythtv   10319  0.2 59.4 852480 616228 ?       Ssl  Jul14   2:48 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.5 852480 616468 ?       Ssl  Jul14   3:13 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.5 852480 616468 ?       Ssl  Jul14   3:20 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.5 852480 616468 ?       Ssl  Jul14   3:26 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.5 852480 616468 ?       Ssl  Jul14   3:36 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.5 852480 616476 ?       Ssl  Jul14   3:43 /usr/bin/mythbackend --verb...
mythtv   10319  0.2 59.5 852480 616492 ?       Ssl  Jul14   3:49 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.5 853128 616652 ?       Ssl  Jul14   4:11 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.5 853128 616652 ?       Ssl  Jul14   4:18 /usr/bin/mythbackend --verb...
mythtv   10319  0.2 59.5 853264 616680 ?       Ssl  Jul14   4:24 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.5 853264 616740 ?       Ssl  Jul14   4:45 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.5 853396 616824 ?       Ssl  Jul14   5:08 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.5 853396 616880 ?       Ssl  Jul14   5:13 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.5 853532 616944 ?       Ssl  Jul14   5:22 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 59.5 853532 617048 ?       Ssl  Jul14   5:40 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 71.4 997060 739780 ?       Ssl  Jul14   6:46 /usr/bin/mythbackend --verb...
mythtv   10319  0.3 71.9 1000956 745716 ?      Ssl  Jul14   5:54 /usr/bin/mythbackend --verb...

Attachments (11)

logfile.13119.gz (34.9 KB) - added by anonymous 11 years ago.
logfile.15127.gz (31.9 KB) - added by anonymous 11 years ago.
logfile.17491.gz (34.3 KB) - added by anonymous 11 years ago.
mythtv-day.png (2.6 KB) - added by anonymous 11 years ago.
trimmed_logfile.txt (7.1 KB) - added by stuartm 11 years ago.
Uncompressed and cutdown copy of the valgrind log
valgrind3-1h.log.gz (36.4 KB) - added by AntiCat 11 years ago.
Full Valgrind Log of 1h Recording
valgrind3-5min.log.gz (36.5 KB) - added by AntiCat 11 years ago.
Full Valgrind Log of 5min Recording
t5545_debug_1.diff (1.1 KB) - added by Janne Grunau 11 years ago.
t5545_debug_2.diff (2.4 KB) - added by AntiCat 11 years ago.
t5545_debug_3.diff (2.4 KB) - added by Janne Grunau 11 years ago.
t5545_fix1.diff (1.0 KB) - added by Janne Grunau 11 years ago.

Download all attachments as: .zip

Change History (31)

Changed 11 years ago by anonymous

Attachment: logfile.13119.gz added

Changed 11 years ago by anonymous

Attachment: logfile.15127.gz added

Changed 11 years ago by anonymous

Attachment: logfile.17491.gz added

Changed 11 years ago by anonymous

Attachment: mythtv-day.png added

comment:1 Changed 11 years ago by udo

I experience similar (but not so extreme) growths of memory. I us e Terratec Cinergy 1200 DVB-T card with multirec to record three SD TV channels 24/7. Recently I started using EIT for soem radio channels besides the XMLTV based TV channels.

My stats so far: # cat /home/udo/psmyth.txt |cut -b16-65 %CPU %MEM VSZ RSS TTY STAT START TIME

7.2 9.1 393468 88688 ? Ssl 16:34 4:27 5.2 11.8 443152 115084 ? Ssl Jun23 39:17 5.7 12.6 451428 122892 ? Ssl Jun23 126:25 5.8 13.6 461224 132536 ? Ssl Jun23 213:50 5.9 14.8 473084 143824 ? Ssl Jun23 300:29 6.0 16.0 485440 156256 ? Ssl Jun23 391:59 5.9 17.0 495228 165496 ? Ssl Jun23 475:35 5.9 18.5 509572 179916 ? Ssl Jun23 560:35 6.0 19.9 522788 193996 ? Ssl Jun23 654:39

6.8 10.7 433740 104748 ? Ssl Jul02 52:04 7.8 13.7 461952 133204 ? Ssl Jul02 172:21 8.0 14.6 471740 142304 ? Ssl Jul02 293:00 7.8 15.4 479484 149972 ? Ssl Jul02 398:51 7.8 16.2 486708 157340 ? Ssl Jul02 510:43 7.8 17.3 497536 168352 ? Ssl Jul02 628:35 7.9 20.8 533292 202428 ? Ssl Jul02 743:31 7.9 22.0 544272 214168 ? Ssl Jul02 862:03 7.9 23.1 555240 225012 ? Ssl Jul02 981:52 8.0 24.4 567456 237172 ? Ssl Jul02 1098:28 7.9 25.2 549876 244692 ? Ssl Jul02 1199:34 7.8 26.2 584772 254916 ? Ssl Jul02 1307:43 7.9 27.6 599624 268256 ? Ssl Jul02 1425:36

I had a small crash of the backend at the empty line. I can not reliably run valgrind on the VIA EN12000 board: mythbackend gives strange errors and does not run well.

# mythfrontend --version Please include all output in bug reports. MythTV Version : exported MythTV Branch : branches/release-0-21-fixes Library API : 0.21.20080304-1 Network Protocol : 40 Options compiled in:

linux release using_alsa using_backend using_dbox2 using_dvb using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_live

comment:2 Changed 11 years ago by eric.bosch@…

I had this same thing happen on my machine (Core 2 Duo x86_64). Was watching live TV, everything was fine for a while, but after a scheduled recording completed, a subsequent recording did not occur. At this point, I lost keyboard/remote control, and noticed my memory usage was skyrocketing. I have 4G of RAM. System at idle, watching live TV, mythfrontend normally uses approximately 5.4% of RAM, but at the time this was going on, usage was at 51% and climbing rapidly. I had to kill the frontend and bounce the backend to get things to recover.

comment:3 Changed 11 years ago by eric.bosch@…

Oh, and I'm currently running trunk svn 18181

comment:4 Changed 11 years ago by eric.bosch@…

Sorry, one other detail. My CPU usage for mythfrontend went from it's usual 14% to 38%

Changed 11 years ago by stuartm

Attachment: trimmed_logfile.txt added

Uncompressed and cutdown copy of the valgrind log

comment:5 Changed 11 years ago by stuartm

Milestone: unknown0.22
Severity: mediumhigh

Same valgrind log we keep seeing for this issue.

comment:6 Changed 11 years ago by danielk

Cc: danielk@… added

hmm, this is definitely a PES packet we're keeping too long. Since you say this goes up when you are not collecting EIT it must be a PAT/PMT or NIT/SDT table.

comment:7 Changed 11 years ago by udo

I built a fresh svn checkout of mythtv-fixes on 11 october 2008. I installed it on the 12th of october. Some early figures:

%CPU %MEM VSZ RSS TTY STAT START TIME

8.9 11.2 435760 108728 ? Ssl Oct12 122:07 9.2 14.3 466100 139272 ? Ssl Oct12 259:58 9.4 15.7 480016 152884 ? Ssl Oct12 399:55 9.6 17.5 497020 170316 ? Ssl Oct12 547:57 9.6 18.6 508312 181476 ? Ssl Oct12 688:08 9.7 20.0 521500 194544 ? Ssl Oct12 837:01

It still keeps on growing....

Just 1 Terratec Cinergy 1200 DVB-T card with 7 virtual tuners of which 3 are more or less 24/7 recording 3 TV channels off of one multiplex. Back to back programs overlap 2 minutes max (1 minute at begin, 1 minute at the end). The machine has 1GB of RAM and is running on a VIA Epia EN12000.

# mythbackend --version Please include all output in bug reports. MythTV Version : exported MythTV Branch : branches/release-0-21-fixes Library API : 0.21.20080304-1 Network Protocol : 40 Options compiled in:

linux release using_alsa using_backend using_dbox2 using_dvb using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_live

comment:8 Changed 11 years ago by AntiCat

If there is anything I can do to help localizing the leak please let me know.

My email address is leak...a...t...anticat.ch.

comment:9 Changed 11 years ago by Dibblah

Resolution: fixed
Status: newclosed

Should be fixed by [19226]

comment:10 Changed 11 years ago by Janne Grunau

Resolution: fixed
Status: closednew

no, this leak is unrelated to [19226]

comment:11 Changed 11 years ago by Dibblah

Owner: changed from Isaac Richards to Janne Grunau
Status: newassigned

Thanks, janne!

Changed 11 years ago by AntiCat

Attachment: valgrind3-1h.log.gz added

Full Valgrind Log of 1h Recording

Changed 11 years ago by AntiCat

Attachment: valgrind3-5min.log.gz added

Full Valgrind Log of 5min Recording

comment:12 Changed 11 years ago by AntiCat

I have currently a spare Core2Duo machine. I made a test setup for mythtv with valgrind. The System is setup using mythubuntu 8.10 with latest weekly build of mythtv.

MythTV Version : 19626 MythTV Branch : branches/release-0-21-fixes Library API : 0.21.20080304-1 Network Protocol : 40 Options compiled in: linux profile using_oss using_alsa using_arts using_jack using_backend using_dbox2 using_dvb using_firewire using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_libfftw3 using_lirc using_opengl_vsync using_opengl_video using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld using_glx_proc_addr_arb using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_libavc_5_3 using_live

I still have the usual memory growth of about 100MB per Hour. I did a 1hour recording and a 5minute recording, both with valgrind running. As it is a test setup without any personal data on the machine I offer to put the machine into a dedicated subnet accessible from the internet and pass the login to a developer if it helps to figure out the source for the memory growth.

comment:13 Changed 11 years ago by Dibblah

Probably the important bits of these logs:

Short recording:

==7204== 11,534,336 bytes in 22 blocks are still reachable in loss record 778 of 778
==7204==    at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==7204==    by 0x4373501: pes_alloc(unsigned) (in /usr/lib/libmythtv-0.21.so.0.21.0)
==7204==    by 0x43960BC: PESPacket::PESPacket(PESPacket const&) (in /usr/lib/libmythtv-0.21.so.0.21.0)
==7204==    by 0x43941A1: MPEGStreamData::AssemblePSIP(TSPacket const*, bool&) (in /usr/lib/libmythtv-0.21.so.0.21.0)
==7204==    by 0x43948E1: MPEGStreamData::HandleTSTables(TSPacket const*) (in /usr/lib/libmythtv-0.21.so.0.21.0)
==7204==    by 0x438C507: MPEGStreamData::ProcessTSPacket(TSPacket const&) (in /usr/lib/libmythtv-0.21.so.0.21.0)
==7204==    by 0x438531D: MPEGStreamData::ProcessData(unsigned char const*, int) (in /usr/lib/libmythtv-0.21.so.0.21.0)
==7204==    by 0x4850CEC: DVBStreamHandler::RunTS() (in /usr/lib/libmythtv-0.21.so.0.21.0)
==7204==    by 0x48522DD: DVBStreamHandler::Run() (in /usr/lib/libmythtv-0.21.so.0.21.0)
==7204==    by 0x631A7ED: clone (in /lib/tls/i686/cmov/libc-2.8.90.so)

Long recording:

==6691== 147,324,928 bytes in 281 blocks are still reachable in loss record 791 of 791
==6691==    at 0x4025D2E: malloc (vg_replace_malloc.c:207)
==6691==    by 0x4373501: pes_alloc(unsigned) (in /usr/lib/libmythtv-0.21.so.0.21.0)
==6691==    by 0x43960BC: PESPacket::PESPacket(PESPacket const&) (in /usr/lib/libmythtv-0.21.so.0.21.0)
==6691==    by 0x43941A1: MPEGStreamData::AssemblePSIP(TSPacket const*, bool&) (in /usr/lib/libmythtv-0.21.so.0.21.0)
==6691==    by 0x43948E1: MPEGStreamData::HandleTSTables(TSPacket const*) (in /usr/lib/libmythtv-0.21.so.0.21.0)
==6691==    by 0x438C507: MPEGStreamData::ProcessTSPacket(TSPacket const&) (in /usr/lib/libmythtv-0.21.so.0.21.0)
==6691==    by 0x438531D: MPEGStreamData::ProcessData(unsigned char const*, int) (in /usr/lib/libmythtv-0.21.so.0.21.0)
==6691==    by 0x4850CEC: DVBStreamHandler::RunTS() (in /usr/lib/libmythtv-0.21.so.0.21.0)
==6691==    by 0x48522DD: DVBStreamHandler::Run() (in /usr/lib/libmythtv-0.21.so.0.21.0)
==6691==    by 0x631A7ED: clone (in /lib/tls/i686/cmov/libc-2.8.90.so)
==6691== 

comment:14 Changed 11 years ago by Janne Grunau

Status: assignedaccepted

Please run valgrind with t5545.diff applied. It should at least make the leak smaller.

I suspect that we might read a PID with video data as PSIP. That's at least the only way I can explain PES packets larger than 65536 bytes.

Changed 11 years ago by Janne Grunau

Attachment: t5545_debug_1.diff added

comment:15 Changed 11 years ago by AntiCat

Your patch did not produce any additional output on my system. So I also addad an else statement to doublecheck if the debug output was working. Result:

...
2009-01-14 10:56:01.602 Allocating a 3844 byte PES packet successful
2009-01-14 10:56:01.603 Allocating a 3844 byte PES packet successful
2009-01-14 10:56:01.603 Allocating a 3844 byte PES packet successful
2009-01-14 10:56:01.604 Allocating a 3844 byte PES packet successful
2009-01-14 10:56:01.606 Allocating a 3844 byte PES packet successful
...

I alterd the patch a little bit to also catch the other memory allocations. Result:

2009-01-14 18:23:44.043 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:23:44.134 static unsigned char* get_188_block() -> Allocating a 512*188 byte blocks
2009-01-14 18:23:56.069 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:24:08.030 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:24:20.449 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:24:34.210 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:24:46.950 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:24:58.720 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:25:12.089 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:25:25.770 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:25:37.789 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:25:49.919 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:26:03.640 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:26:16.721 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:26:28.430 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:26:41.540 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:26:55.230 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:27:07.529 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:27:19.300 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks
2009-01-14 18:27:33.140 static unsigned char* get_4096_block() -> Allocating a 128*4096 byte blocks

a lot of allocations but never a free

Changed 11 years ago by AntiCat

Attachment: t5545_debug_2.diff added

Changed 11 years ago by Janne Grunau

Attachment: t5545_debug_3.diff added

comment:16 Changed 11 years ago by AntiCat

Note 1: The patched line 322 and 325 conflicts during compile. I removed one case/break. this leads to NIT and NITo having the same value.

Note 2: My test machine is configured for MythtTV 0.21 with QT3. I had to rename on line 344 it.value() to it.data()

short time after start

1025 4096 blocks remain
1004 NIT, 1004 NITo, 0 other
10 NITs with network id 1
21 NITs with network id 2
21 NITs with network id 3
21 NITs with network id 4
20 NITs with network id 5
20 NITs with network id 6
20 NITs with network id 100
21 NITs with network id 139
21 NITs with network id 201
21 NITs with network id 202
21 NITs with network id 203
21 NITs with network id 204
21 NITs with network id 205
19 NITs with network id 206
19 NITs with network id 207
18 NITs with network id 273
19 NITs with network id 274
19 NITs with network id 275
20 NITs with network id 277
20 NITs with network id 298
20 NITs with network id 299
20 NITs with network id 300
20 NITs with network id 301
20 NITs with network id 317
20 NITs with network id 400
20 NITs with network id 401
20 NITs with network id 402
20 NITs with network id 403
20 NITs with network id 404
20 NITs with network id 410
20 NITs with network id 433
20 NITs with network id 480
20 NITs with network id 502
20 NITs with network id 600
20 NITs with network id 601
20 NITs with network id 602
20 NITs with network id 603
20 NITs with network id 604
10 NITs with network id 605
20 NITs with network id 735
20 NITs with network id 800
20 NITs with network id 860
20 NITs with network id 880
20 NITs with network id 888
20 NITs with network id 890
20 NITs with network id 891
20 NITs with network id 892
20 NITs with network id 910
20 NITs with network id 920
20 NITs with network id 942
21 NITs with network id 990

after ~15min

8193 4096 blocks remain
8172 NIT, 8172 NITo, 0 other
82 NITs with network id 1
164 NITs with network id 2
164 NITs with network id 3
164 NITs with network id 4
163 NITs with network id 5
163 NITs with network id 6
163 NITs with network id 100
164 NITs with network id 139
164 NITs with network id 201
164 NITs with network id 202
164 NITs with network id 203
164 NITs with network id 204
164 NITs with network id 205
162 NITs with network id 206
162 NITs with network id 207
162 NITs with network id 273
163 NITs with network id 274
163 NITs with network id 275
164 NITs with network id 277
164 NITs with network id 298
164 NITs with network id 299
164 NITs with network id 300
164 NITs with network id 301
164 NITs with network id 317
164 NITs with network id 400
164 NITs with network id 401
164 NITs with network id 402
164 NITs with network id 403
164 NITs with network id 404
164 NITs with network id 410
164 NITs with network id 433
164 NITs with network id 480
163 NITs with network id 502
163 NITs with network id 600
163 NITs with network id 601
163 NITs with network id 602
163 NITs with network id 603
163 NITs with network id 604
82 NITs with network id 605
163 NITs with network id 735
163 NITs with network id 800
163 NITs with network id 860
163 NITs with network id 880
163 NITs with network id 888
163 NITs with network id 890
163 NITs with network id 891
163 NITs with network id 892
163 NITs with network id 910
163 NITs with network id 920
163 NITs with network id 942
164 NITs with network id 990

I hope the output helps. If you prefare full files i can attatch them.

comment:17 Changed 11 years ago by AntiCat

32769 4096 blocks remain
32755 NIT, 32755 NITo, 0 other
327 NITs with network id 1
655 NITs with network id 2
655 NITs with network id 3
655 NITs with network id 4
655 NITs with network id 5
655 NITs with network id 6
655 NITs with network id 100
655 NITs with network id 139
655 NITs with network id 201
655 NITs with network id 202
655 NITs with network id 203
655 NITs with network id 204
655 NITs with network id 205
655 NITs with network id 206
655 NITs with network id 207
655 NITs with network id 273
655 NITs with network id 274
655 NITs with network id 275
655 NITs with network id 277
654 NITs with network id 298
654 NITs with network id 299
654 NITs with network id 300
654 NITs with network id 301
654 NITs with network id 317
654 NITs with network id 400
655 NITs with network id 401
655 NITs with network id 402
655 NITs with network id 403
655 NITs with network id 404
655 NITs with network id 410
654 NITs with network id 433
654 NITs with network id 480
656 NITs with network id 502
656 NITs with network id 600
656 NITs with network id 601
656 NITs with network id 602
656 NITs with network id 603
656 NITs with network id 604
327 NITs with network id 605
656 NITs with network id 735
656 NITs with network id 800
656 NITs with network id 860
656 NITs with network id 880
656 NITs with network id 888
656 NITs with network id 890
656 NITs with network id 891
656 NITs with network id 892
655 NITs with network id 910
655 NITs with network id 920
655 NITs with network id 942
655 NITs with network id 990

Changed 11 years ago by Janne Grunau

Attachment: t5545_fix1.diff added

comment:18 Changed 11 years ago by Janne Grunau

Status: acceptedstarted

t5545_fix1.diff hopefully fixes the issue

The DVB tables have all empty destructors but since the data gets copied in the constructor they all would leak memory. Since we keep track of all the tables except of the NIT other the leak is rather small if no NIT others are transmitted.

comment:19 Changed 11 years ago by Janne Grunau

Resolution: fixed
Status: startedclosed

(In [19705]) implement DVBStreamData::DeleteCachedTable? to properly delete cached NITs and SDTs

it needs to be implemented in ScanStreamData? too due to multiple inheritance Fixes #5545

comment:20 Changed 11 years ago by Janne Grunau

(In [19706]) backports [19705] from trunk. Refs #5545

implement DVBStreamData::DeleteCachedTable? to properly delete cached NITs and SDTs it needs to be implemented in ScanStreamData? too due to multiple inheritance

Note: See TracTickets for help on using tickets.