Comment 105 for bug 1439288

My excuses for the high traffic I may cause here.

Something that I noticed and that raised some questions in my mind was this:

why does preference object reference only cause problems in the thunar-transfer-job.c file ?

I mean, there are plenty of preference object references spread over the entire thunar code. Why is the crash only happen in this particular *.c file ? This should also happen, if I query other settings that way.

The functions "thunar_transfer_job_veryify_destination" and "thunar_transfer_job_execute" are connected together.

Means "thunar_transfer_job_execute" is the top function that executes the "thunar_transfer_job_veryify_destination" function.

But thunar_transfer_job_execute seem to be a exojob_class->execute reference as found in the thunar_transfer_job_class_init function of the same file. This is the only "unique" difference (handed over to exo) to most other areas of thunar where the preferences object is referenced.

So basicly and theoreticaly it doesn't matter whether we g_object_get "misc-file-size-binary" or anything else. It will result in a crash.

thunar_transfer_job_veryify_destination (using GIT version as is)

preferences = thunar_preferences_get ();
g_object_get (preferences, "misc-file-size-binary", &file_size_binary, NULL);
g_object_unref (preferences);

... we know will crash ...

Replaced "misc-file-size-binary" with this:
g_object_get (preferences, "misc-middle-click-in-tab", &open_in_tab, NULL);

... crash ...

Now only this:
preferences = thunar_preferences_get ();
g_object_unref (preferences);

... no crash ...

Let's make some adress tests. Is the object in preferences still the same object as in thunar_transfer_job_veryify_destination ?

thunar_preferences_get_property: preferences object address: 8c1c850
thunar_transfer_job_veryify_destination: preferences object address: 8c1c850

Yes it is. At least let's believe this is.

Now that I assume that this object is being handed over to exo (?). Does exo still know that this address is an g_object ? Or does g_object_get know that this still is an object ? Let's put some casts around it:

preferences = thunar_preferences_get ();
g_object_get (G_OBJECT (preferences), "misc-file-size-binary", &file_size_binary, NULL);
g_object_unref (G_OBJECT (preferences));

... sadly this leads to crashes after a while again ...

I was typing this text during experiments with thunar over the past 1-2 hours now. I thought that it might be that the object reference might become broken and g_object_get might get irritated that this may not be understood as object. But this has proven me wrong ...

Still the only unique difference between other parts of thunar and here is, exo.