Memory Leaks Detected when creating & destroying large volume of connections.

[adedomin]

• SerialPort Version: 4.0.7

• NodeJS Version: 4.6.0, 4.8.2, 6.10.3

• Operating System and Hardware Platform: Debian Jessielite (armv8 - RaspPi 3 - nodesource v4), Debian Sid (x86_64), Fedora 25 (x86_64)

• Have you checked the right version of the api docs?: yes

• Are you having trouble installing and you checked the Installation Special Cases docs?: no, n/a

• Are you using Electron and have you checked the Electron Docs?: no, n/a

Summary of Problem

opening and closing many connections causes memory leaks.

Steps and Code to Reproduce the Issue

any large number of opens and closes seems to cause a massive memory leak over a period of time

below is the most extreme example I could make; I used a pseudo terminal for testing on the x86 platforms.
you can set up a test using socat -d -d pty,raw,echo=0 pty,raw,echo=0 and then consuming one of the pty's it allocates with cat /dev/pts/something and then using the other as the path parameter for the SerialPort object constructor.

var SerialPort = require('serialport'),
    port

var forever = () => {
    port = new SerialPort('/dev/pts/something', { baudRate: 38400 })
    port.on('open', (err) => {
        if (err) {
            console.log(err)
            return setImmediate(() => forever())
        }
        port.write('yyyyyyyyyyyyyyy\n', (err) => { 
            if (err) console.log(err)
            port.close((err) => {
                if (err) console.log(err)
                setImmediate(() => forever())
            }) 
        })
    })
}
forever()

More information forthcoming...

[reconbot]

Always good stuff to know about. I'd appreciate testing on 5x beta as well. However there are no known leaks in either.

…

--- Francis Gulotta [email protected]

On Fri, Jun 9, 2017 at 3:51 PM, Anthony DeDominic ***@***.***> wrote: - *SerialPort Version*: 4.0.7 - *NodeJS Version*: 4.6.0, 4.8.2, 6.10.3 - *Operating System* and *Hardware Platform*: Debian Jessielite (armv8 - RaspPi 3 - nodesource v4), Debian Sid (x86_64), Fedora 25 (x86_64) - Have you checked the right *version* of the *api docs?*: yes - Are you having trouble installing and you checked the *Installation Special Cases* docs?: no, n/a - Are you using *Electron* and have you checked the *Electron Docs*?: no, n/a Summary of Problem opening and closing many connections causes memory leaks. Steps and Code to Reproduce the Issue any large number of opens and closes seems to cause a massive memory leak over a period of time below is the most extreme example I could make; I used a pseudo terminal for testing on the x86 platforms. you can set up a test using socat -d -d pty,raw,echo=0 pty,raw,echo=0 and then consuming one of the pty's it allocates with cat /dev/pts/something and then using the other as the path parameter for the SerialPort object constructor. var SerialPort = require('serialport'), port var forever = () => { port = new SerialPort('/dev/pts/something', { baudRate: 38400 }) port.on('open', (err) => { if (err) { console.log(err) return setImmediate(() => forever()) } port.write('yyyyyyyyyyyyyyy\n', (err) => { if (err) console.log(err) port.close((err) => { if (err) console.log(err) setImmediate(() => forever()) }) }) }) } forever() More information forthcoming... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1187>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABlbkSmV5UD_tm70DWeCk2R3gs46pJoks5sCaJEgaJpZM4N1xDn> .

[adedomin]

What i can say right now is, I have a raspberry pi device in the field and when someone disconnects the serial (USB) cable while configured a certain way, it constantly recreates SerialPort Objects which results a slow increase of memory that can't be reclaimed; this ultimately results in some form of out of memory error in about a week of time.

I decided to explore the memory leak in detail, using tools like heapdump--findable on npm.
What I found was an increase in V8's resident set but not the javascript heap size portion. most of the unreclaimed memory isn't from javascript as far as I can see, as new/old pieces don't account for the massive increase in the resident set size.

I'm going to try further debugging and let you know what i find.

EDIT: also I'll try the beta release as well.

EDIT2: this example doesn't seem to be consistent with the issues I'm seeing in further testing. also changing the on('open') to once('open') has fixed the leak this example finds....which confuses me since i figured the gc would remove all the event emitters.
I'll reopen when I find a better example and more info.

[adedomin]

other note, this example code doesn't appear to work on the [email protected]. so that's good news.