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

Mailing List Archive: MythTV: Users

`Mythbackend leaks memory` continued

 

 

First page Previous page 1 2 3 4 Next page Last page  View All MythTV users RSS feed   Index | Next | Previous | View Threaded


udovdh at xs4all

Jun 22, 2008, 5:32 AM

Post #1 of 99 (1762 views)
Permalink
`Mythbackend leaks memory` continued

Hello,

The system is backup again. Mythbackend appears to be recording again.

About the valgrind trick:
What is the way I am suppsed to run the tool?

`valgrind [insert normal mythbackend command line here] 2>
valgrindlog.txt` ?

Any suggestions?

Kind regards,
Udo

PS: I am willing to try valgrind for a limited time; I fera the machine
will be slowed down even below normal usable speeds but if we could
catch a leak within say 24 hours...
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


jan.ceuleers at computer

Jun 22, 2008, 6:25 AM

Post #2 of 99 (1730 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Udo van den Heuvel wrote:
> Hello,
>
> The system is backup again. Mythbackend appears to be recording again.
>
> About the valgrind trick:
> What is the way I am suppsed to run the tool?
>
> `valgrind [insert normal mythbackend command line here] 2>
> valgrindlog.txt` ?
>
> Any suggestions?

From man valgrind:

SYNOPSIS
valgrind [[valgrind] [options]] [your-program] [[your-program-options]]

....
--log-file=<filename>
Specifies that Valgrind should send all of its messages to the
specified file. In fact, the file name used is created by
concatenating the text filename, "." and the process ID, (ie.
<filename>.<pid>), so as to create a file per process. The
specified file name may not be the empty string.

--log-file-exactly=<filename>
Just like --log-file, but the suffix ".pid" is not added. If you
trace multiple processes with Valgrind when using this option
the log file may get all messed up.

So you could try:

valgrind --log-file-exactly=/tmp/mythbackend.valgrind.log [insert
normal mythbackend command line here]

Cheers, Jan
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


udovdh at xs4all

Jun 22, 2008, 6:55 AM

Post #3 of 99 (1731 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Jan Ceuleers wrote:
> So you could try:
>
> valgrind --log-file-exactly=/tmp/mythbackend.valgrind.log [insert
> normal mythbackend command line here]

Thanks,
Will let it run tonight until tomorrow afternoon when I get back from work.

Kind regards,
Udo
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


udovdh at xs4all

Jun 22, 2008, 10:44 AM

Post #4 of 99 (1722 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Udo van den Heuvel wrote:
> Jan Ceuleers wrote:
>> So you could try:
>>
>> valgrind --log-file-exactly=/tmp/mythbackend.valgrind.log [insert
>> normal mythbackend command line here]
>
> Thanks,
> Will let it run tonight until tomorrow afternoon when I get back from work.

Well, just gave it a go.
MythWeb doesn't show recording activity but the log does, as well as a
bunch of:

2008-06-22 19:39:19.536 DevRdB(0) Error: Driver buffers overflowed
2008-06-22 19:39:26.437 DevRdB(0) Error: Driver buffers overflowed
2008-06-22 19:39:33.697 DevRdB(0) Error: Driver buffers overflowed
2008-06-22 19:39:40.409 DevRdB(0) Error: Driver buffers overflowed
2008-06-22 19:39:47.446 DevRdB(0) Error: Driver buffers overflowed
2008-06-22 19:39:55.415 DevRdB(0) Error: Driver buffers overflowed
2008-06-22 19:40:02.514 DevRdB(0) Error: Driver buffers overflowed

So I don't think the backend will do much work tonight.
No, these errors normally don't occur.

As the behaviour of the system is being influenced quite a lot valgrind
might not find the assumed leaks. (?)

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


nick.rout at gmail

Jun 22, 2008, 12:44 PM

Post #5 of 99 (1721 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

