Topic: glynor's instability and memory leaks (Read 5828 times)

glynor · « **on:** February 23, 2015, 10:51:55 pm »

I've been having an odd problem with builds 73 and 74.

When playing back video from my HTPC (MC client, with direct access to the files over my LAN), I'm getting two issues:

* Videos are sometimes "stuttering". It usually only happens in the first 5 minutes of playback (or so). There's a skip, then the audio and video get out of sync a bit, and then it fixes itself with another smaller hiccup 30 seconds or so later. This usually only happens once, but sometimes happens a handful of times, but always near the beginning of playback.

* Once this happens, MC will usually play fine throughout the video.

* Once this happens, however, when I hit stop, MC often crashes.

The usual is true. Nothing new on the system. Appeared just recently (I was on build 73 the first time I noticed it over the weekend, and then updated to build 74 hoping it would go away, but it didn't). It doesn't happen every time with every video, but it is common enough that I've seen it probably 5 or 6 times (in some version of the above) just over the past three or four days.

This last time I caught a log, which does have a crash dump:
http://glynor.com/files/jriver/JRiver%20Log%202015-02-23%2022-44-59.zip

glynor · « **Reply #1 on:** February 23, 2015, 10:57:17 pm »

I should also note, that I'm seeing what seems to be leak-like behavior on the server copy of MC.

Right now, MC 20.0.74 has been running on my server for just over 24-hours (since 10:47pm yesterday). Here's what I have right now, with MC minimized:

Memory usage was substantially lower this morning, and even lower last night. Handles seem to always be at the peak, and keep going up. Slowly, but up. And I think Matt previously said that 2700 handles was well into the "danger zone".

Hendrik · « **Reply #2 on:** February 24, 2015, 05:14:35 am »

Quote from: glynor on February 23, 2015, 10:57:17 pm

I should also note, that I'm seeing what seems to be leak-like behavior on the server copy of MC.

Right now, MC 20.0.74 has been running on my server for just over 24-hours (since 10:47pm yesterday). Here's what I have right now, with MC minimized:

<snip>

Memory usage was substantially lower this morning, and even lower last night. Handles seem to always be at the peak, and keep going up. Slowly, but up. And I think Matt previously said that 2700 handles was well into the "danger zone".

Can you send me Process Explorers handle listing? That might indicate where the problem lies.

glynor · « **Reply #3 on:** February 24, 2015, 07:47:29 am »

Quote from: Hendrik on February 24, 2015, 05:14:35 am

Can you send me Process Explorers handle listing? That might indicate where the problem lies.

Unfortunately, I closed it down last night soon after I posted that, so that I could check to make sure I wasn't crazy and that the memory usage was way out of the normal range.

It was. After it had run for around 30 minutes or so and settled down, I was seeing a total virtual size of 165MB, much lower private bytes, and handles around 600. So, I don't have a listing from the process as it was running last night.

This morning (after doing absolutely nothing but sit idle all night), it is here:

Listing:
http://glynor.com/files/jriver/Media%20Center%2020.exe-20150224-Handles.txt

I can leave it running and generate another one later tonight or tomorrow if you'd like.

Hendrik · « **Reply #4 on:** February 24, 2015, 08:54:36 am »

Quote from: glynor on February 24, 2015, 07:47:29 am

Unfortunately, I closed it down last night soon after I posted that, so that I could check to make sure I wasn't crazy and that the memory usage was way out of the normal range.

It was. After it had run for around 30 minutes or so and settled down, I was seeing a total virtual size of 165MB, much lower private bytes, and handles around 600. So, I don't have a listing from the process as it was running last night.

This morning (after doing absolutely nothing but sit idle all night), it is here:

It seems to be hung up on two FLAC files, not sure why:
File M:\Incoming\Parov Stelar - Discography\Parov Stelar - 2008 - Single Collection 2\Parov Stelar - Single Collection 2.flac
File M:\Incoming\Parov Stelar - Discography\Parov Stelar - 2007 - Single Collection\Parov Stelar - Single Collection.flac

There are hundreds of entries for those.

I don't suppose it's in the realm of possibility to share one of those two, so we can see whats wrong with them? (Including any CUE files, if they have any)

JimH · « **Reply #5 on:** February 24, 2015, 09:17:30 am »

Funny title.

marko · « **Reply #6 on:** February 24, 2015, 10:16:15 am »

Yeah, I thought Ed had gone off the rails and came in to see if I could help

glynor · « **Reply #7 on:** February 24, 2015, 10:43:55 am »

Quote from: marko on February 24, 2015, 10:16:15 am

Yeah, I thought Ed had gone off the rails and came in to see if I could help

Oh, I have.

Quote from: Hendrik on February 24, 2015, 08:54:36 am

I don't suppose it's in the realm of possibility to share one of those two, so we can see whats wrong with them? (Including any CUE files, if they have any)

But of course...
http://glynor.com/files/jriver/Handles-FLAC-CUE.zip

NOTE: It is still uploading. Should be done in around 1:00pm EST.

glynor · « **Reply #8 on:** February 24, 2015, 10:56:36 am »

While that uploads, figured it was worth re-checking. Here's where I'm at now:

http://glynor.com/files/jriver/Media%20Center%2020.exe-20150224-Handles2.txt

And, I figured this might help:
http://glynor.com/files/jriver/Media%20Center%2020_HandlesMiniDump1.zip

Matt · « **Reply #9 on:** February 24, 2015, 11:02:09 am »

The handle leak is certainly those FLAC files staying open. Hopefully Hendrik will have some luck (if you need help Hendrik, just say).

glynor · « **Reply #10 on:** February 24, 2015, 02:24:09 pm »

Just confirming, that file did upload, so use the link above. Here's a SHA-1 in case:
CB1460B402CAFFB88C99E79E21841F077C5BFDE3

Hendrik · « **Reply #11 on:** February 25, 2015, 02:54:46 am »

I found the leak, it leaked both handles and memory.
I'm somewhat curious why this wasn't being noticed before, it didn't seem like anything that changed recently. It looks like it was triggered from having both an embedded CUE and an external CUE file.

6233638 · « **Reply #12 on:** February 25, 2015, 08:16:34 am »

Quote from: Hendrik on February 25, 2015, 02:54:46 am

I found the leak, it leaked both handles and memory.
I'm somewhat curious why this wasn't being noticed before, it didn't seem like anything that changed recently. It looks like it was triggered from having both an embedded CUE and an external CUE file.

I have noticed some instability recently, so I wonder if it could be related. MC never seems to create crash dumps for me (never has) and I try not to post things like "it's crashing at random" unless there's any kind of pattern I can see. (or it's so frequent that it becomes a serious issue)

