After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755859 - ges-lanch and gst-launcher have leakages
ges-lanch and gst-launcher have leakages
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-editing-services
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-09-30 08:38 UTC by Justin Kim
Modified: 2015-10-19 09:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[1/3] project uri string (1.75 KB, patch)
2015-09-30 08:39 UTC, Justin Kim
none Details | Review
[2/3] improve doc (816 bytes, patch)
2015-09-30 08:39 UTC, Justin Kim
none Details | Review
[3/3] sanitized_timeline string (909 bytes, patch)
2015-09-30 08:40 UTC, Justin Kim
accepted-commit_now Details | Review
and one more fix for launch (802 bytes, patch)
2015-09-30 08:42 UTC, Justin Kim
accepted-commit_now Details | Review
[2/3] improve doc (812 bytes, patch)
2015-10-01 02:38 UTC, Justin Kim
none Details | Review
[2/3] improve doc (828 bytes, patch)
2015-10-01 02:39 UTC, Justin Kim
none Details | Review
[1/3] project uri string (1.57 KB, patch)
2015-10-01 02:43 UTC, Justin Kim
none Details | Review

Description Justin Kim 2015-09-30 08:38:42 UTC
"gst-validate (--sync) ges --valgrind" reports lots of leakages so I don't have idea how I can organize issues clearly. I just create an issue based on a group of files or APIs. If someone has great idea to handle this kind of process, let me know. thank you!

Anyway, here are my patches to fix launch{er} leakages.
Comment 1 Justin Kim 2015-09-30 08:39:30 UTC
Created attachment 312402 [details] [review]
[1/3] project uri string
Comment 2 Justin Kim 2015-09-30 08:39:55 UTC
Created attachment 312404 [details] [review]
[2/3] improve doc
Comment 3 Justin Kim 2015-09-30 08:40:22 UTC
Created attachment 312405 [details] [review]
[3/3] sanitized_timeline string
Comment 4 Justin Kim 2015-09-30 08:42:56 UTC
Created attachment 312406 [details] [review]
and one more fix for launch
Comment 5 Thibault Saunier 2015-09-30 09:41:10 UTC
Review of attachment 312404 [details] [review]:

::: ges/ges-project.c
@@ +1033,3 @@
  * Retrieve the uri that is currently set on @project
  *
+ * Returns: a newly allocated string representing uri.

Then we should specify (transfer full)
Comment 6 Thibault Saunier 2015-09-30 09:41:33 UTC
Review of attachment 312405 [details] [review]:

OK
Comment 7 Thibault Saunier 2015-09-30 09:41:35 UTC
Review of attachment 312405 [details] [review]:

OK
Comment 8 Thibault Saunier 2015-09-30 09:42:29 UTC
Review of attachment 312402 [details] [review]:

::: tools/ges-launcher.c
@@ -233,2 +237,3 @@
   }
 
+  gst_object_unref (project);

Looks weird to unref it here, where does that ref come from?
Comment 9 Thibault Saunier 2015-09-30 09:42:56 UTC
Review of attachment 312406 [details] [review]:

OK
Comment 10 Justin Kim 2015-10-01 02:38:12 UTC
Created attachment 312462 [details] [review]
[2/3] improve doc
Comment 11 Justin Kim 2015-10-01 02:39:09 UTC
Created attachment 312463 [details] [review]
[2/3] improve doc
Comment 12 Justin Kim 2015-10-01 02:43:18 UTC
Created attachment 312464 [details] [review]
[1/3] project uri string
Comment 14 Sebastian Dröge (slomo) 2015-10-19 08:15:46 UTC
Why are they different "pull requests" in phabricator instead of just having one branch there?
Comment 15 Thibault Saunier 2015-10-19 09:20:11 UTC
(In reply to Sebastian Dröge (slomo) from comment #14)
> Why are they different "pull requests" in phabricator instead of just having
> one branch there?

One revision per commit is the way it works (same as one patch per commit here). The workflow we have (and that let us have a clear view of what to do) is to have a task per branch, similar to https://phabricator.freedesktop.org/T3373