On Mon, Jun 23, 2008 at 7:03 AM, Ray Lischner <linux[at]tempest-sw.com> wrote:
> On Sunday 22 June 2008 08:32 am, Udo van den Heuvel wrote:
>
>> PS: I am willing to try valgrind for a limited time; I fera the
>> machine will be slowed down even below normal usable speeds but if we
>> could catch a leak within say 24 hours...
>
> Valgrind is a useful tool, but not the right tool in this situation.
> First, we need to ascertain whether the leak exists. Valgrind is a
> developer's tool to help locate the source of the leak.
>
> Most of us are running mythbackend for days, weeks, or months, without
> any memory problems, which demonstrates that in normal code paths,
> there are no leaks. There might be leaks on other code paths. The
> difficulty is identifying those code paths.
>
> Whoever is experiencing mythbackend running out of memory needs to:
> 1. Verify that mythbackend truly is running out of memory. Watch the
> virtual memory size (VIRT) and the resident set size (RES) in top.
> Watch VIRT over time. Does it increase forever? Does it sometimes go
> down. If so, when? It isn't always easy for a user to find a memory
> leak, but if the backend runs long enough, and the leak is real, the
> numbers will show it.
> 2. Verify that the behavior is repeatable. Reboot the backend and try it
> again.
> 3. Determine what about that user's environment is different, unusual,
> or unique. Post details so others can try similar setups. If no one
> else can reproduce the problem, there is no hope of fixing it. This is
> the hard part, but is absolutely crucial.
>
> I'm not a myth developer, but I am a software developer who has used
> valgrind a lot, including on projects bigger than myth.


I suspect this is quite frustrating for Udo. He recently started a
long thread in which he was criticised for not running valgrind to
support a bug ticket that he filed (and I joined in briefly).

http://www.gossamer-threads.com/lists/mythtv/users/338087

Now you are saying valgrind is the wrong tool. I feel a bit sorry for
Udo if that is the case.
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mythtv at vulturest

Jun 22, 2008, 6:26 PM

Post #6 of 99 (1708 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Nick Rout wrote:
>> I'm not a myth developer, but I am a software developer who has used
>> valgrind a lot, including on projects bigger than myth.
>
>
> I suspect this is quite frustrating for Udo. He recently started a
> long thread in which he was criticised for not running valgrind to
> support a bug ticket that he filed (and I joined in briefly).
>
> http://www.gossamer-threads.com/lists/mythtv/users/338087
>
> Now you are saying valgrind is the wrong tool. I feel a bit sorry for
> Udo if that is the case.

I don't. He has consistently evaded giving useful answers to questions
and as far as I can follow it, doesn't understand memory management in
Linux at all. The numbers that he was picking as "evidence" (40% of the
system memory) as far as I am concerned were the virtual size of the
process which is not a good indicator of how much memory the process is
actually using.

Udo, post the mythbackend line from top after restarting the backend and
then incrementally every 30 minutes (or whatever increment you feel
adequate to display the issue). In the meantime allow some recordings to
happen, buffers to be allocated and free'd etc. Then post the results
for the knowledgable users on this list to decipher and let you know if
you have anything to worry about.

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


udovdh at xs4all

Jun 23, 2008, 7:34 AM

Post #7 of 99 (1691 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Udo van den Heuvel wrote:
> Well, just gave it a go.
> MythWeb doesn't show recording activity but the log does, as well as a
> bunch of:
>
> 2008-06-22 19:39:19.536 DevRdB(0) Error: Driver buffers overflowed
> 2008-06-22 19:39:26.437 DevRdB(0) Error: Driver buffers overflowed
> 2008-06-22 19:39:33.697 DevRdB(0) Error: Driver buffers overflowed
> 2008-06-22 19:39:40.409 DevRdB(0) Error: Driver buffers overflowed
> 2008-06-22 19:39:47.446 DevRdB(0) Error: Driver buffers overflowed
> 2008-06-22 19:39:55.415 DevRdB(0) Error: Driver buffers overflowed
> 2008-06-22 19:40:02.514 DevRdB(0) Error: Driver buffers overflowed
>
> So I don't think the backend will do much work tonight.
> No, these errors normally don't occur.
>
> As the behaviour of the system is being influenced quite a lot valgrind
> might not find the assumed leaks. (?)

Just checking again now after coming hoem from work.
Mythbacked appears not to be recording any longer: the load has gone
down and no new MPG files are being created.
There is enough program data and mythweb still works.
It appears that no leak has been found.
Below is a log excerpt from around the time that the final MPG file was
written.

