Opened 16 years ago

Last modified 8 years ago

#105 closed defect (Not a bug)

Todays Build - Possible memory leak?

Reported by: yancm Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: yancm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


I sync'd and built against CVS this AM - Launched at 6:45 EST. Memory usage is at 25M and climbing.

I suspect a memory leak, but am unsure how to help you find it.

Will it crash at some point and generate a useful core?

I'm on NetBSD 2.0_Stable w/P2-300 256M Ram.

Process limits:
clarity 13 -> limit
cputime unlimited
filesize unlimited
datasize 131072 kbytes
stacksize 2048 kbytes
coredumpsize unlimited
memoryuse 251972 kbytes
memorylocked 83990 kbytes
maxproc 160
openfiles 1648

I'm also getting 6-10 of the following messages per hour:
Feb 28 13:55:08.261 [warn] circuit_receive_relay_cell(): connection_edge_process_relay_cell (away from origin) failed.
Feb 28 13:55:08.261 [warn] command_process_relay_cell(): circuit_receive_relay_cell (forward) failed. Closing.

[Automatically added by flyspray2trac: Operating System: BSD]

Child Tickets

Change History (6)

comment:1 Changed 16 years ago by nickm

One thing that would be cool is if you could find out when the possible leak was introduced. Also, when exactly did you update from CVS?

Also, could you tell me more about how your Tor server is configured? Is it a client, a server, a middleman server, an exit server... ?


comment:2 Changed 16 years ago by yancm

OK, looks like a mostly false alarm. Memory usage grew to about 26M then fell back to about 10M and now appears stable.

I have felt (nice objective measure there) that cvs was a bit unsteady since last Thursday. It's been eating more CPU for sure, and today was eating more RAM too.

I've been running this mornings build for about 12 hours and have 40 minutes of CPU. Previously 12 hours might eat 5-10 minutes of CPU and run on about 4-5M RAM.

Do you have a max RAM target guess for a slow (20 KB - dsl) node like mine? I could set my process limits up and might get a core trace for what routine is trying to grow the ram allocation?

I sync to CVS and rebuild if there are changes once or twice a day. When I give you a build time, just assume that's the same time I did a full "cvs update -dP" (cause otherwise I wouldn't rebuild). I'm about to rebuild now since I see that CVS has some changes.

My server name is Clarity. It's an exit server and I believe it's a client, server and middleman server too?
My directory entry has more details:

comment:3 Changed 16 years ago by yancm

Just an update:
I sync'd to the last cvs updates at about 9PM EST on 2/28.
I also set my memory limits down to 20M in case the problem recurred.

So far, the latest build seem to be more stable (back to that "feeling" kinda report - I'm more callibrated than most though, after programming for 35+ years as an academic and hobbyist).

After over 12 hours running I'm at about 9.5M memmory and about 30 minutes cpu. My stats also look better on:

I'd say whatever your latest CVS commits, they have improved the situation.

I will continue to monitor.

comment:4 Changed 16 years ago by yancm

Tor build from cvs current @ 3/14/2005 9 PM (2100) EST is using almost 2x as much memory from the previous days build. I'm seeing 17-28M currently.

comment:5 Changed 16 years ago by nickm

flyspray2trac: bug closed.
So from what I can tell, this isn't actually a memory leak -- this is just Tor using a lot of memory. (We've been using dmalloc to hunt for leaks recently, and we squashed all the ones it found.)

It might be nice to reduce memory usage in the future, but currently memory usage isn't a bug.

(If you can come up with anything that suggests that this is a leak, such as the Tor process growing day-by-day over a matter of weeks, you should definitely re-open this bug.)

comment:6 Changed 8 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.