Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Nautilus crashes when creating new folder in owncloud folder and renaming it #3067

Closed
piratenpanda opened this issue Apr 3, 2015 · 23 comments
Closed

Nautilus crashes when creating new folder in owncloud folder and renaming it #3067

piratenpanda opened this issue Apr 3, 2015 · 23 comments
Assignees
@ckamm
Labels
Needs info type:bug
Milestone
2.0.2

Comments

@piratenpanda
Copy link

I'm running latest client (38ef52) available in manjaro linux with nautilus 3.14.2. When creating a new folder, owncloud starts syncing right away but when renaming the folder, a standard procedure after creating a new folder, it crashes. Is there any way I can debug?
@guruz
Copy link
Contributor

guruz commented Apr 5, 2015

Did you try running it inside gdb?

gdb --args /usr/bin/owncloud --logfile -

Then on crash you do:
thread apply all where

@guruz guruz added this to the 1.8.1 - Bugfix milestone Apr 5, 2015
@guruz guruz added the type:bug label Apr 5, 2015
@ogoffart
Copy link
Contributor

ogoffart commented Apr 6, 2015

What is crashing? owncloud or Nautilus?

@piratenpanda
Copy link
Author

Nautilus, owncloud is running fine. Will try to get a backtrace

@piratenpanda
Copy link
Author

Interesting, while and after running nautilus in gdb it didn't crash anymore. Will try to reproduce this

@piratenpanda
Copy link
Author

Got it. Does this help already or do i need more debug symbols?

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4f2bf3f in g_type_check_instance_is_a ()
from /usr/lib/libgobject-2.0.so.0
(gdb) thread apply all where

Thread 7 (Thread 0x7fffe386f700 (LWP 908)):
#0 0x00007ffff3e7a4ed in poll () from /usr/lib/libc.so.6
#1 0x00007ffff4c349a4 in ?? () from /usr/lib/libglib-2.0.so.0
#2 0x00007ffff4c34abc in g_main_context_iteration ()
from /usr/lib/libglib-2.0.so.0
#3 0x00007ffff4c34af9 in ?? () from /usr/lib/libglib-2.0.so.0
#4 0x00007ffff4c5b215 in ?? () from /usr/lib/libglib-2.0.so.0
#5 0x00007ffff4145374 in start_thread () from /usr/lib/libpthread.so.0
#6 0x00007ffff3e8327d in clone () from /usr/lib/libc.so.6

Thread 6 (Thread 0x7fffe1bcb700 (LWP 909)):
#0 0x00007ffff3e7a4ed in poll () from /usr/lib/libc.so.6
#1 0x00007ffff4c349a4 in ?? () from /usr/lib/libglib-2.0.so.0
#2 0x00007ffff4c34abc in g_main_context_iteration ()
from /usr/lib/libglib-2.0.so.0
#3 0x00007fffe1bd325d in ?? () from /usr/lib/gio/modules/libdconfsettings.so
#4 0x00007ffff4c5b215 in ?? () from /usr/lib/libglib-2.0.so.0
#5 0x00007ffff4145374 in start_thread () from /usr/lib/libpthread.so.0
#6 0x00007ffff3e8327d in clone () from /usr/lib/libc.so.6

Thread 5 (Thread 0x7fffcf7fe700 (LWP 938)):
#0 0x00007ffff3e7ef89 in syscall () from /usr/lib/libc.so.6
#1 0x00007ffff4c79267 in g_cond_wait_until () from /usr/lib/libglib-2.0.so.0
#2 0x00007ffff4c09779 in ?? () from /usr/lib/libglib-2.0.so.0
#3 0x00007ffff4c5bb80 in ?? () from /usr/lib/libglib-2.0.so.0
#4 0x00007ffff4c5b215 in ?? () from /usr/lib/libglib-2.0.so.0
#5 0x00007ffff4145374 in start_thread () from /usr/lib/libpthread.so.0
#6 0x00007ffff3e8327d in clone () from /usr/lib/libc.so.6