Kind regards,
Udo




2008-06-23 06:28:38.543 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:28:55.757 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:29:06.642 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:29:14.126 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:29:35.169 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:30:03.025 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:30:22.242 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:30:32.104 TVRec(4): Changing from RecordingOnly to None
2008-06-23 06:30:32.763 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:30:56.641 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:31:16.590 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:31:35.522 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:31:46.836 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:31:54.753 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:32:06.337 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:32:13.966 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:32:25.231 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:32:37.315 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:32:52.868 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:33:13.387 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:33:14.973 Finished recording NOS Hoogtepunten Studio
Sport: channel 3
2008-06-23 06:33:24.842 DevRdB(0) Error: Driver buffers overflowed
2008-06-23 06:34:32.584 TFW: Taking a long time to flush..
2008-06-23 06:38:31.956 Using runtime prefix = /usr
2008-06-23 06:38:34.395 Using localhost value of localhost
2008-06-23 06:38:37.689 New DB connection, total: 1
2008-06-23 06:38:38.557 Connected to database 'mythconverg' at host:
localhost
2008-06-23 06:38:39.397 Closing DB connection named 'DBManager0'
2008-06-23 06:38:39.781 Connected to database 'mythconverg' at host:
localhost
2008-06-23 06:38:40.695 New DB connection, total: 2
2008-06-23 06:38:40.905 Connected to database 'mythconverg' at host:
localhost
2008-06-23 06:38:41.511 Current Schema Version: 1214
2008-06-23 06:38:49.104 AFD: Opened codec 0x897d170, id(MPEG2VIDEO)
type(Video)
2008-06-23 06:38:49.622 AFD: codec MP3 has 2 channels
2008-06-23 06:38:50.069 AFD: Opened codec 0x897d760, id(MP3) type(Audio)
2008-06-23 06:38:57.511 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 37 21
2008-06-23 06:38:57.921 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 6
2008-06-23 06:38:57.952 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 7
2008-06-23 06:38:57.972 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 8
2008-06-23 06:38:57.989 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 9
2008-06-23 06:38:57.998 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 10
2008-06-23 06:38:58.252 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 11
2008-06-23 06:38:58.375 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 12
2008-06-23 06:38:58.382 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 13
2008-06-23 06:38:58.569 [mpeg2video @ 0x46cee0a0]invalid mb type in I
Frame at 0 14
2008-06-23 06:38:58.724 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 15
2008-06-23 06:38:58.890 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 16
2008-06-23 06:38:58.918 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 17
2008-06-23 06:38:58.919 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 18
2008-06-23 06:38:58.933 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 19
2008-06-23 06:38:58.938 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 20
2008-06-23 06:38:58.943 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 22
2008-06-23 06:38:58.949 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 23
2008-06-23 06:38:58.950 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 24
2008-06-23 06:38:58.953 [mpeg2video @ 0x46cee0a0]invalid mb type in I
Frame at 0 25
2008-06-23 06:38:58.953 [mpeg2video @ 0x46cee0a0]invalid mb type in I
Frame at 0 25
2008-06-23 06:38:58.958 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 26
2008-06-23 06:38:58.963 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 27
2008-06-23 06:38:58.971 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 28
2008-06-23 06:38:58.975 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 29
2008-06-23 06:38:59.081 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 30
2008-06-23 06:38:59.101 [mpeg2video @ 0x46cee0a0]invalid mb type in I
Frame at 0 31
2008-06-23 06:38:59.126 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 32
2008-06-23 06:38:59.310 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 33
2008-06-23 06:38:59.457 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 34
2008-06-23 06:38:59.664 [mpeg2video @ 0x46cee0a0]ac-tex damaged at 0 35
2008-06-23 06:38:59.951 [mpeg2video @ 0x46cee0a0]Warning MVs not available
2008-06-23 06:39:03.255 Preview: Grabbed preview
'/Myth/LiveTV/3_20080623040800.mpg' 704x576[at]159s
2008-06-23 06:39:58.984 Finished recording NOS Hoogtepunten Studio
Sport: channel 3
2008-06-23 06:42:41.348 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 06:58:48.346 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 07:15:38.073 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 07:32:33.687 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 07:50:01.166 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 08:06:09.060 Unknown socket closing
2008-06-23 08:06:16.279 MythSocket(135f9528:-1): writeStringList: Error,
socket went unconnected.
2008-06-23 08:06:28.967 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 08:23:41.938 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 08:41:18.073 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 08:59:05.651 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 09:09:14.366 Reschedule interrupted, will retry
2008-06-23 09:09:29.729 TVRec(1): ASK_RECORDING 1 -1 0 0
2008-06-23 09:09:31.229 TVRec(2): ASK_RECORDING 2 -1 0 0
2008-06-23 09:09:31.307 TVRec(5): ASK_RECORDING 5 -1 0 0
2008-06-23 09:09:31.349 TVRec(7): ASK_RECORDING 7 0 0 0
2008-06-23 09:09:31.387 TVRec(6): ASK_RECORDING 6 -1 0 0
2008-06-23 09:09:31.427 TVRec(4): ASK_RECORDING 4 -1 0 0
2008-06-23 09:09:31.472 TVRec(3): ASK_RECORDING 3 -1 0 0
2008-06-23 09:11:04.527 TVRec(1): Changing from None to RecordingOnly
2008-06-23 09:11:07.515 TVRec(1): HW Tuner: 1->1
2008-06-23 09:11:37.432 TVRec(1): Changing from RecordingOnly to None
2008-06-23 09:11:55.305 Finished recording Sesamstraat "Meedoen": channel 3
2008-06-23 09:12:00.275 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 09:12:05.100 Started recording: Sesamstraat "Meedoen":
channel 3 on cardid 1, sourceid 1
2008-06-23 09:12:10.857 Reschedule requested for id 0.
2008-06-23 09:15:35.681 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 09:33:02.202 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 09:51:05.581 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 10:09:33.010 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 10:26:22.069 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 10:43:24.595 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 11:02:06.757 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 11:05:52.674 Unknown socket closing
2008-06-23 11:06:05.495 MythSocket(6809180:-1): writeStringList: Error,
socket went unconnected.
2008-06-23 11:19:48.918 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 11:35:58.633 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 11:52:37.035 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 12:09:15.802 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 12:26:02.211 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 12:43:45.456 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 13:00:41.448 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 13:19:11.030 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 13:37:11.766 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 13:55:58.415 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 14:06:23.265 Unknown socket closing
2008-06-23 14:06:45.644 MythSocket(eda8f60:-1): writeStringList: Error,
socket went unconnected.
2008-06-23 14:14:16.771 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 14:32:20.518 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 14:49:45.316 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 15:07:52.017 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 15:25:19.318 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 15:27:25.243 Scheduled 33 items in 1038.3 = 0.23 match +
1038.06 place
2008-06-23 15:41:11.978 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 15:56:21.317 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 16:11:30.639 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min
2008-06-23 16:26:39.587 AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min



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


