Re: gvfsd-trash eats all cpu when msdos usb memory stick is mounted, then thunar joins in
On Mon, Jan 16, 2012 at 11:44:43AM +0100, Antoine Jacoutot wrote: On Mon, Jan 16, 2012 at 09:46:47AM +1100, Brett wrote: Hi, After updating to -current on 8th Jan, I noticed that whenever I mounted a usb memory stick formatted as msdos, gvfsd-trash would get out of control and chew up all available cpu (top shows it starting about 2% or something small then steadily climbing). This would stop if I use top to kill the process. However, when I then try to open the files on that stick (using thunar in xfce4 desktop environment), both gvfsd-trash and thunar processes will start steadily climbing in top. I could kill both gvfsd-trash and thunar, but then whenever I tried to open any folder (not just the ones on the memory stick), thunar would again start chewing up all the cpu. The only way to fix it this time would be to umount the stick and then kill thunar. This did not happen on my previous -current compiled on 6 Jan. I did not report until now as the 8 Jan -current I was using had Ariane van der Steldt's vmmap patches applied. But last night I compiled a new current without those patches and the problem remains. If I login using startx without going into xfce4, then I can mount this device and copy files no problem. Mounting a UFS filesystem does not cause any problems. I also noticed that one time, I used xlock to lock my screen while the stick was mounted. When I tried to unlock the screen, xlock was very slow to respond, and top showed xlock and gvfsd-trash both consuming about 50% of cpu each. Dmesg, top output and gdb output below. The memory stick is the 16gb SanDisk U3 Cruzer Micro in dmesg below. Let me know if you want me to try something else. I know where this is coming from. Give me a couple of days to come up with a patch. Fixed in glib2-2.30.2p3; thanks for the report. Brett. After mounting usb memory stick: # top -SHd 1 load averages: 2.39, 2.10, 1.33emachine.the.do 22:50:47 59 processes: 57 idle, 2 on processor CPU0 states: 0.6% user, 0.0% nice, 1.2% system, 0.1% interrupt, 98.1% idle CPU1 states: 0.5% user, 0.0% nice, 1.3% system, 0.0% interrupt, 98.2% idle Memory: Real: 144M/1958M act/tot Free: 1017M Cache: 543M Swap: 0K/4103M PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 6094 brett 640 3204K 5204K onproc/0 -12:31 99.27% gvfsd-trash 12165 brett 20 30M 69M sleep/0 select2:13 7.47% Xorg 24756 brett -50 11M 25M sleep/0 getblk1:11 3.86% Thunar 2 root -2200K 9628K idle -30.9H 0.00% idle0 4 root -2200K 9628K idle -30.9H 0.00% idle1 16325 brett 20 7380K 20M sleep/1 poll 0:45 0.00% xfce4-terminal 30883 brett 20 3096K 11M sleep/0 poll 0:34 0.00% xfce4-netload-pl 2961 brett 20 14M 27M sleep/0 poll 0:12 0.00% sylpheed 24811 _pflogd40 744K 472K sleep/1 bpf 0:09 0.00% pflogd 11021 brett 20 6784K 20M sleep/1 poll 0:07 0.00% xfdesktop 17585 brett 20 8968K 23M sleep/1 poll 0:07 0.00% xfce4-panel 13 root 1800K 9628K sleep/1 syncer0:02 0.00% update 12 root -1300K 9628K idle cleaner 0:02 0.00% cleaner 6192 brett 20 3424K 14M sleep/0 poll 0:02 0.00% xfwm4 19536 root 20 1656K 2220K sleep/1 select0:02 0.00% sendmail 5 root 1000K 9628K sleep/1 acpi0 0:02 0.00% acpi0 22992 brett 20 1396K 2024K idle poll 0:01 0.00% dbus-daemon 3 root 1000K 9628K sleep/1 bored 0:01 0.00% syswq After using top to kill thunar, there was a core dump file Thunar.core, not sure if this is useful: $ gdb thunar Thunar.core (gdb) where #0 0x000201a03b47 in _dl_find_symbol_obj () from /usr/libexec/ld.so #1 0x000201a03eec in _dl_find_symbol () from /usr/libexec/ld.so #2 0x000201a04140 in _dl_find_symbol_bysym () from /usr/libexec/ld.so #3 0x000201a0639d in _dl_md_reloc () from /usr/libexec/ld.so #4 0x000201a029db in _dl_rtld () from /usr/libexec/ld.so #5 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #6 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #7 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #8 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #9 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #10 0x000201a05695 in dlopen () from /usr/libexec/ld.so #11 0x000203e01cfb in g_module_open () from /usr/local/lib/libgmodule-2.0.so.2992.0 #12 0x00020bd2fb8f in thunarx_provider_module_new () from /usr/local/lib/libthunarx-2.so.0.0 #13 0x00020d3323cc in g_type_module_use ()
Re: gvfsd-trash eats all cpu when msdos usb memory stick is mounted, then thunar joins in
On 01/15/12 23:46, Brett wrote: Hi, After updating to -current on 8th Jan, I noticed that whenever I mounted a usb memory stick formatted as msdos, gvfsd-trash would get out of control and chew up all available cpu (top shows it starting about 2% or something small then steadily climbing). This would stop if I use top to kill the process. Hi, I have the same problem, the problem disappears by reverting latest glib2 update, I think there could be something wrong in kqueue implementation. http://marc.info/?l=openbsd-ports-cvsm=132540863032648w=2 Cheers Giovanni
Re: gvfsd-trash eats all cpu when msdos usb memory stick is mounted, then thunar joins in
On Mon, Jan 16, 2012 at 09:46:47AM +1100, Brett wrote: Hi, After updating to -current on 8th Jan, I noticed that whenever I mounted a usb memory stick formatted as msdos, gvfsd-trash would get out of control and chew up all available cpu (top shows it starting about 2% or something small then steadily climbing). This would stop if I use top to kill the process. However, when I then try to open the files on that stick (using thunar in xfce4 desktop environment), both gvfsd-trash and thunar processes will start steadily climbing in top. I could kill both gvfsd-trash and thunar, but then whenever I tried to open any folder (not just the ones on the memory stick), thunar would again start chewing up all the cpu. The only way to fix it this time would be to umount the stick and then kill thunar. This did not happen on my previous -current compiled on 6 Jan. I did not report until now as the 8 Jan -current I was using had Ariane van der Steldt's vmmap patches applied. But last night I compiled a new current without those patches and the problem remains. If I login using startx without going into xfce4, then I can mount this device and copy files no problem. Mounting a UFS filesystem does not cause any problems. I also noticed that one time, I used xlock to lock my screen while the stick was mounted. When I tried to unlock the screen, xlock was very slow to respond, and top showed xlock and gvfsd-trash both consuming about 50% of cpu each. Dmesg, top output and gdb output below. The memory stick is the 16gb SanDisk U3 Cruzer Micro in dmesg below. Let me know if you want me to try something else. I know where this is coming from. Give me a couple of days to come up with a patch. Brett. After mounting usb memory stick: # top -SHd 1 load averages: 2.39, 2.10, 1.33emachine.the.do 22:50:47 59 processes: 57 idle, 2 on processor CPU0 states: 0.6% user, 0.0% nice, 1.2% system, 0.1% interrupt, 98.1% idle CPU1 states: 0.5% user, 0.0% nice, 1.3% system, 0.0% interrupt, 98.2% idle Memory: Real: 144M/1958M act/tot Free: 1017M Cache: 543M Swap: 0K/4103M PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 6094 brett 640 3204K 5204K onproc/0 -12:31 99.27% gvfsd-trash 12165 brett 20 30M 69M sleep/0 select2:13 7.47% Xorg 24756 brett -50 11M 25M sleep/0 getblk1:11 3.86% Thunar 2 root -2200K 9628K idle -30.9H 0.00% idle0 4 root -2200K 9628K idle -30.9H 0.00% idle1 16325 brett 20 7380K 20M sleep/1 poll 0:45 0.00% xfce4-terminal 30883 brett 20 3096K 11M sleep/0 poll 0:34 0.00% xfce4-netload-pl 2961 brett 20 14M 27M sleep/0 poll 0:12 0.00% sylpheed 24811 _pflogd40 744K 472K sleep/1 bpf 0:09 0.00% pflogd 11021 brett 20 6784K 20M sleep/1 poll 0:07 0.00% xfdesktop 17585 brett 20 8968K 23M sleep/1 poll 0:07 0.00% xfce4-panel 13 root 1800K 9628K sleep/1 syncer0:02 0.00% update 12 root -1300K 9628K idle cleaner 0:02 0.00% cleaner 6192 brett 20 3424K 14M sleep/0 poll 0:02 0.00% xfwm4 19536 root 20 1656K 2220K sleep/1 select0:02 0.00% sendmail 5 root 1000K 9628K sleep/1 acpi0 0:02 0.00% acpi0 22992 brett 20 1396K 2024K idle poll 0:01 0.00% dbus-daemon 3 root 1000K 9628K sleep/1 bored 0:01 0.00% syswq After using top to kill thunar, there was a core dump file Thunar.core, not sure if this is useful: $ gdb thunar Thunar.core (gdb) where #0 0x000201a03b47 in _dl_find_symbol_obj () from /usr/libexec/ld.so #1 0x000201a03eec in _dl_find_symbol () from /usr/libexec/ld.so #2 0x000201a04140 in _dl_find_symbol_bysym () from /usr/libexec/ld.so #3 0x000201a0639d in _dl_md_reloc () from /usr/libexec/ld.so #4 0x000201a029db in _dl_rtld () from /usr/libexec/ld.so #5 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #6 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #7 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #8 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #9 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #10 0x000201a05695 in dlopen () from /usr/libexec/ld.so #11 0x000203e01cfb in g_module_open () from /usr/local/lib/libgmodule-2.0.so.2992.0 #12 0x00020bd2fb8f in thunarx_provider_module_new () from /usr/local/lib/libthunarx-2.so.0.0 #13 0x00020d3323cc in g_type_module_use () from /usr/local/lib/libgobject-2.0.so.2992.0 #14 0x00020bd2f3ce in thunarx_provider_factory_list_providers () from /usr/local/lib/libthunarx-2.so.0.0 #15 0x0047906b in __register_frame_info () #16
gvfsd-trash eats all cpu when msdos usb memory stick is mounted, then thunar joins in
Hi, After updating to -current on 8th Jan, I noticed that whenever I mounted a usb memory stick formatted as msdos, gvfsd-trash would get out of control and chew up all available cpu (top shows it starting about 2% or something small then steadily climbing). This would stop if I use top to kill the process. However, when I then try to open the files on that stick (using thunar in xfce4 desktop environment), both gvfsd-trash and thunar processes will start steadily climbing in top. I could kill both gvfsd-trash and thunar, but then whenever I tried to open any folder (not just the ones on the memory stick), thunar would again start chewing up all the cpu. The only way to fix it this time would be to umount the stick and then kill thunar. This did not happen on my previous -current compiled on 6 Jan. I did not report until now as the 8 Jan -current I was using had Ariane van der Steldt's vmmap patches applied. But last night I compiled a new current without those patches and the problem remains. If I login using startx without going into xfce4, then I can mount this device and copy files no problem. Mounting a UFS filesystem does not cause any problems. I also noticed that one time, I used xlock to lock my screen while the stick was mounted. When I tried to unlock the screen, xlock was very slow to respond, and top showed xlock and gvfsd-trash both consuming about 50% of cpu each. Dmesg, top output and gdb output below. The memory stick is the 16gb SanDisk U3 Cruzer Micro in dmesg below. Let me know if you want me to try something else. Brett. After mounting usb memory stick: # top -SHd 1 load averages: 2.39, 2.10, 1.33emachine.the.do 22:50:47 59 processes: 57 idle, 2 on processor CPU0 states: 0.6% user, 0.0% nice, 1.2% system, 0.1% interrupt, 98.1% idle CPU1 states: 0.5% user, 0.0% nice, 1.3% system, 0.0% interrupt, 98.2% idle Memory: Real: 144M/1958M act/tot Free: 1017M Cache: 543M Swap: 0K/4103M PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 6094 brett 640 3204K 5204K onproc/0 -12:31 99.27% gvfsd-trash 12165 brett 20 30M 69M sleep/0 select2:13 7.47% Xorg 24756 brett -50 11M 25M sleep/0 getblk1:11 3.86% Thunar 2 root -2200K 9628K idle -30.9H 0.00% idle0 4 root -2200K 9628K idle -30.9H 0.00% idle1 16325 brett 20 7380K 20M sleep/1 poll 0:45 0.00% xfce4-terminal 30883 brett 20 3096K 11M sleep/0 poll 0:34 0.00% xfce4-netload-pl 2961 brett 20 14M 27M sleep/0 poll 0:12 0.00% sylpheed 24811 _pflogd40 744K 472K sleep/1 bpf 0:09 0.00% pflogd 11021 brett 20 6784K 20M sleep/1 poll 0:07 0.00% xfdesktop 17585 brett 20 8968K 23M sleep/1 poll 0:07 0.00% xfce4-panel 13 root 1800K 9628K sleep/1 syncer0:02 0.00% update 12 root -1300K 9628K idle cleaner 0:02 0.00% cleaner 6192 brett 20 3424K 14M sleep/0 poll 0:02 0.00% xfwm4 19536 root 20 1656K 2220K sleep/1 select0:02 0.00% sendmail 5 root 1000K 9628K sleep/1 acpi0 0:02 0.00% acpi0 22992 brett 20 1396K 2024K idle poll 0:01 0.00% dbus-daemon 3 root 1000K 9628K sleep/1 bored 0:01 0.00% syswq After using top to kill thunar, there was a core dump file Thunar.core, not sure if this is useful: $ gdb thunar Thunar.core (gdb) where #0 0x000201a03b47 in _dl_find_symbol_obj () from /usr/libexec/ld.so #1 0x000201a03eec in _dl_find_symbol () from /usr/libexec/ld.so #2 0x000201a04140 in _dl_find_symbol_bysym () from /usr/libexec/ld.so #3 0x000201a0639d in _dl_md_reloc () from /usr/libexec/ld.so #4 0x000201a029db in _dl_rtld () from /usr/libexec/ld.so #5 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #6 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #7 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #8 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #9 0x000201a0295e in _dl_rtld () from /usr/libexec/ld.so #10 0x000201a05695 in dlopen () from /usr/libexec/ld.so #11 0x000203e01cfb in g_module_open () from /usr/local/lib/libgmodule-2.0.so.2992.0 #12 0x00020bd2fb8f in thunarx_provider_module_new () from /usr/local/lib/libthunarx-2.so.0.0 #13 0x00020d3323cc in g_type_module_use () from /usr/local/lib/libgobject-2.0.so.2992.0 #14 0x00020bd2f3ce in thunarx_provider_factory_list_providers () from /usr/local/lib/libthunarx-2.so.0.0 #15 0x0047906b in __register_frame_info () #16 0x00021274e125 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.2992.0 #17 0x0002127519cc in g_main_context_check () from /usr/local/lib/libglib-2.0.so.2992.0 #18 0x000212751cea in g_main_loop_run () from
gvfsd-trash eats all cpu when msdos usb memory stick is mounted, then thunar joins in
After updating to -current on 8th Jan, I noticed that whenever I mounted a usb memory stick formatted as msdos, gvfsd-trash would get out of control and chew up all available cpu (top shows it starting about 2% or something small then steadily climbing). This would stop if I use top to kill the process. I forgot to mention that the same time this started happening, it was no longer possible to unmount usb memory sticks (while logged into xfce4), without using the umount -f option. This is now necessary whether using UFS or MSDOS (and was not with 6 Jan or earlier -current). Seems related since this gvfsd-trash creature is spotted at the scene of the crime. eg using ufs: # mount /dev/sd5i # umount /dev/sd5i umount: /mnt/data: Device busy # fstat /mnt/data/ USER CMD PID FD MOUNTINUM MODE R/WSZ|DV NAME brettgvfsd-trash 19688 28 /mnt/data2 drwxrwxr-x r 512 /mnt/data/ brettgvfsd-trash 19688 31 /mnt/data2 drwxrwxr-x r 512 /mnt/data/
Re: gvfsd-trash eats all cpu when msdos usb memory stick is mounted, then thunar joins in
After updating to -current on 8th Jan, I noticed that whenever I mounted a usb memory stick formatted as msdos, gvfsd-trash would get out of control and chew up all available cpu (top shows it starting about 2% or something small then steadily climbing). This would stop if I use top to kill the process. I forgot to mention that the same time this started happening, it was no longer possible to unmount usb memory sticks (while logged into xfce4), without using the umount -f option. This is now necessary whether using UFS or MSDOS (and was not with 6 Jan or earlier -current). Experimenting with this some more, it does happen on UFS filesystems as well (contrary to my earlier email) - just not all the time like it does with MSDOS. I reproduced the same issue with a UFS usb memory stick, and also with a UFS usb hard drive (500gb buffalo). Brett.
