gnome-search-tool consumes alot of memory while attempting to copy files from search results

[ERE]

Binary package hint: gnome-utils

step
1) open gnome-search-tool
2) find files (about 6000)
3) select all
4) drag and drop in Nautilus

Note: use of Memory abnormally

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: gnome-utils 2.30.0-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-24.38-generic 2.6.32.15+drm33.5
Uname: Linux 2.6.32-24-generic x86_64
Architecture: amd64
CheckboxSubmission: 93c4e47dccb94407d61a3001d6f0dcde
CheckboxSystem: 7e6efd756230e856ae594ed731432c18
Date: Sun Jul 25 21:57:07 2010
ExecutablePath: /usr/bin/gnome-search-tool
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
ProcEnviron:
 LANG=fr_FR.utf8
 SHELL=/bin/bash
SourcePackage: gnome-utils
XsessionErrors:
 (polkit-gnome-authentication-agent-1:1275): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (gnome-terminal:1367): Gtk-CRITICAL **: gtk_accel_map_unlock_path: assertion `entry != NULL && entry->lock_count > 0' failed
 (tomboy:1732): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference.

[haqt (hanqing-tan)]

I can confirm and replicate the bug.

ran 2 tests:
1. search results returned only a dozen or so files
2. search results returned a few thousand files

for 1st test:

- No issues running search utility. Only a few files were returned in search results

top output after search completed:

top - 23:39:45 up 3:12, 2 users, load average: 0.28, 0.20, 0.29
Tasks: 203 total, 1 running, 202 sleeping, 0 stopped, 0 zombie
Cpu(s): 5.2%us, 1.8%sy, 0.0%ni, 93.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4056520k total, 1150904k used, 2905616k free, 14872k buffers
Swap: 2931852k total, 341988k used, 2589864k free, 211564k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 2757 haqt 20 0 1053m 351m 346m S 0 8.9 3:12.99 /usr/lib/virtualbox/VirtualBox --comment lucid-mini-amd64 --startvm 41b4bd1f-1245-42a1-85ed-d527079776fd --no-startvm-errormsgbox
 2464 haqt 20 0 801m 153m 15m S 12 3.9 12:25.75 /usr/lib/firefox-3.6.8/firefox-bin
 1018 root 20 0 169m 45m 5380 S 10 1.1 10:31.68 /usr/bin/X :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-HiXAz4/database -nolisten tcp vt7
 1562 haqt 20 0 706m 32m 15m S 0 0.8 0:23.70 nautilus
 3538 haqt 20 0 372m 28m 11m S 0 0.7 0:09.28 gnome-search-tool

No issues copying files to a temp folder.

for 2nd test:

- Again, no issues running search utility. This time more than 6000 files were returned in search results.

- When I selected all the files and dragged (copied) them to a folder, cpu load spiked momentarily (due to disk activity). During this period, mouse becomes slightly unresponsive too. But eventually the disk activity subsides.
In top I could see that the search tool has consumed a large portion of available memory, but nothing has copied to folder. No copy indicator with completion bar appear to indicate that a copy is in progress.

here is top output while I was waiting for files to copy across.

top - 23:50:42 up 3:23, 2 users, load average: 0.85, 0.50, 0.35
Tasks: 203 total, 1 running, 202 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.9%us, 0.8%sy, 0.2%ni, 97.5%id, 0.1%wa, 0.5%hi, 0.0%si, 0.0%st
Mem: 4056520k total, 4006020k used, 50500k free, 13548k buffers
Swap: 2931852k total, 336692k used, 2595160k free, 295340k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 3538 haqt 20 0 3058m 2.7g 11m S 0 68.5 0:52.11 gnome-search-tool
 2757 haqt 20 0 1053m 351m 346m S 3 8.9 3:16.11 /usr/lib/virtualbox/VirtualB...

[haqt (hanqing-tan)]

ERE,

I don't think this is a memory leak.

Although gnome-search-tool does consume an unusually large amount of memory while the program is running, they seem to be freed once the program is terminated.

I think a more appropriate title to this bug would be: 'gnome-search-tool consumes alot of memory while attempting to copy files from search results; cannot copy files from large search results'

or something like that....