glynor · « **Reply #13 on:** February 25, 2015, 08:48:29 am »

Quote from: Hendrik on February 25, 2015, 02:54:46 am

I'm somewhat curious why this wasn't being noticed before

I think I mentioned it once before (the leaking, and those specific files). Anyway, thanks!

I'll let you know if it seems sorted, and if this change has any impact on my other issues with video playback. I'm dubious about the latter, which I think is more likely to do with sleeping drive spin-up.

kstuart · « **Reply #14 on:** February 25, 2015, 11:40:31 am »

Quote from: Hendrik on February 25, 2015, 02:54:46 am

I found the leak, it leaked both handles and memory.
I'm somewhat curious why this wasn't being noticed before, it didn't seem like anything that changed recently. It looks like it was triggered from having both an embedded CUE and an external CUE file.

Which build will have the leak fix ? Thanks.

glynor · « **Reply #15 on:** February 26, 2015, 11:28:50 pm »

Oh yeah... I'd meant to reply but I wanted to wait until the build was public, and then the beta thread got locked and 79 came out and I didn't do a good job recording my stats last time.

Anyway, thanks Hendrik. This seems to have fixed my handles leak, at least largely. All of those handles for those dumb Parov Stellar albums are GONE.

I do want to watch it again overnight tonight, though, to make sure that was all I was seeing. This morning with build 78 I was at ~870 handles after running overnight. I felt like the memory usage and handles count was a bit higher than it had been the night before, but unfortunately I didn't keep good records from before I went to bed. If memory serves, the private bytes were around 250,000k and virtual size was at 760,000k this morning. That seemed a bit higher I remembered seeing the night before, but like I said, I didn't have good records from just after installing .78 so I can't be sure.

In any case, it is way better. It would have been much, much worse (handles in the 1000s) after a night with the older builds, as you can see above.

As of right now, I started MC at ~7:20pm on 2/26 and it is now ~12:20am on 2/27 and I'm here:

I think that was what I was seeing, roughly, when I went to bed last night with .78. So, I'll check it in the morning and let you know if it still seems to be leaking a little. The biggest culprit by far was those albums though.

kstuart · « **Reply #16 on:** February 27, 2015, 12:32:36 pm »

