[dir] still leaks file handles

[reduzent]

I'm afraid the bug isn't fixed. [dir] still leaks file handles. However, the process to trigger the leak is a bit different:

[reset, open ., dump(
|
[dir ]

It seems one file handle doesn't get properly closed when doing the above, as can seen with

lsof -c pd | wc -l 

Each iteration leaks exactly one handle.

[porres]

I'm afraid I don't know how to test this. I don't know what "lsof -c pd | wc -l" is :) - help?

[reduzent]

On a Linux machine, you can enter the whole line into a terminal. lsof lists all open files on the system, -c pd restricts it to the a command called pd. wc -l counts the number of lines. The way I test for leaks is to launch Pd and then I execute (in a Terminal window):

lsof -c pd | wc -l 

which will show something like:

93

which means that the pd process has currently 93 files open.

Then I send 'reset, open ., dump' to [dir] and execute above line again. If the number has increased, some filehandles are being leaked.

It's probably possible to do something similar on macOS, but I'm not sure about what name should be used for the pd process (the -c option for lsof).

[porres]

it's probably possible to do something similar on macOS, but I'm not sure about what name should be used for the pd process (the -c option for lsof).

seems to be working, and I get an extra open file every time I use the 'open' message, how about you?

[porres]

actually, it's whenever using the 'dump' message

[porres]

well, this seems to have fixed it for me f8bfadb

[porres]

hopefully it's time to ditch ggee and moocow for good :)

[reduzent]

Cool! Thanks, looks good here, too.