Modify

Opened 9 years ago

Closed 9 years ago

Last modified 2 years ago

#1780 closed defect (fixed)

memory leak in kamikaze 2.4

Reported by: netprince (at) vt (dot) edu Owned by: developers
Priority: high Milestone: Barrier Breaker 14.07
Component: kernel Version:
Keywords: memleak memory leak Cc:

Description

There seems to be a kernel memory leak in kamikaze 2.4. I setup my router and noticed this graph after about 12 hours. Memory usage continues to rise:

http://www.psyc.vt.edu/openwrt/mem_leak.png

So I then setup a test router, default build of kamikaze. I installed one script into cron, and left it alone:

#!/bin/sh

counter=1000
[ "$1" != "" ] && counter="$1"

while [ "$counter" -gt "0" ]; do
  memStats=$(/bin/grep "^Mem:" /proc/meminfo \
  | /usr/bin/awk '{print "\$((" $2 " - " $3 " + " $6 " + " $7 "))" }')
  memLeft=$(eval "echo $memStats")
  dt=$(date)

  echo "$dt: $memLeft"

  #grep ip_dst_cache /proc/slabinfo
  #cat /proc/net/rt_cache | wc -l

  counter=$(( $counter - 1))
  [ "$counter" -gt "0" ] && sleep 300
done

The output is as follows:

Sat Jan  1 00:15:02 UTC 2000: 9478144
Sat Jan  1 00:30:01 UTC 2000: 9535488
Sat Jan  1 00:45:01 UTC 2000: 9535488
Sat Jan  1 01:00:01 UTC 2000: 9535488
Sat Jan  1 01:15:01 UTC 2000: 9535488
Sat Jan  1 01:30:01 UTC 2000: 9420800
Sat Jan  1 01:45:01 UTC 2000: 8904704
Sat Jan  1 02:00:02 UTC 2000: 8962048
Sat Jan  1 02:15:01 UTC 2000: 9269248
Sat Jan  1 02:30:01 UTC 2000: 9207808
Sat Jan  1 02:45:02 UTC 2000: 9207808
Sat Jan  1 03:00:01 UTC 2000: 9207808
Sat Jan  1 03:15:01 UTC 2000: 9207808
Sat Jan  1 03:30:01 UTC 2000: 9199616
Sat Jan  1 03:45:01 UTC 2000: 9199616
Sat Jan  1 04:00:01 UTC 2000: 9256960
Sat Jan  1 04:15:01 UTC 2000: 9256960
Sat Jan  1 04:30:02 UTC 2000: 9256960
Sat Jan  1 04:45:01 UTC 2000: 9256960
Sat Jan  1 05:00:01 UTC 2000: 9256960
Sat Jan  1 05:15:02 UTC 2000: 9199616
Sat Jan  1 05:30:01 UTC 2000: 9199616
Sat Jan  1 05:45:01 UTC 2000: 9199616
Sat Jan  1 06:00:01 UTC 2000: 9199616
Sat Jan  1 06:15:01 UTC 2000: 9150464
Sat Jan  1 06:30:01 UTC 2000: 9150464
Sat Jan  1 06:45:01 UTC 2000: 9150464
Sat Jan  1 07:00:02 UTC 2000: 9150464
Sat Jan  1 07:15:01 UTC 2000: 9150464
Sat Jan  1 07:30:01 UTC 2000: 9150464
Sat Jan  1 07:45:02 UTC 2000: 9150464
Sat Jan  1 08:00:01 UTC 2000: 9150464
Sat Jan  1 08:15:01 UTC 2000: 9150464
Sat Jan  1 08:30:01 UTC 2000: 9150464
Sat Jan  1 08:45:01 UTC 2000: 9150464
Sat Jan  1 09:00:01 UTC 2000: 9150464
Sat Jan  1 09:15:01 UTC 2000: 9142272
Sat Jan  1 09:30:01 UTC 2000: 9142272
Sat Jan  1 09:45:01 UTC 2000: 9199616
Sat Jan  1 10:00:01 UTC 2000: 9199616
Sat Jan  1 10:15:02 UTC 2000: 9199616
Sat Jan  1 10:30:01 UTC 2000: 9199616
Sat Jan  1 10:45:01 UTC 2000: 9142272
Sat Jan  1 11:00:01 UTC 2000: 9199616
Sat Jan  1 11:15:01 UTC 2000: 9199616
Sat Jan  1 11:30:01 UTC 2000: 9138176
Sat Jan  1 11:45:01 UTC 2000: 9072640
Sat Jan  1 12:00:01 UTC 2000: 9072640
Sat Jan  1 12:15:01 UTC 2000: 9072640

I'm not sure how to debug this. If anyone has any advice or ideas, I'd be happy to give them a try.

I will update this ticket with further stats tomorrow morning...

Attachments (0)

Change History (6)

comment:1 Changed 9 years ago by netprince (at) vt (dot) edu

Well, looks like the default install is not leaking. I'm still hunting down the problem here...

comment:2 Changed 9 years ago by netprince (at) vt (dot) edu

I found the leak.

This little script will highlight the problem.

#!/bin/sh

i=1
while [ "$i" -lt "1000" ]; do

        l=1
        while [ "$l" -lt "50" ]; do
                model=$(cat /proc/diag/model)
                l=$(( $l + 1))
        done

        memStats=$(/bin/grep "^Mem:" /proc/meminfo \
        | /usr/bin/awk '{print "\$((" $2 " - " $3 " + " $6 " + " $7 "))" }')
        memLeft=$(eval "echo $memStats")
        dt=$(date)

        echo "$dt: $memLeft bytes free."

        i=$(( $i + 1))
done

comment:3 Changed 9 years ago by florian

So the problem is in the diag driver ?

comment:4 Changed 9 years ago by netprince (at) vt (dot) edu

Yes, I think so. As long as I dont read from /proc/diag/model, all is fine. I took a quick look at the code, but I'm not familiar with how it interfaces with the kernel.

comment:5 Changed 9 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

fixed in [7683]

comment:6 Changed 2 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.