Thread 3 (Thread 0x7fffe9c24700 (LWP 906)):
#0 0x00007ffff3e7a4ed in poll () from /usr/lib/libc.so.6
#1 0x00007ffff4c349a4 in ?? () from /usr/lib/libglib-2.0.so.0
#2 0x00007ffff4c34d32 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#3 0x00007ffff5224d86 in ?? () from /usr/lib/libgio-2.0.so.0
#4 0x00007ffff4c5b215 in ?? () from /usr/lib/libglib-2.0.so.0
#5 0x00007ffff4145374 in start_thread () from /usr/lib/libpthread.so.0
#6 0x00007ffff3e8327d in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7ffff7fa7940 (LWP 902)):
#0 0x00007ffff4f2bf3f in g_type_check_instance_is_a ()
from /usr/lib/libgobject-2.0.so.0
#1 0x000000000042fb2f in ?? ()
#2 0x00007fffef61b1f0 in ffi_call_unix64 () from /usr/lib/libffi.so.6
#3 0x00007fffef61ac58 in ffi_call () from /usr/lib/libffi.so.6
#4 0x00007ffff4f09984 in g_cclosure_marshal_generic ()
from /usr/lib/libgobject-2.0.so.0
#5 0x00007ffff4f09175 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#6 0x00007ffff4f1aa5c in ?? () from /usr/lib/libgobject-2.0.so.0
#7 0x00007ffff4f236f8 in g_signal_emit_valist ()
from /usr/lib/libgobject-2.0.so.0
#8 0x00007ffff4f2395f in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#9 0x0000000000482963 in ?? ()
#10 0x000000000048d33d in ?? ()
#11 0x00007ffff6e936e9 in ?? () from /usr/lib/libgtk-3.so.0
#12 0x00007ffff4f092f2 in ?? () from /usr/lib/libgobject-2.0.so.0
#13 0x00007ffff4f22ab0 in g_signal_emit_valist ()
from /usr/lib/libgobject-2.0.so.0
#14 0x00007ffff4f2395f in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#15 0x00007ffff6fc4124 in ?? () from /usr/lib/libgtk-3.so.0
#16 0x00007ffff6fe2b9e in gtk_window_propagate_key_event ()
from /usr/lib/libgtk-3.so.0
#17 0x0000000000475eeb in ?? ()
#18 0x00007ffff6e936e9 in ?? () from /usr/lib/libgtk-3.so.0
#19 0x00007ffff4f093a4 in ?? () from /usr/lib/libgobject-2.0.so.0
#20 0x00007ffff4f22ab0 in g_signal_emit_valist ()
from /usr/lib/libgobject-2.0.so.0
#21 0x00007ffff4f2395f in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#22 0x00007ffff6fc4124 in ?? () from /usr/lib/libgtk-3.so.0
#23 0x00007ffff6e9111e in ?? () from /usr/lib/libgtk-3.so.0
#24 0x00007ffff6e92c0e in gtk_main_do_event () from /usr/lib/libgtk-3.so.0
#25 0x00007ffff6a3bc12 in ?? () from /usr/lib/libgdk-3.so.0
#26 0x00007ffff4c3471d in g_main_context_dispatch ()
from /usr/lib/libglib-2.0.so.0
#27 0x00007ffff4c34a08 in ?? () from /usr/lib/libglib-2.0.so.0
#28 0x00007ffff4c34abc in g_main_context_iteration ()
from /usr/lib/libglib-2.0.so.0
#29 0x00007ffff51ef09c in g_application_run () from /usr/lib/libgio-2.0.so.0
#30 0x0000000000429f01 in ?? ()
#31 0x00007ffff3dbb800 in __libc_start_main () from /usr/lib/libc.so.6
#32 0x0000000000429f63 in ?? ()

@guruz
Copy link
Contributor

guruz commented Apr 6, 2015

Do you have the Nautilus integration for the icon overlays inside the sync folders running?
If you disable it does it crash too?

@piratenpanda
Copy link
Author

Yes, python-nautilus is installed. Will try without

@piratenpanda
Copy link
Author

Seems to work fine without

@dragotin
Copy link
Contributor

dragotin commented Apr 7, 2015