udovdh at xs4all

Jun 23, 2008, 7:37 AM

Post #8 of 99 (1684 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Udo van den Heuvel wrote:
> So I don't think the backend will do much work tonight.
> No, these errors normally don't occur.

BTW: mytbackend --resched cron jobs give this kind of results:

2008-06-23 11:05:15.543 Using runtime prefix = /usr
2008-06-23 11:05:15.677 Using localhost value of localhost
2008-06-23 11:05:21.467 New DB connection, total: 1
2008-06-23 11:05:23.173 Connected to database 'mythconverg' at host:
localhost
2008-06-23 11:05:24.451 Closing DB connection named 'DBManager0'
2008-06-23 11:05:24.661 Connected to database 'mythconverg' at host:
localhost
2008-06-23 11:05:25.200 New DB connection, total: 2
2008-06-23 11:05:25.263 Connected to database 'mythconverg' at host:
localhost
2008-06-23 11:05:26.152 Current Schema Version: 1214
2008-06-23 11:05:26.575 Connecting to backend server: 127.0.0.1:6543
(try 1 of 5)
2008-06-23 11:05:33.614 MythSocket(9e0d190:5): readStringList: Error,
timeout (quick).
2008-06-23 11:05:33.614 Unexpected response to MYTH_PROTO_VERSION:
2008-06-23 11:05:33.614 Cannot connect to master for reschedule

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


