[Geany-Devel] Segmentation fault when auto-close plug-in is enable [patch]

Matthew Brush mbrush at xxxxx
Thu Oct 24 04:54:01 UTC 2013

On 13-10-23 08:39 PM, Lex Trotman wrote:
> On 24 October 2013 13:09, Matthew Brush <mbrush at codebrainz.ca> wrote:
>> On 13-10-23 11:36 AM, Thomas Martitz wrote:
>>> [snip]
>> Regarding that pattern we discussed previously and used in this AutoClose
>> code for attaching data to a document, I'd be interested whether you or
>> anyone thinks this branch (last/top two commits) would be useful to plugins:
>> https://github.com/codebrainz/**geany/commits/document-**datalist<https://github.com/codebrainz/geany/commits/document-datalist>
> IIUC several plugins already use various methods of storing data for
> different documents and other Geany data structures.  Having a common way
> of doing that which cleans up when the Geany struct is destroyed is a good
> idea.
> But it seems a pity to have to duplicate the glib interface for each
> structure that offers the facility, can we just return the GData and let
> the plugins use the normal g_datalist functions?

Heh, I forgot to respond to this part. In my experience the other 
structures are often used in terms of the documents, or the Scintilla 
which already has this because it's a GObject or the UI widgets, which 
are also GObjects.

On the other hand, we could just make all the important structures 
GObjects and get the data lists for "free", and all the other goodness 
that comes with GObjects, but I digress.

>> IMO it'd be better to make GeanyDocument an actual GObject and get the
>> data lists for "free", but at least this is sort of a step in the same
>> direction.
>> [snip]
> PS On the recycling of doc structures and doc->is_valid, this does have the
> advantage (for a structure where miscellaneous pointers to the structure
> are going to exist in Geany and plugins) that doc pointers will always
> point to a geanydocument struct.  So the is_valid test is always right.  If
> the memory was returned and re-cycled into some other struct, the old doc
> pointers could point to anything, and could just as easily appear a valid
> document.  So its safer than the alternative, but the requirement to check
> is_valid really does need more visibility since its an unusual idiom.

We could just use the usual idiom (in G*) and use objects that have 
destruction signals and reference counting and such stuff that is useful 
for this type of scenario. IMO it'd be more useful to just treat 
GeanyDocuments like other stuff, and maybe having an _is_open() or 
_is_closed() function or something to see if the document you have a 
reference on is still open (if you didn't want to connect to its 
open/close signals it could emit).

Matthew Brush

More information about the Devel mailing list