hmm, are you sure that the python-nautilus does match the nautilus version that is running? I.e. if you updated nautilus to a more recent version that is not bin compatible to the python bindings, that might crash.

@piratenpanda
Copy link
Author

I'm using the one available in arch so i dont have a choice really. Icons and updating the icons while syncing works fine.

@mihaig11
Copy link

mihaig11 commented Apr 7, 2015

It works just fine on fedora 20 x64 (nautilus 3.10.1, nautilus-python 1.1) , same OC client version as piratenpanda with icon overlays running. All packages from official repos.

@ckamm ckamm self-assigned this Apr 8, 2015
@ckamm
Copy link
Contributor

ckamm commented Apr 8, 2015

@piratenpanda Unfortunately the backtrace doesn't tell me much. Would you be up for testing a couple of things?

Open your installed syncstate.py (probably in .../share/nautilus-python/extensions/syncstate.py):

  • line 151: 'return []' instead of 'return'?
  • line 182: remove 'Nautilus.ColumnProvider, '

It that doesn't do it, let's try to narrow down the problem locaton:

  • remove the whole MenuExtension class, does it work now?
  • remove the whole SyncStateExtension, does it work now?

I'm somewhat suspicious of how the script stores the FileInfo items it gets from update_file_info() - it may need to be rewritten to use the async update_file_info_full()...

@piratenpanda
Copy link
Author

Changing the two lines didn't help. And i noticed renaming works fine a few times and then it crashes for the n-th time you rename folders.

Removing the MenuExtension class doesn't change it.

When removing the whole extension i can't get nautilus to crash

@ckamm
Copy link
Contributor

ckamm commented Apr 8, 2015

@piratenpanda Thanks for the test! Removing only the SyncStateExtension makes it work, correct?

@piratenpanda
Copy link
Author

When you mean deleting the file in the python-nautilus extension directory then yes

@ckamm
Copy link
Contributor

ckamm commented Apr 8, 2015

@piratenpanda No, I mean removing everything between class SyncStateExtension and the end of the file.

@piratenpanda
Copy link
Author

ah ok, i misunderstood because the file is called syncstate.py and in an extension dir. Let me try it now.

@piratenpanda
Copy link
Author

Removing the SyncStateExtension class seems to "fix" it, yes

@ckamm
Copy link
Contributor

ckamm commented Apr 8, 2015

@piratenpanda Okay, thanks. Unfortunately that means it'll probably not be a simple fix. I think we can't store the FileInfo objects we get from update_file_info. Instead we'll likely have to use update_file_info_full. See https://projects-old.gnome.org/nautilus-python/documentation/html/class-nautilus-python-info-provider.html.

@ckamm ckamm removed the Needs info label Apr 8, 2015
@ckamm
Copy link
Contributor

ckamm commented Apr 8, 2015

@piratenpanda I now installed everything in a VM with archlinux, nautilus 3.14.2 and owncloud 38ef52. I can't reproduce the problem. I'm creating new folders and renaming them immediately or after a short pause. Is there anything in particular I should try?

@piratenpanda
Copy link
Author

I have to create a few folders quickly in sequence. And after a few times it crashes.

@ckamm
Copy link
Contributor

ckamm commented Apr 9, 2015

I've now made 35 folders in quick succession in various subfolders but can't reproduce it. :/

This makes it less clear that there's an actual bug here. I'll ask someone from nautilus-python whether our usage of update_file_info is safe - but it's not necessary for 1.8.1.

@ckamm ckamm modified the milestones: 1.9 - Multi-account, 1.8.1 - Bugfix Apr 9, 2015
@MTRichards MTRichards modified the milestones: 2.0.1-next, 2.0 - Multi-account Jun 19, 2015
@guruz
Copy link
Contributor

guruz commented Aug 3, 2015

Please re-open if you have more info

@guruz guruz closed this as completed Aug 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ckamm ckamm

Labels
Needs info type:bug
Projects
None yet
Milestone
2.0.2
Development

No branches or pull requests
7 participants
@ckamm @piratenpanda @ogoffart @guruz @dragotin @MTRichards @mihaig11