udovdh at xs4all

Jun 23, 2008, 8:14 AM

Post #9 of 99 (1691 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Johan Venter wrote:
> Linux at all. The numbers that he was picking as "evidence" (40% of the
> system memory) as far as I am concerned were the virtual size of the

Nope. ps man page:
%mem %MEM ratio of the process’s resident set size to the
physical
memory on the machine, expressed as a percentage.
(alias pmem).

top man page:
n: %MEM -- Memory usage (RES)
A task’s currently used share of available physical memory.

> Udo, post the mythbackend line from top after restarting the backend and
> then incrementally every 30 minutes (or whatever increment you feel
> adequate to display the issue).

I currently have a job that runs `ps aux` every morning, filters the
mythbackend line and logs it.

> In the meantime allow some recordings to
> happen, buffers to be allocated and free'd etc.

Normally it runs all the time.

> Then post the results
> for the knowledgable users on this list to decipher and let you know if
> you have anything to worry about.

Will do.
Does `ps aux` give the right numbers? (doubt it, from reading your comment)

Kind regards,
Udo

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


knowledgejunkie at gmail

Jun 23, 2008, 2:17 PM

Post #10 of 99 (1676 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

On 23/06/2008, Udo van den Heuvel <udovdh[at]xs4all.nl> wrote:
> Johan Venter wrote:
> > Then post the results
> > for the knowledgable users on this list to decipher and let you know if
> > you have anything to worry about.
>
>
> Will do.
> Does `ps aux` give the right numbers? (doubt it, from reading your comment)

Udo,

I use the following simple script to monitor the RSS (resident) and
VSZ (virtual) memory usage by mythbackend:

=== cut ===
#!/bin/bash

TIME=`/bin/date +%Y-%m-%d-%H%M`
CMD=`/bin/ps -C mythbackend -o rss=,vsz=`

echo "${TIME}: ${CMD}" >> /var/log/mythtv/memusage-mythbackend.log
=== cut ===

Nick

--
Nick Morrott

MythTV Official wiki:
http://mythtv.org/wiki/
MythTV users list archive:
http://www.gossamer-threads.com/lists/mythtv/users

"An investment in knowledge always pays the best interest." - Benjamin Franklin
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


udovdh at xs4all

Jun 24, 2008, 8:12 PM

Post #11 of 99 (1644 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Ray Lischner wrote:
> On Monday 23 June 2008 11:14 am, Udo van den Heuvel wrote:
>
>> I currently have a job that runs `ps aux` every morning, filters the
>> mythbackend line and logs it.
>
> Please post the logs. RSS and %MEM by themselves do not prove (or
> disprove) a memory leak, but watching VSZ and RSS change over time can
> be informative.

almost 2 days of data:

# cat /home/udo/psmyth.txt
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 4203 7.2 9.1 393468 88688 ? Ssl 16:34 4:27
root 4203 5.2 11.8 443152 115084 ? Ssl Jun23 39:17
root 4203 5.7 12.6 451428 122892 ? Ssl Jun23 126:25

(I removed the command line for readability)

One ps ran shortly after sytartup, next was the next morning and last
one was this morning.


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


udovdh at xs4all

Jun 25, 2008, 1:01 AM

Post #12 of 99 (1636 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Ray Lischner wrote:
> On Tuesday 24 June 2008 11:12 pm, Udo van den Heuvel wrote:
>
>> # cat /home/udo/psmyth.txt
>> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
>> COMMAND
>> root 4203 7.2 9.1 393468 88688 ? Ssl 16:34 4:27
>> root 4203 5.2 11.8 443152 115084 ? Ssl Jun23 39:17
>> root 4203 5.7 12.6 451428 122892 ? Ssl Jun23 126:25
>>
>> (I removed the command line for readability)
>>
>> One ps ran shortly after sytartup, next was the next morning and last
>> one was this morning.
>
> An increase by 10% in virtual memory size is not significant. Keep
> running and observing. That may be the first indication of a leak, but
> it's too soon to tell.


I know, but to give you an impression of the early situation. Better to
compare to say next weeks results.

> How much RAM and swap are available on this system?

