Scanning consumes all memory

Faralla
2011-08-08
2013-05-29
  • Faralla

    Faralla - 2011-08-08

    Hi,

    today I tried running minidlna, but during scanning some videos and around 14000 mp3-files, it consumed all available RAM of my WNDR3700.
    Is there any way to limit the maximum cache size in memory?

    Regards,
    Philipp

     
  • Justin Maggard

    Justin Maggard - 2011-08-08

    Do you know if it happens with only music files?  Usually it's the ffmpeg libraries that eat up large chunks of memory.  Are you able to compile a custom binary for your router? 

     
  • Faralla

    Faralla - 2011-08-09

    It seems to always crash on one particular mp3 album, regardless if videos are scanned before, or not.

    In a private mail, I'll send you a link to a file, where minidlna crashes reproducible, while consuming all available memory.

    Here is what the kernel dumps on the crash:

    minidlna invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
    Call Trace:
      dump_stack+0x8/0x34
      dump_header.clone.12+0x48/0x120
      oom_kill_process.clone.13+0x44/0x110
      __out_of_memory+0x178/0x1ac
      out_of_memory+0x88/0xb4
      __alloc_pages_nodemask+0x468/0x598
      __do_page_cache_readahead+0xd4/0x224
      ra_submit+0x28/0x34
      filemap_fault+0x1f4/0x424
      __do_fault+0x70/0x480
      handle_mm_fault+0x3c0/0x760
      do_page_fault+0x110/0x304
      ret_from_exception+0x0/0xc

    Mem-Info:
    Normal per-cpu:
    CPU    0: hi:   18, btch:   3 usd:   6
    active_anon:5449 inactive_anon:5511 isolated_anon:0
      active_file:69 inactive_file:0 isolated_file:0
      unevictable:427 dirty:0 writeback:0 unstable:0
      free:263 slab_reclaimable:164 slab_unreclaimable:2847
      mapped:3 shmem:0 pagetables:102 bounce:0
    Normal free:1052kB min:1016kB low:1268kB high:1524kB active_anon:21796kB inactive_anon:22044kB active_file:276kB inactive_file:0kB unevictable:1708kB isolated(anon):0kB isolated(file):0kB present:65024kB mlocked:0kB dirty:0kB writeback:0kB mapped:12kB shmem:0kB slab_reclaimable:656kB slab_unreclaimable:11388kB kernel_stack:344kB pagetables:408kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
    lowmem_reserve: 0 0
    Normal: 263*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1052kB
    877 total pagecache pages
    381 pages in swap cache
    Swap cache stats: add 16761, delete 16380, find 89/129
    Free swap  = 0kB
    Total swap = 65532kB
    16384 pages RAM
    921 pages reserved
    77 pages shared
    13809 pages non-shared
    Out of memory: kill process 9803 (minidlna) score 956 or a child
    Killed process 9810 (minidlna) vsz:110524kB, anon-rss:41824kB, file-rss:0kB

     
  • Justin Maggard

    Justin Maggard - 2011-08-11

    Are you running stock firmware, or dd-wrt or similar?  Does it OOM if that file is the only file it scans?

     
  • Faralla

    Faralla - 2011-08-11

    I am running a Frankn'dd-wrt. That is, a dd-wrt combined with additional OpenWRT-Binaries. (see http://g300nh.blogspot.com/2010/06/software-installation-on-dd-wrt-part-1.html)

    And yes, it does crash, if only scanning the sent file or any track of the containing album.
    I guess, it might be invalid on purpose. Maybe designed to exploit some WinAmp-vulnerability. But that is only an assumption.

    In the meatime, I removed the album from my media-library and scanned it successfully. I have a running minidlna now.

    Can you reproduce the crash with the file?

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks