Voice Leaks

[Deivu]

Please describe the problem you are having in as much detail as possible: I Opened this same issue in past, but that time I don't have too much evidence about this leak. From that moment, I tried to debug this via dumping heapdumps and tracking it inside d.js voice code & my code and it seems like it was really leaking. Previous Heapdumps shows that "FFmpegTransform", "Encoder" & "VolumeTransformer16LE" arent getting gced and just piles up overtime, IF the dispatcher ended prematurely (when the writer stream ended without even draining the data from the readable stream). So what I did is I tried various libs from npm, and it seemed to work fine, so I tested it again with prism-media, but this time, what I did is to make sure to that all the streams are getting closed and It seems this fixes this issue.

Old Memory Usage on 20k servers 58H of uptime. https://cdn.discordapp.com/attachments/450644221410410506/490741735501201418/Untitled.png

New Memory Usage on 28k servers 43H of uptime. https://cdn.discordapp.com/attachments/450644221410410506/512826205079339010/unknown.png

Further details:

• discord.js version: discordjs/discord.js#01476de58250761ffe5eedc9ee6c9782576ca043

• Node.js version: 10.12.0

• Operating system: Ubuntu 18.04 LTS

• Priority this issue should have – please be realistic and elaborate if possible: Low - Medium because I assume most of the big bots now use Lavalink.

• [ ] I have also tested the issue on latest master, commit hash:

• [ ] I found this issue while running code on a user account

[amishshah]

Hi sorry for such a late reply, can you confirm whether or not you can still reproduce this issue?

[amishshah]

Can you also clarify as to how you're making sure all the streams are being closed?

[Deivu]

Yes you could reproduce this issue if you use dispatcher.end() or dispatcher.destroy() to end the stream that is not yet done.

For closing basically, the streams that prism media creates, I try to close them manually instead of leaving them as is. Although this did not solve this 100%, it migrated it to a great degree.

[amishshah]

Recently encountered this and just made some commits that I think fix the issue, can you try them out and tell me if it fixes the issue?

[amishshah]

Note you'll also need to update your prism install

[Deivu]

Thanks for the response, I'll try this as soon as I was able to do so

[Deivu]

Ok Update about this, the commit did make the music more stable, but the issue when you are ending the streams early via dispatcher.end() makes the memory creep up a bit over time is still noticable

Code I used in testing this

    const stream = await ytdl(serverQueue.songs[0].url)
    const dispatcher = connection.play(stream, { type: 'opus', passes: 2, bitrate: 128 })
        .on('error', onError)
        .once('finish', async () => {
            dispatcher.removeListener('error', onError);
            serverQueue.songs.shift();
            await play(client, guild, serverQueue.songs[0]);
        });
    dispatcher.setVolumeLogarithmic(serverQueue.volume / 7.5);

[amishshah]

Could you try dispatcher.destroy() instead of end ()?

[Deivu]

destroy doesn't emit finish when I used it causing the music to be stucked, That's why I use dispatcher.end()

[amishshah]

That's really strange I'll have a look in the next hour or two

[amishshah]

@Deivu I think I've managed to fix it in https://github.com/discordjs/discord.js/commit/6aa792f9ab8008c22397d1a46a862fa88ba5aef5 could you give it a try? This means that the dispatcher will be cleaned up properly when using end()

[Deivu]

@amishshah Thanks for that commit, I do think right now the memory is much more stable than before. I will observe this for a few days and close it finally when I do see if it works as intended

As for test session, I limited my max old space size to 128mb to force the it to gc and see if there's still unusual behaviors in regard to this.

[amishshah]

That's great news so far! Good luck with your testing, let's hope this has finally fixed it.

[Deivu]

Closing this issue, I feel like its now the cache what makes the memory rise up, and for normal personal usage its fine.

[amishshah]

That's great news! Thanks for being so helpful and patient with the testing 🎉