# free
total used free shared buffers cached
Mem: 970780 959808 10972 0 2288 782068
-/+ buffers/cache: 175452 795328
Swap: 3911788 34400 3877388

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


belcampo at zonnet

Jun 25, 2008, 1:46 AM

Post #13 of 99 (1625 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Udo van den Heuvel wrote:
> Ray Lischner wrote:
>> On Tuesday 24 June 2008 11:12 pm, Udo van den Heuvel wrote:
>>
>>> # cat /home/udo/psmyth.txt
>>> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
>>> COMMAND
>>> root 4203 7.2 9.1 393468 88688 ? Ssl 16:34 4:27
>>> root 4203 5.2 11.8 443152 115084 ? Ssl Jun23 39:17
>>> root 4203 5.7 12.6 451428 122892 ? Ssl Jun23 126:25
>>>
>>> (I removed the command line for readability)
>>>
>>> One ps ran shortly after sytartup, next was the next morning and last
>>> one was this morning.
>> An increase by 10% in virtual memory size is not significant. Keep
>> running and observing. That may be the first indication of a leak, but
>> it's too soon to tell.
>
>
> I know, but to give you an impression of the early situation. Better to
> compare to say next weeks results.
>
>> How much RAM and swap are available on this system?
>
> # free
> total used free shared buffers cached
> Mem: 970780 959808 10972 0 2288 782068
> -/+ buffers/cache: 175452 795328
> Swap: 3911788 34400 3877388
I see swap is 'touched' although you have a fair amount of memory, I had
problems which seem to be related to mythcommflag.
I don't know if you do commflagging, but I got this with a hard lock-up
3606 root 32 17 871m 383m 1460 D 0.6 81.2 13:21.02 mythcommflag
with 512MB memory and 512MB swap.
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users[at]mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


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


udovdh at xs4all

Jun 25, 2008, 4:12 AM

Post #14 of 99 (1614 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

belcampo wrote:
>>> How much RAM and swap are available on this system?
>> # free
>> total used free shared buffers cached
>> Mem: 970780 959808 10972 0 2288 782068
>> -/+ buffers/cache: 175452 795328
>> Swap: 3911788 34400 3877388
> I see swap is 'touched' although you have a fair amount of memory, I had
> problems which seem to be related to mythcommflag.
> I don't know if you do commflagging,

Due to the lack of real CPU power (1.2 Ghz VIA C7 on VIA EN12000 board)
we don't run any jobs like mythcommflag.

Kind egards,
Udo
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


udovdh at xs4all

Jun 28, 2008, 10:11 PM

Post #15 of 99 (1509 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Ray Lischner wrote:
> An increase by 10% in virtual memory size is not significant. Keep
> running and observing. That may be the first indication of a leak, but
> it's too soon to tell.

%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

A bit sooner than planned but these results already give some trend
info. Memory related ficgures only go up after the first set of numbers.
Interestingly the CPU doesn't appear to be stable after the first sample
(which was not at the same time of day as the others).
The CPU-time per day (see TIME collumn) isn't a steady increasing number.

What do we see here? Do you need a graph?

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


udovdh at xs4all

Jul 2, 2008, 7:31 AM

Post #16 of 99 (1413 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Udo van den Heuvel wrote:
> Ray Lischner wrote:
>> An increase by 10% in virtual memory size is not significant. Keep
>> running and observing. That may be the first indication of a leak, but
>> it's too soon to tell.

Well, we can start over again. The backend crashed:

mythbackend[4222]: segfault at 0 ip 42eb09df sp b2b84690 error 4 in
libqt-mt.so.3.3.8[428da000+837000]

(all the time just the backend, no frontend or anything)

The (final...) table of memory sizes, etc:

%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

A steady growth from the second sample on.
Is the a leak?
Is this normal?
Can this be explained?

Why did the backend crash in the qt lib?
(doesn't qt do somethign with the gui? No gui has been active for the
backend...)

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


nick.rout at gmail

Jul 2, 2008, 3:25 PM

Post #17 of 99 (1402 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

