On 08/05/2017 12:59 AM, Marek Marczykowski-Górecki wrote:
> On Fri, Aug 04, 2017 at 07:40:22PM -0700, Andrew Morgan wrote:
>> On 08/04/2017 05:36 PM, Andrew Morgan wrote:
>>> On 08/04/2017 05:17 AM, Marek Marczykowski-Górecki wrote:
>>>> On Fri, Aug 04, 2017 at 03:51:32AM -0700, Andrew Morgan wrote:
>>>>> On 08/02/2017 07:59 AM, Marek Marczykowski-Górecki wrote:
>>>>>> On Wed, Aug 02, 2017 at 04:33:51AM -0700, Andrew Morgan wrote:
>>>>>>> On 08/01/2017 02:54 AM, Andrew Morgan wrote:
>>>>>>>> On 08/01/2017 02:53 AM, Marek Marczykowski-Górecki wrote:
>>>>>>>>> On Tue, Aug 01, 2017 at 12:59:16AM -0700, Andrew Morgan wrote:
>>>>>>>>>> On 07/31/2017 03:17 AM, Marek Marczykowski-Górecki wrote:
>>>>>>>>>>> On Sun, Jul 30, 2017 at 11:48:48PM -0700, Andrew Morgan wrote:
>>>>>>>>>>>> Quick update for tonight.
>>>>>>>>>>>> I've found where the most likely choke point for opening files is. 
>>>>>>>>>>>> [1]
>>>>>>>>>>>> Ideally one would just make a call to extensions through
>>>>>>>>>>>> libnautilus-extension through there, wait for responses, then 
>>>>>>>>>>>> return if
>>>>>>>>>>>> any extension returns a False. I'm unsure if anything in Nautilus 
>>>>>>>>>>>> on the
>>>>>>>>>>>> UX side needs to happen after that (such as showing a loading icon 
>>>>>>>>>>>> or
>>>>>>>>>>>> something...) but that's currently outside the scope of this 
>>>>>>>>>>>> patchset.
>>>>>>>>>>>> I've been talking to and getting help from people on 
>>>>>>>>>>>> GIMPnet/#nautilus.
>>>>>>>>>>>> After explaining the whole idea to a few people, I've been 
>>>>>>>>>>>> prompted to
>>>>>>>>>>>> post on the mailing list. I have now done so with a RFC of sorts 
>>>>>>>>>>>> on the
>>>>>>>>>>>> idea and whether or not they'd be prone to accepting it upstream 
>>>>>>>>>>>> once
>>>>>>>>>>>> it's ready.
>>>>>>>>>>>> The post is currently awaiting moderation approval, but I'll link 
>>>>>>>>>>>> it
>>>>>>>>>>>> once it goes up so people can keep up with the discussion.
>>>>>>>>>>> Great, thanks for the update!
>>>>>>>>>>>> Andrew Morgan
>>>>>>>>>>>> [1]:
>>>>>>>>>>>> https://github.com/GNOME/nautilus/blob/master/src/nautilus-mime-actions.c#L2421
>>>>>>>>>> Another update,
>>>>>>>>>> The mailing list post still hasn't been approved. I messaged on 
>>>>>>>>>> GIMPnet
>>>>>>>>>> about it not too long ago so hopefully the appropriate people will 
>>>>>>>>>> get
>>>>>>>>>> pinged eventually. The team is currently busy with GUADEC so it's
>>>>>>>>>> understandable they may be running behind on moderating posts on a 
>>>>>>>>>> not
>>>>>>>>>> too traffic heavy mailing list[1] :)
>>>>>>>>> Does subscribing to the list workaround the issue? Some times 
>>>>>>>>> moderator
>>>>>>>>> is set to just one, busy, person...
>>>>>>>> I presume that's probably the case, yeah. I subscribed before I posted,
>>>>>>>> didn't seem to make a difference :)
>>>>>>>>>> In terms of the patch, I've inserted the necessary code into all the
>>>>>>>>>> accompanying files and Nautilus builds successfully. During my 
>>>>>>>>>> testing I
>>>>>>>>>> threw a return statement in there and confirmed it blocked all file 
>>>>>>>>>> open
>>>>>>>>>> attempts silently, which is intended behavior.
>>>>>>>>>> I've stuck the WIP code up on Github, currently it segfaults but the
>>>>>>>>>> cause is known. I'll be modifying the qvm_trust.py NautilusPython
>>>>>>>>>> extension to make use of this method soon, and once it all works out
>>>>>>>>>> I'll provide some pre-made .RPMs for testing.
>>>>>>>>> Ok :)
>>>>>>> Another status update for today.
>>>>>>> As I said mostly everything's in place, however I'm currently stuck on
>>>>>>> trying to provide the correct arguments to a function that calls the
>>>>>>> subclassed methods in nautilus extensions.
>>>>>>> Here is an example of calling a function subclassed by extensions:
>>>>>>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-directory-async.c#L4647
>>>>>>> The update_complete and &handle arguments are not necessary for our
>>>>>>> purposes, but the provider and file args are.
>>>>>>> Here I am calling our new method, that asks extensions whether we should
>>>>>>> open a particular file or not:
>>>>>>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-mime-actions.c#L2500
>>>>>>> However the provider object is NULL. That
>>>>>>> nautilus_module_get_extensions_for_type method is defined here:
>>>>>>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-module.c#L268
>>>>>>> That G_TYPE_CHECK_INSTANCE_TYPE always fails, so we never get any data
>>>>>>> prepended. G_TYPE_CHECK_INSTANCE_TYPE doesn't seem to be defined in this
>>>>>>> codebase either, which makes it a bit tricky to figure out why we're
>>>>>>> getting a negative value back from it.
>>>>>>> Talking to people about it on IRC has brought mixed results, it seems
>>>>>>> the extension interface hasn't been changed in a while, so most don't
>>>>>>> remember too much about it. I'll keep asking though, hoping someone in
>>>>>>> the know pops in.
>>>>>>> That's where I'm at currently, any help or clues are appreciated.
>>>>>> See this search results:
>>>>>> https://github.com/search?q=org%3AGNOME+NAUTILUS_TYPE_INFO_PROVIDER&type=Code
>>>>>> Especially this one:
>>>>>> https://github.com/GNOME/gnome-system-tools/blob/50f92695648a1d6340416c8db6eff7c38a7b3bbd/src/shares/nautilus/nautilus-shares.c#L349-L352
>>>>> Alright well I've been at this for a bit again with varying success.
>>>>> The issue is that this if statement here fails:
>>>>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-module.c#L290
>>>>> This is due to none of the modules in module_objects being of type
>>>>> NAUTILUS_TYPE_INFO_PROVIDER. I tried the method suggested
>>>>> (g_type_module_add_interface) but am unsure of how to get access to the
>>>>> correct module to add our NAUTILUS_TYPE_INFO_PROVIDER type to.
>>>>> Looking at nautilus-sendto-module.c (part of the included sendto
>>>>> extension) it gets a module from Nautilus, then calls a method that
>>>>> registers the NAUTILUS_TYPE_MENU_PROVIDER with that module:
>>>>> https://github.com/anoadragon453/nautilus/blob/master/nautilus-sendto-extension/nautilus-sendto-module.c#L33
>>>>> https://github.com/anoadragon453/nautilus/blob/master/nautilus-sendto-extension/nautilus-nste.c#L190
>>>>> So, nautilus-python is flexible and will do this for you given that your
>>>>> extensions asks for one of the variable provider types:
>>>>> https://github.com/anoadragon453/nautilus-python/blob/master/src/nautilus-python-object.c#L651
>>>>> So while writing this it seems that unless the new method (or any
>>>>> extension) is integrated into nautilus-python, it won't work to call it
>>>>> from nautilus. That wouldn't be such a big deal... if nautilus-python
>>>>> would work when I build and installed it. For that I'm having the
>>>>> following issue:
>>>>> [user@dev-fedora nautilus-python]$ nautilus
>>>>> /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py:40: Warning:
>>>>> specified class size for type 'PyGtkGenericCellRenderer' is smaller than
>>>>> the parent type's 'GtkCellRenderer' class size
>>>>>   from gtk import _gtk
>>>>> /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py:40: Warning:
>>>>> g_type_get_qdata: assertion 'node != NULL' failed
>>>>>   from gtk import _gtk
>>>>> ^CSegmentation fault (core dumped)
>>>>> [user@dev-fedora nautilus-python]$
>>>>> This happens with both my patched nautilus-python and the version
>>>>> directly from source. Some research online says that it has to do with
>>>>> importing both PyGObject and PyGTK libraries at the same time[1], which
>>>>> is interesting as both libraries are a requirement to build
>>>>> NautilusPython. This crash occurs with patched nautilus and nautilus
>>>>> from the repos, so it's definitely an issue with building NautilusPython
>>>>> in some form or another, even though the build completes successfully.
>>>>> The process of building it is as follows, simply:
>>>>> ./autogen
>>>>> make
>>>>> Then one copies the produced src/.libs/libnautilus-python.so to
>>>>> /usr/lib64/nautilus/extensions-3.0/ and nautilus will load it on startup.
>>>>> You can grab the source code from here: git clone
>>>>> git://git.gnome.org/nautilus-python
>>>>> And all the dependencies on Fedora: sudo dnf install gnome-common
>>>>> gtk-doc python-devel gnome-python2-devel
>>>>> And getting an error related to get_toolbar_items is normal, I just
>>>>> comment out that line. I don't believe it to be related to the segfault.
>>>> I get identical behavior.
>>>> Then switched to nautilus-3.0 branch and this one do not crash.
>>>> I get this at startup:
>>>>     Traceback (most recent call last):
>>>>       File "/usr/lib64/python2.7/site-packages/gi/__init__.py", line 39, 
>>>> in <module>
>>>>         raise ImportError(_static_binding_error)
>>>>     ImportError: When using gi.repository you must not import static 
>>>> modules like "gobject". Please change all occurrences of "import gobject" 
>>>> to "from gi.repository import GObject". See: 
>>>> https://bugzilla.gnome.org/show_bug.cgi?id=709183
>>>>     (nautilus:1168): Nautilus-Python-WARNING **: 
>>>> nautilus_python_init_python failed
>>>> Not sure if failing nautilus_python_init_python prevent the SEGV, or
>>>> previously it didn't got that far.
>>>> BTW that SEGV was infinite recursion like this:
>>>>     #39684 0x00007fffcb7d42d2 in pyg_type_get_bases () at 
>>>> /usr/lib64/python2.7/site-packages/gobject/_gobject.so
>>>>     #39685 0x00007fffcb7d4672 in pygobject_new_with_interfaces () at 
>>>> /usr/lib64/python2.7/site-packages/gobject/_gobject.so
>>>>     #39686 0x00007fffcb7d4285 in pygobject_lookup_class () at 
>>>> /usr/lib64/python2.7/site-packages/gobject/_gobject.so
>>>>     #39687 0x00007fffcb7d42d2 in pyg_type_get_bases () at 
>>>> /usr/lib64/python2.7/site-packages/gobject/_gobject.so
>>>>     #39688 0x00007fffcb7d4672 in pygobject_new_with_interfaces () at 
>>>> /usr/lib64/python2.7/site-packages/gobject/_gobject.so
>>> Wow, did not notice that branch. Yes that seems to be compatible with
>>> the latest Nautilus code.
>>> I can't explain it, but for some reason I do not get that error on my
>>> fedora-25-minimal VM (where I'm doing my testing), however I do get it
>>> on my fedora-25 VM. Instead, I get the following:
>>> [user@fedora-25-minimal np3]$ nautilus
>>> sys:1: PyGIWarning: Nautilus was imported without specifying a version
>>> first. Use gi.require_version('Nautilus', '3.0') before import to ensure
>>> that the right version gets loaded.
>>> ** (nautilus:11881): WARNING **: Unable to get contents of the bookmarks
>>> file: Error opening file /home/user/.gtk-bookmarks: No such file or
>>> directory
>>> update_file_info_full
>>> Traceback (most recent call last):
>>>   File
>>> "/usr/share/nautilus-python/extensions/update-file-info-async.py", line
>>> 9, in update_file_info_full
>>>     gobject.timeout_add_seconds(3, self.update_cb, provider, handle,
>>> closure)
>>> NameError: global name 'gobject' is not defined
>>> update_file_info_full
>>> However python extensions still seem to work fine, so I'll just continue
>>> on with this VM for now.
>>> Andrew Morgan
>> Alright, I've managed to narrow down the issue to a single line which is
>> baffling me and probably has something to do with 32-bit vs. 64-bit
>> system (I'm on 64-bit of course).
>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-mime-actions.c#L2489
>> So providers here (a GList *) is ending up as a different pointer than
>> what is being returned (another GList *), but instead of something
>> completely different, it's the same pointer but truncated 4 hex values
>> at the front.
>> Here we can see that without the truncation, we get a valid pointer
>> destination.
>> (gdb) print providers
>> $7 = 0x55f65ac0 = {Cannot access memory at address 0x55f65ac0
>> (gdb) print 0x555555f65ac0
>> $8 = 93825002789568
>> (gdb) Quit
>> (gdb)
>> So we're getting a 32-bit pointer instead of a 64-bit pointer, but I
>> can't see why as they're both GList *'s. As far as I know getting data
>> from this method works fine in other parts of the program, i.e. here:
>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-files-view.c#L4577
> Try:
>     print (GList*)0x555555f65ac0
> Have you tried make clean after switching branch? I've got some problems
> without that (like still old version reporting).

NautilusPython (which switching branches on fixed) is working swimmingly
now, though I did try to do a make clean and make to see if that had any
effect on this pointer nonsense but it didn't seem to. It's definitely a
problem contained within nautilus itself.

Doing a sizeof on both the returning GList* and the GList* we're storing
the data in both report 8 bytes, which is the correct size for a 64bit
pointer, so I have no idea why it's being truncated somewhere.

Doing the print statement you mentioned above does confirm that using
the correct address results in the correct data, while doing it on the
truncated address results in garbage data:

ret is 0x555555ab3d00, size: 8
providers is 0x55ab3d00, size: 8

Thread 1 "nautilus" received signal SIGSEGV, Segmentation fault.
0x00005555555fa960 in nautilus_mime_activate_files (parent_window=
2505                provider = NAUTILUS_INFO_PROVIDER (p->data);
(gdb) print (GList*) 0x555555ab3d00
$1 = 0x555555ab3d00 = {0x555555908e40}
(gdb) print ((GList*) 0x555555ab3d00)[0]
$2 = {data=0x555555908e40, next=0x0, prev=0x0}
(gdb) print (GList*) 0x55ab3d00
$3 = 0x55ab3d00 = {Cannot access memory at address 0x55ab3d00

As a workaround I've managed to get the correct address back again by
adding the truncated amount to the address, as well as setting the GList
to a static variable. Nautilus no longer crashes.

I'll leave a big TODO in there for now, but at least I'll be able to get
on with other things.

Andrew Morgan

You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to