linuxdcpp-1.0.1 (only this version) fall in cycle on symlinks. After that, hashing thread(?) tries to allocate all possible memory. Seems like where is a bug in directory delimiter handling - '/' (see attached scr) Reproducible: Always Steps to Reproduce: 1. Create symbolic link for directory with lot of files - e.g with name "ISO" 2. Share directory symbolic link in linuxdcpp 3. See cycle in status bar and hashing form and available system memory (free -m) Actual Results: memleak + 100% CPU is used. Hashing is not completed Expected Results: linuxdcpp must not infinitely add '/' in directory path, if share is symlink
Created attachment 142293 [details] scr
probably, real bug in linuxdcpp - incorrect handling of unknown encoding in directory name. I find 2 directory with cyrillic name and broken encoding (my locale is ru_RU.utf8, these directory names looks like '??????????'). After renaming these dirs, hashing completed successfully. expected result: if linuxdcpp unable to hash directory, it have to skip it
Report this upstream, please.
Done. http://developer.berlios.de/bugs/?func=detailbug&bug_id=13050&group_id=2230