On Thu, Jul 3, 2008 at 9:28 AM, Ray Lischner <linux[at]tempest-sw.com> wrote:
> On Wednesday 02 July 2008 10:31 am, Udo van den Heuvel wrote:
>
>> A steady growth from the second sample on.
>> Is the a leak?
>> Is this normal?
>> Can this be explained?
>
> It looks like a leak to me. The problem, however, is that most Myth
> users do not experience a leak. Therefore, something about your system
> is different from ours. In particular, it is different from the systems
> that the developers use.
>
> That's why the next step is to try to associate the leak with some other
> behavior of the backend, e.g., recording, playback, plug-ins, etc.
>
> Also, what distribution are you using? What version of Qt? Mysql client?
>
>> Why did the backend crash in the qt lib?
>> (doesn't qt do somethign with the gui? No gui has been active for the
>> backend...)
>
> I can't say why it crashed, but Qt is more than just a GUI library. It
> has basic utilities, threads, networking, and more.
> --
> Ray Lischner
>

IIRC Udo was using his backend to record a number of channels
continuously, like every programme! That seems to be the only
difference in his system identified to date.

So its an "edge" case, but edge cases have a way of throwing up errors
that "normal" use may not throw up. Errors that ideally should still
be fixed, but that may have a lower priority to errors that affect
many more users (resources being finite and all that).

But steady growth in memory use doesn't necessarily imply a leak,
mightn't it be that there is simply a lot of buffers used, which will
get thrown away eventually. The process still only seems to have a
%MEM of 19.9 on the last reading.
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


udovdh at xs4all

Jul 3, 2008, 9:42 AM

Post #18 of 99 (1375 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Ray Lischner wrote:
> On Wednesday 02 July 2008 10:31 am, Udo van den Heuvel wrote:
>
>> A steady growth from the second sample on.
>> Is the a leak?
>> Is this normal?
>> Can this be explained?
>
> It looks like a leak to me. The problem, however, is that most Myth
> users do not experience a leak. Therefore, something about your system
> is different from ours. In particular, it is different from the systems
> that the developers use.
>
> That's why the next step is to try to associate the leak with some other
> behavior of the backend, e.g., recording, playback, plug-ins, etc.
>
> Also, what distribution are you using? What version of Qt? Mysql client?

Fedora 9
Qt 4.3.5
mysql 5.0.51a

>> Why did the backend crash in the qt lib?
>> (doesn't qt do somethign with the gui? No gui has been active for the
>> backend...)
>
> I can't say why it crashed, but Qt is more than just a GUI library. It
> has basic utilities, threads, networking, and more.

Just now I see there is a qt update.
Perhaps do a fresh build after this qt update?


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


udovdh at xs4all

Jul 3, 2008, 9:46 AM

Post #19 of 99 (1375 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Nick Rout wrote:
> IIRC Udo was using his backend to record a number of channels
> continuously, like every programme! That seems to be the only
> difference in his system identified to date.

I just use mythtv to record.

> So its an "edge" case,

Indeed, a very extreme difference.

> that "normal" use may not throw up. Errors that ideally should still
> be fixed, but that may have a lower priority to errors that affect
> many more users (resources being finite and all that).

Why speculate on that when we even don't know WHERE the error is or WHAT
is wrong. Or HOW we can find out what is wrong where when we can't run
valgrind?

If the code is valgrind-proof under 'normal' use the error must be in
the code that has to do with my peculiar use of MythTV.
I limit the scheduler to 8 hours ahead with some SQL.
I use multirec.
Also I use three searches, one for each channel. Maybe I could combine
these and see a different memory growth rate?
What ideas do you have?

> But steady growth in memory use doesn't necessarily imply a leak,
> mightn't it be that there is simply a lot of buffers used, which will
> get thrown away eventually. The process still only seems to have a
> %MEM of 19.9 on the last reading.

Just hope it doesn't crash.
It may reach the 40% I mentioned earlier.
It just continues to grow. It doesn't get smaller.
Please believe me.

Kind regards,
Udo
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


udovdh at xs4all

Jul 3, 2008, 9:49 AM

Post #20 of 99 (1371 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Udo van den Heuvel wrote:
>> Also, what distribution are you using? What version of Qt? Mysql client?
>
> Fedora 9
> Qt 4.3.5

qt3 3.3.8 for 21-fixex...
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


cal at graggrag

