GNOME Bugzilla – Bug 144697
load_directory in async-handle.cc crashes.
Last modified: 2011-01-16 23:36:21 UTC
given the patch of the bug 144627 (http://bugzilla.gnome.org/show_bug.cgi?id=144627) I got the following error when using load_directory in async-handler.cc. (shotit:13822): GLib-GObject-CRITICAL **: file gobject.c: line 1597 (g_object_get_qdata): assertion `G_IS_OBJECT (object)' failed When debugging I realised that the error appears from within a call to Glib::wrap_auto(...) from within a call to TypeTraits<Glib::RefPtr<T = FileInfo> >::to_cpp_type(...) in containerhandle_shared.h (in glibmm) I write a specialisation of TypeTraits<Glib::RefPtr<FileInfo> > which uses the Glib::wrap(GnomeVFSFileInfo, bool) method instead of wrap_auto and it seemed to work. I can't send a patch since I don't find in file-info.hg any wrap method!? when I add the TypeTraits specialization to the end of file-info.hg, I got a error when building since in the generated file-info.h wrap method appears after my modification! is there a document that describes how .hg/.ccg file works? *ANOTHER BUG* in SignalProxy_AsyncLoadDirectory::c_callback: the ownership parameter to ListHandle should be OWNERSHIP_NONE instead of OWNERSHIP_SHALLOW.
> I can't send a patch since I don't find in file-info.hg any wrap method!? when I > add the TypeTraits specialization to the end of file-info.hg, I got a error when > building since in the generated file-info.h wrap method appears after my > modification! I don't understand what you mean, but if you post the unfinished patch then I might be able to understand. Sorry for the delay - I will investigate this in the next few days. glibmm/docs/internal has some documentation about gmmproc. If you are using cvs and autogen.sh then it should just work.
Created attachment 29073 [details] the file-info.h that solves the problem of load_directory.
That is not a patch. Here is some help about creating patches: http://www.gtkmm.org/bugs.shtml#CreatingPatches
There are some changes in the patch here http://bugzilla.gnome.org/show_bug.cgi?id=144627 that might fix this problem for you. Make the OWNER_* changes, but not the other ones. I would like to hear whether that fixes the problem for you.
I don't understand! :p Actually Bug 144697 contains two bugs: ownership and wrapping. I sent ownership correction on Bug 144627, and if I understand you, it is a good change (I should keep it). What about wrapping then? I know that the file 'file-info.h' I sent is not a patch. It was just a hint about what gmmproc should generate... I've read the glibmm/docs/internal docs about gmmproc but I still do not know how to change file-info.hg so it generates the 'file-info.h' I sent. Maybe should I read other .hg/*.ccg files to understand how gmmproc works...
Please try the latest tarball or cvs version.
Please respond.
Really sorry... I will respond these week or in 2 weeks (next week I am in holiday).
I tested the cvs version. The bug is still there. I don't know if my solution (specialisation of TypeTraits<>::to_cpp_type) is a 'good one' but it solves the problem. I'll try to send an example that uses that api...
What's the status of this now?
Given the definition of 'status', I may say 'NEW'. I have a hacked (working) version on my computer. But I can't send any patch: poor knowledge of gmmproc... Someone else should take a look to what have been said above... a small move is necessary to have this bug 'solved'... As soon as I have an example I will send it here.
> I have a hacked (working) version on my computer. But I can't send any patch: > poor knowledge of gmmproc... You need to edit the .hg/.ccg files. Hopefully it is easy. See also: http://www.gtkmm.org/bugs.shtml#CreatingPatches At the least, please give us a diff of the generated .h/.cc files. > Someone else should take a look to what have been said above... a small move is > necessary to have this bug 'solved'... Sorry, there's not enough information there.
Have you made any progress with this? I can't do anything until I see a patch.
There's no patch and no test case here. Should I close thi bug, or will you respond?
I am sorry, I won't respond. I no more have a working environment.
> *ANOTHER BUG* in SignalProxy_AsyncLoadDirectory::c_callback: > the ownership parameter to ListHandle should be OWNERSHIP_NONE instead of > OWNERSHIP_SHALLOW. It seems to be OWNERSHIP_NONE already in cvs. As for the rest of this, without a test case or even a description of code that triggers the bug, I can't see what bug you are reporting, though it very possibly exists.
Seems that this problem still exists. I've created a test case that shows the same problem on my system (Ubuntu Breezy, gnome-vfs 2.12.0). I tried to make a patch for file-info.hg but got the same result as the initial reporter. Compilation fails because the Glib::wrap Function for GnomeVFSFileInfo* is placed below the code that uses it in the generated file-info.h file.
Created attachment 54775 [details] Test case
Created attachment 54776 [details] [review] Incorrect patch for file-info.hg
Many thanks. > Compilation fails because the Glib::wrap Function for > GnomeVFSFileInfo* is placed below the code that uses it in the generated > file-info.h file. Can you add a prototype declaration to solve that problem? I'll need to investigate exactly what this does (or what it was doing wrong before) if you can't explain it to me. A ChangeLog entry would be a good start.
The bug seems to be related to the template <class T> struct TypeTraits< Glib::RefPtr<const T> > in glibmm/glib/glibmm/containerhandle_shared.h. This template is useable for gobjects only but GnomeVfsFileInfo isn't a gobject. The patch adds a specialized version for Glib::RefPtr<Gnome::Vfs::FileInfo> that uses Glib::wrap in the to_cpp_type() function und gnome_vfs_file_info_unref(..) in release_c_type(...). The patch for bug #132187 might be the reason for this problem.
Created attachment 54826 [details] [review] Adjusted patch
This seems sensible to me. Well done. Applied.
reopening so I can close it as fixed.