Quote from: glynor on February 26, 2015, 11:28:50 pm

So, I'll check it in the morning and let you know if it still seems to be leaking a little.

... and ....

glynor · « **Reply #17 on:** February 27, 2015, 12:35:30 pm »

Quote from: kstuart on February 27, 2015, 12:32:36 pm

... and ....

I'll have to check when I get home. Child was not cooperating this morning.

glynor · « **Reply #18 on:** February 27, 2015, 10:45:28 pm »

Now. The same session as last night. Aside from importing some new recordings, and playing part of one kids show this evening (on a client copy of MC, the HTPC) the server has been idle. Here's the current stats on the server copy.

MC was minimized to the system tray in Media Server mode when that was taken.

Overall handles are fixed. Not so sure about memory usage. And I'm not sure if it matters, but that GDI Handles stat did seem to double (and isn't fluctuating by +/-100 like the overall handles count seems to sometimes, probably during import and whatnot).

Either way, the super-serious problem does seem to have been fixed. There might be a little more in there, though it is hard to tell. I'm not sure if a slowly climbing virtual memory private bytes and total size (private bytes are basically triple last night) are expected or something to worry about. Physical RAM usage is down, of course (but last night the full UI was running, and this is in the tray).

glynor · « **Reply #19 on:** February 27, 2015, 10:58:04 pm »

I just checked, because typing the last line made me think I should compare apples-to-apples. Restoring from the tray made no substantial difference. GDI Handles are now up to 306, but of course the UI is visible.

I have noticed, the drawing errors I see are worse when MC has been running a while. I have seen those issues tonight, with basically every restore from minimized/media server, but did not see last night when it was fresh. Restore from minimize performance seems more sluggish now too, a tad. Perhaps there's something to that GDI number?

Dunno.

I'm going to bed now. If you want memory dumps or anything just yell. I'll probably end up restarting it at some point tomorrow, but I can pull one before I do. If you aren't that worried about it, then cool. Thanks for fixing the stuck files I had there.

Trumpetguy · « **Reply #20 on:** March 01, 2015, 05:17:49 am »

Quote from: glynor on February 27, 2015, 10:58:04 pm

I have noticed, the drawing errors I see are worse when MC has been running a while. I have seen those issues tonight,

I have noticed a lot of those lately, on my 24/7 HTPC. They may have been there always, but I started noticing the past few weeks, or maybe couple of months. Playing around with maximize/re-size of windows usually fixes it and I haven't noticed it coming back in the current session.

glynor · « **Reply #21 on:** March 01, 2015, 10:14:18 am »

Still haven't relaunched MC:

MC now has the largest Private Bytes size of any application running on my system, including a running VM.

Hendrik · « **Reply #22 on:** March 01, 2015, 10:40:48 am »

Memory consumption is practically impossible to debug without the ability to reproduce it, unfortunately.
You could post a new handle listing though, ~840 seems high for a idle MC, mine usually hangs out at ~350 even after days of running media server.

glynor · « **Reply #23 on:** March 01, 2015, 10:56:55 am »

Figured I might as well:

* Logs
* Full dump
* Handles listing

glynor · « **Reply #24 on:** March 01, 2015, 10:58:04 am »

Quote from: Hendrik on March 01, 2015, 10:40:48 am

Memory consumption is practically impossible to debug without the ability to reproduce it, unfortunately.

Yeah. I know it is difficult (and that being a massive understatement).

I'd been uploading the memory dump (now done), but I grabbed all the stuff I thought was relevant. The Handles value (overall) does seem to fluctuate by +/- 70-100. Right now, it is bouncing around 810.

glynor · « **Reply #25 on:** March 03, 2015, 12:21:10 am »

Hey! I hadn't yet restarted MC tonight. I didn't get any stats (I was going to do it before bed in a bit here), but while watching a show, MC just crashed. I was seeking backwards in a video file, and it crashed. I got a log, and it does have a crash dump.

http://glynor.com/files/jriver/JRiver%20Log%202015-03-03%2001-15-56.zip

I don't know, of course, if this crash was related to or might show anything about the memory usage, or about something else entirely, but in any case, here it is.

Hendrik · « **Reply #26 on:** March 03, 2015, 10:09:31 am »

That was an odd crash, but I did simplify the code a bit and add a few safe guards, hopefully it shouldn't happen again.

INTERACT FORUM

Author Topic: glynor's instability and memory leaks (Read 5828 times)