Jul 3, 2008, 10:15 AM

Post #21 of 99 (1376 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Udo van den Heuvel wrote:
> Udo van den Heuvel wrote:
>>> Also, what distribution are you using? What version of Qt? Mysql client?
>> Fedora 9
>> Qt 4.3.5
>
> qt3 3.3.8 for 21-fixex...

No, you want 3.3.8b, which includes a mysql fix of importance for 0.21-fixes.

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


udovdh at xs4all

Jul 3, 2008, 11:13 AM

Post #22 of 99 (1367 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

cal wrote:
> Udo van den Heuvel wrote:
>> Udo van den Heuvel wrote:
>>>> Also, what distribution are you using? What version of Qt? Mysql client?
>>> Fedora 9
>>> Qt 4.3.5
>> qt3 3.3.8 for 21-fixex...
>
> No, you want 3.3.8b, which includes a mysql fix of importance for 0.21-fixes.

Thanks.
That one was in the updates that I mentioned.
Just built with those.

So the current run could crash just like the recent one.
Then I could upgrade and see the difference.


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


nick.rout at gmail

Jul 3, 2008, 12:42 PM

Post #23 of 99 (1357 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

On Fri, Jul 4, 2008 at 6:13 AM, Udo van den Heuvel <udovdh[at]xs4all.nl> wrote:
>
> Thanks.
> That one was in the updates that I mentioned.
> Just built with those.
>
> So the current run could crash just like the recent one.
> Then I could upgrade and see the difference.

Its not a fix (and no one even knows if you need a fix) but why not
restart mythbackend every 24 hours or so?

Also you have reached 40% mem without a crash, yet the QT crash
occurred at about 20%, so it seems to me the two are likely unrelated.

Also multirec is relatively new. There may be bugs. No software is bug free.
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


udovdh at xs4all

Jul 4, 2008, 5:33 AM

Post #24 of 99 (1339 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

Nick Rout wrote:
> On Fri, Jul 4, 2008 at 6:13 AM, Udo van den Heuvel <udovdh[at]xs4all.nl> wrote:
>> Thanks.
>> That one was in the updates that I mentioned.
>> Just built with those.
>>
>> So the current run could crash just like the recent one.
>> Then I could upgrade and see the difference.
>
> Its not a fix (and no one even knows if you need a fix) but why not
> restart mythbackend every 24 hours or so?

A restart is a windo-ism.
Of course it is an effective workaround but not more than that.

> Also you have reached 40% mem without a crash, yet the QT crash
> occurred at about 20%, so it seems to me the two are likely unrelated.

I may have rebuilt the code in between. I most certainly did because of
my harddisk failure.
I did not imply any relation but just found it worth mentioning.

> Also multirec is relatively new. There may be bugs. No software is bug free.

Sure.
But I am just using the very core functionality of MythTV, right?
I am not even posting here about mythfrontend.
This is backend only.
So I guess if I indeed have found a bug (which is to be determined of
course) it is worth repairing.

Whoever wants to do similar stuff as I do (record multiple channels
using multirec continuously) on a more potent machien can contact me for
configuration specifics. There is nothing truly special here.
If you can reproduce the memory growth you can then use valgrind to find
the spot of the error.

Kind regards,
Udo
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


nick.rout at gmail

Jul 4, 2008, 8:00 PM

Post #25 of 99 (1298 views)
Permalink
Re: `Mythbackend leaks memory` continued [In reply to]

On Sat, Jul 5, 2008 at 12:33 AM, Udo van den Heuvel <udovdh[at]xs4all.nl> wrote:
> Nick Rout wrote:
>
>> Also you have reached 40% mem without a crash, yet the QT crash
>> occurred at about 20%, so it seems to me the two are likely unrelated.
>
> I may have rebuilt the code in between. I most certainly did because of
> my harddisk failure.
> I did not imply any relation but just found it worth mentioning.

Is there a particular reason that you are building it yourself, rather
than using one of the pre-built distros?

If you did build it yourself twice, and there is a difference in
behaviour, then can you identify the differences in your buiild
environment? (different library versions, different compiler version,
etc.)
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

First page Previous page 1 2 3 4 Next page Last page  View All MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.