Ticket #12022 (closed defect: fixed)
BUG: port doesn't release (any?) memory
| Reported by: | flob@… | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | MacPorts 1.8.0 |
| Component: | base | Version: | 1.4.42 |
| Keywords: | port memory leak | Cc: | pguyot@… |
| Port: |
Description
After doing a selfupgrade from 1.320 to 1.442 and doing a upgrade installed after that in a new port-shell i saw port eating up my memory while doing noting than providing its shell after it finished its process of updating.
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
0 29148 1711 0 11 20 1331116 804640 - SN+ p2 11:09.87 /usr/bin/tclsh /opt/local/bin//port
Thats about 800 MB of memory for a shell??????
Change History
comment:1 Changed 6 years ago by markd@…
- Component changed from ports to base
- Summary changed from port doesn't release (any?) memory to BUG: port doesn't release (any?) memory
comment:2 Changed 6 years ago by eridius@…
markd, you do realize that you linked this very ticket, right?
comment:3 Changed 6 years ago by eridius@…
It's unfortunate that there aren't really any tcl debugging tools. There's no way (that I know of) to figure out what's going on here without random trial and error.
comment:4 Changed 6 years ago by jmpp@…
- Milestone changed from Needs developer review to MacPorts base bugs
Milestone Needs developer review deleted
comment:6 Changed 4 years ago by toby@…
- Milestone changed from MacPorts base bugs to MacPorts Future
Milestone MacPorts base bugs deleted
comment:7 Changed 4 years ago by jmr@…
- Cc pguyot@… added
I've narrowed down the memory usage problems to the filemap code. It adds about 160 MB to port's RPRVT each time it is used on my system. To demonstrate, open up port in interactive mode, run the activate, deactivate, provides or contents target, and watch your free memory disappear.
Note that it's far worse on trunk because it now closes the filemap when it's done with it (so more memory gets allocated next time it's opened). Upon closing, the variable is unset, FreeFilemapInternalRep() is called, and the ref count goes to zero, but no memory seems to be freed up.


See related ticket #12022.