Seg fault on closing the xpad
Bug #1333727 reported by
Sagar Ghuge
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Xpad |
Fix Released
|
Low
|
Sagar Ghuge |
Bug Description
Steps to produce the bug :
1. launch xpad
2. try to close xpad
It will gets closed by throwing seg fault.
Related branches
lp:~ghugesss/xpad/xpad
- Arthur Borsboom: Approve (quick code test)
-
Diff: 56 lines (+4/-8)3 files modifiedChangeLog (+1/-0)
src/xpad-app.c (+3/-7)
src/xpad-pad-group.c (+0/-1)
Changed in xpad: | |
assignee: | nobody → Sagar Ghuge (ghugesss) |
Changed in xpad: | |
importance: | Undecided → Low |
status: | Confirmed → Fix Committed |
Changed in xpad: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Hi Sagar,
Thanks for looking into this and supplying a possible fix.
I haven't tested it, but I do have some questions.
Since the destroy function has been run before, the group->priv->pads object should be destroyed and therefore this unref seems to me not necessary and will never be called, since group->priv->pads is not an object anymore. Would you mind to verify if this added piece of code, will ever be called? Besides that, it is a good habit too set a variable to NULL when not used anymore.
- group->priv->pads = NULL; >priv-> pads)) >priv-> pads);
+
+ if (G_IS_OBJECT (group-
+ {
+ g_object_unref (group-
+ }
Also by removing the code below, I guess that you introduce a memory leak on application exit. You can verify this with the application gobject-list (https:/ /github. com/danni/ gobject- list). On application exit, there should be no references to 'xpad' objects anymore. The command line I use for this is:
LD_PRELOAD= ~/home/ development/ gojbect- list/libgobject -list.so src/xpad | grep xpad
- /* Free the memory used by group. */
- if (G_IS_OBJECT (pad_group))
- g_object_unref (pad_group);
-
My guess of the cause of the segmentation fault is a timing issue (race condition), between different threads while destroying the different objects. However, I don't have a solution for this problem yet.
Can you verify that
- the g_object_unref (group->priv->pads) is ever called?
- there are no memory leaks of xpad objects?
Cheers,
Arthur.