Opened 17 years ago

Closed 15 years ago

Last modified 15 years ago

#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 (Paul Guyot)
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 (9)

comment:1 Changed 17 years ago by markd@…

Component: portsbase
Summary: port doesn't release (any?) memoryBUG: port doesn't release (any?) memory

See related ticket #12022.

comment:2 Changed 17 years ago by kballard (Lily Ballard)

markd, you do realize that you linked this very ticket, right?

comment:3 Changed 17 years ago by kballard (Lily Ballard)

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 17 years ago by jmpp@…

Milestone: Needs developer reviewMacPorts base bugs

Milestone Needs developer review deleted

comment:5 Changed 17 years ago by nox@…

Priority: ExpectedNormal

comment:6 Changed 15 years ago by tobypeterson

Milestone: MacPorts base bugsMacPorts Future

Milestone MacPorts base bugs deleted

comment:7 Changed 15 years ago by jmroot (Joshua Root)

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.

comment:8 Changed 15 years ago by pguyot (Paul Guyot)

Resolution: fixed
Status: newclosed

Congrats on narrowing the bug to filemap code. Indeed, there was a memory leak there, which I fixed in r51419.

comment:9 Changed 15 years ago by jmroot (Joshua Root)

Milestone: MacPorts FutureMacPorts 1.8.0
Note: See TracTickets for help on using tickets.