David King [Sun, 19 Feb 2012 16:35:10 +0000 (16:35 +0000)]
docs: Fix GDBusProxy typo name → g-name
David King [Sun, 19 Feb 2012 16:36:28 +0000 (16:36 +0000)]
docs: Fix typo in GFileInputStream
g_seekable_stream_can_seek() → g_seekable_can_seek().
David King [Sun, 19 Feb 2012 16:37:55 +0000 (16:37 +0000)]
docs: Fix method names in GMenu and GMenuModel
David King [Sun, 19 Feb 2012 16:39:15 +0000 (16:39 +0000)]
docs: Fix GNetworkAddress typo
g_network_address_parse_host() → g_network_address_parse().
David King [Sun, 19 Feb 2012 16:40:06 +0000 (16:40 +0000)]
docs: Add documentation for supports_hostname in GProxy
Also fix a typo has → as.
David King [Sun, 19 Feb 2012 16:42:55 +0000 (16:42 +0000)]
docs: Correct GSocketClient::event link
David King [Sun, 19 Feb 2012 16:46:59 +0000 (16:46 +0000)]
docs: Fix some typos in GVolume
David King [Sun, 19 Feb 2012 16:48:20 +0000 (16:48 +0000)]
docs: Fix GFileAttribute link in GFileInfo
David King [Sun, 19 Feb 2012 16:53:30 +0000 (16:53 +0000)]
docs: Correct GUnixMount → GUnixMountEntry
Ryan Lortie [Mon, 20 Feb 2012 23:31:14 +0000 (00:31 +0100)]
GApplication: disable a broken test
This test made some invalid assumptions that are no longer true.
Disable it until we can figure out a better way.
Dan Winship [Mon, 13 Feb 2012 22:20:04 +0000 (17:20 -0500)]
gsocket: add g_socket_condition_timed_wait()
https://bugzilla.gnome.org/show_bug.cgi?id=667755
Matthias Clasen [Mon, 20 Feb 2012 23:26:06 +0000 (00:26 +0100)]
2.31.18
Matthias Clasen [Mon, 20 Feb 2012 23:25:31 +0000 (00:25 +0100)]
Don't rely on /bin/sh
Another Fedora UsrMove victim !
Ask H. Larsen [Mon, 20 Feb 2012 22:25:53 +0000 (23:25 +0100)]
Updated Danish translation
Luca Ferretti [Mon, 20 Feb 2012 14:14:18 +0000 (15:14 +0100)]
l10n: Updated Italian translation
Kjartan Maraas [Sun, 19 Feb 2012 14:26:13 +0000 (15:26 +0100)]
Updated Norwegian bokmål translation
David King [Sat, 18 Feb 2012 11:19:53 +0000 (11:19 +0000)]
docs: Fix g_drive_get_identifier() typo
David King [Sat, 18 Feb 2012 11:10:00 +0000 (11:10 +0000)]
docs: Add GIOModuleScope and GIOModuleScopeFlags
Fix some typos and add GIOModuleScope and GIOModuleScopeFlags to
gio-sections.txt.
David King [Sat, 18 Feb 2012 09:24:42 +0000 (09:24 +0000)]
docs: Typo fix GInitiable → GInitable
David King [Sat, 18 Feb 2012 09:20:02 +0000 (09:20 +0000)]
docs: Typo fixes for GMount
Yaron Shahrabani [Sat, 18 Feb 2012 09:07:12 +0000 (11:07 +0200)]
Updated Hebrew translation.
Peter Kjellerstedt [Thu, 16 Feb 2012 11:17:32 +0000 (12:17 +0100)]
Do not fail unit test due to gdb abbreviating strings
gdb by default will only print strings up to 200 characters. After that
it abbreviates them. This affects the run-assert-msg-test.sh script if
the path to the glib installation is too long (in our case it was 133
characters, 132 would still have worked...)
By having gdb execute "set print elements 0" before printing the assert
string, the limit on maximum number of characters to print is set to
unlimited.
Signed-off-by: Peter Kjellerstedt <pkj@axis.com>
https://bugzilla.gnome.org/show_bug.cgi?id=670218
David King [Fri, 17 Feb 2012 16:09:59 +0000 (16:09 +0000)]
docs: Fix a typo in the GSeekable documentation
Matthias Clasen [Thu, 16 Feb 2012 18:33:44 +0000 (13:33 -0500)]
Docs: fix reference to nonexisting function
The regex syntax docs referred to g_regex_fetch() when
g_match_info_fetch() was meant.
https://bugzilla.gnome.org/show_bug.cgi?id=669865
Ravi Sankar Guntur [Tue, 14 Feb 2012 16:35:33 +0000 (22:05 +0530)]
gio: fix memory leak in g_buffered_output_stream_write_async()
https://bugzilla.gnome.org/show_bug.cgi?id=670085
Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>
Christian Persch [Wed, 15 Feb 2012 14:25:47 +0000 (15:25 +0100)]
gbytes: Add G_BEGIN/END_DECL guards
Bug #670138.
Christian Persch [Sun, 5 Feb 2012 15:00:31 +0000 (16:00 +0100)]
Plug a mem leak in g_environ_unsetenv
And clarify the memory allocation requirement of the string arrays passed to
g_environ_{,un}setenv().
==9458== 10 bytes in 1 blocks are definitely lost in loss record 16 of 39
==9458== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==9458== by 0x4221A1F: vasprintf (vasprintf.c:78)
==9458== by 0x40C6065: g_vasprintf (gprintf.c:314)
==9458== by 0x409D894: g_strdup_vprintf (gstrfuncs.c:509)
==9458== by 0x409D8C9: g_strdup_printf (gstrfuncs.c:535)
==9458== by 0x40672E9: g_environ_setenv (genviron.c:156)
==9458== by 0x80490E7: test_environ_array (environment.c:78)
==9458== by 0x40A3DB5: test_case_run (gtestutils.c:1662)
==9458== by 0x40A40B2: g_test_run_suite_internal (gtestutils.c:1715)
==9458== by 0x40A417C: g_test_run_suite_internal (gtestutils.c:1726)
==9458== by 0x40A42F9: g_test_run_suite (gtestutils.c:1771)
==9458== by 0x40A3441: g_test_run (gtestutils.c:1319)
==9458== by 0x80493F1: main (environment.c:108)
Bug #669412.
Dan Winship [Fri, 10 Feb 2012 13:49:17 +0000 (08:49 -0500)]
Add G_GNUC_BEGIN/END_IGNORE_DEPRECATIONS
Add new macros to disable -Wdeprecated-declarations around a piece of
code, using the C99 (and GNU89) _Pragma() operator. Replace the
existing use of #pragma for this in gio, and suppress the warnings in
gvaluearray.c as well.
https://bugzilla.gnome.org/show_bug.cgi?id=669671
Dan Winship [Fri, 10 Feb 2012 13:24:28 +0000 (08:24 -0500)]
gobject: Use a destructor rather than g_atexit() for refcount debugging
https://bugzilla.gnome.org/show_bug.cgi?id=669671
Murray Cumming [Wed, 15 Feb 2012 10:53:03 +0000 (11:53 +0100)]
g_application_activate(): Fix typo in docs.
Giovanni Campagna [Mon, 13 Feb 2012 15:42:44 +0000 (16:42 +0100)]
GKeyFile: fix annotation of g_key_file_load_from_data
(array) without (element-type) means "array of the same type as
the C type", so gchar* with (array) is interpreted as an array of
strings. Since GKeyFiles must be UTF-8 encoded anyway, just
annotate it as a string.
https://bugzilla.gnome.org/show_bug.cgi?id=658484
Giovanni Campagna [Mon, 13 Feb 2012 15:41:20 +0000 (16:41 +0100)]
GDataInputStream: don't segfault on async line reads
If an async line read fails, it returns NULL. In that case, we
must return NULL before validating the line, or we segfault.
https://bugzilla.gnome.org/show_bug.cgi?id=658484
Kasia Bondarava [Tue, 14 Feb 2012 15:28:32 +0000 (18:28 +0300)]
Updated Belarusian translation.
Мирослав Николић [Tue, 14 Feb 2012 10:01:33 +0000 (11:01 +0100)]
Updated Serbian translation
Dan Winship [Wed, 8 Feb 2012 13:26:36 +0000 (08:26 -0500)]
gasyncqueue: deprecate GTimeVal-based methods, add relative-delay ones
https://bugzilla.gnome.org/show_bug.cgi?id=669670
Мирослав Николић [Sun, 12 Feb 2012 19:12:30 +0000 (20:12 +0100)]
Updated Serbian translation
Daniel Mustieles [Sun, 12 Feb 2012 12:21:17 +0000 (13:21 +0100)]
Updated Spanish translation
Matthias Clasen [Sat, 11 Feb 2012 03:13:36 +0000 (22:13 -0500)]
Add a few more missing functions to the docs
Matthias Clasen [Sat, 11 Feb 2012 03:08:47 +0000 (22:08 -0500)]
Add g_settings_new_full to the docs
Matthias Clasen [Sat, 11 Feb 2012 02:10:58 +0000 (21:10 -0500)]
Add g_test_undefined to the docs
Matthias Clasen [Sat, 11 Feb 2012 02:09:39 +0000 (21:09 -0500)]
Fix a parameter name mismatch
gtk-doc gets unhappy if parameters aren't named the same in
headers, sources and doc comments.
Matthias Clasen [Fri, 10 Feb 2012 23:06:10 +0000 (18:06 -0500)]
Drop menu markup docs
This does not exist anymore.
Javier Jardón [Fri, 10 Feb 2012 20:09:20 +0000 (20:09 +0000)]
docs: Fix some typos in gwin32inputstream
Marc-André Lureau [Fri, 10 Feb 2012 01:02:29 +0000 (02:02 +0100)]
socket/win32: flush pending read before signaling HUP
Unix and Windows gio GSocket behaves differently when the socket is
closed by the peer. On Unix, the client receives pending data before
receiving HUP. But on Windows, the HUP may come before, resulting in
unreliable and racy code. We should have same behaviour on all
platforms.
According to MSDN documentation: "an application should check for
remaining data upon receipt of FD_CLOSE to avoid any possibility of
losing data."
https://bugzilla.gnome.org/show_bug.cgi?id=669810
Marc-André Lureau [Fri, 10 Feb 2012 13:52:33 +0000 (14:52 +0100)]
gio/tests: add /socket/close_graceful test
Add a test to check that remaining data is read before the close
event is received.
https://bugzilla.gnome.org/show_bug.cgi?id=669810
Christophe Fergeau [Thu, 9 Feb 2012 16:59:55 +0000 (17:59 +0100)]
Fix g_hash_table_foreach crash with NULL hash table
When G_DISABLE_ASSERT is not defined, g_hash_table_foreach and
g_hash_table_find dereferences the hash table argument before
checking if it's NULL. This causes a crash when one of this function
is mistakenly called with a NULL argument instead of returning
with a warning through g_return_if_fail.
Chun-wei Fan [Fri, 10 Feb 2012 00:57:21 +0000 (08:57 +0800)]
Dist gio/gconstructor_as_data.h
This will avoid a dependency on a PERL installation for Visual Studio
builds.
Checked with mclasen in
https://bugzilla.gnome.org/show_bug.cgi?id=669538#c2
Chun-wei Fan [Tue, 7 Feb 2012 06:41:24 +0000 (14:41 +0800)]
Bug 669538-glib-compile-resources.c: Include io.h on Windows
This is needed for close() on Windows (Visual C++ specifically) so that
no C4013 (aka Implicit declaration of ...) errors/warnings will be emitted.
Richard Hughes [Thu, 9 Feb 2012 16:22:36 +0000 (16:22 +0000)]
Allow multiple --sourcedir options to glib-compile-resources
Ryan Lortie [Thu, 9 Feb 2012 17:15:49 +0000 (12:15 -0500)]
GApplication: put non-unique apps on D-Bus
For a number of reasons it might be useful to register the object paths
associated with a non-unique application so that the application can at
least field requests to its unique D-Bus name.
https://bugzilla.gnome.org/show_bug.cgi?id=647986
David King [Tue, 7 Feb 2012 09:02:51 +0000 (09:02 +0000)]
docs: Fix gdbus-codegen example XML
Without the surrounding <node> tags, gdbus-codegen does not generate any
implementation for the interface described in the introspection XML.
https://bugzilla.gnome.org/show_bug.cgi?id=669544
Dan Winship [Fri, 3 Feb 2012 17:14:06 +0000 (12:14 -0500)]
gthread-win32: update for g_get_monotonic_time() changes
g_cond_wait_until() was calling GetSystemTimeAsFileTime() to get the
current time, which is no longer what g_get_monotonic_time() returns.
https://bugzilla.gnome.org/show_bug.cgi?id=669329
Dan Winship [Fri, 3 Feb 2012 16:45:51 +0000 (11:45 -0500)]
glocalfile: fix error code when opening a directory on win32
g_file_read() was returning G_IO_ERROR_IS_DIRECTORY when you tried to
open a directory on unix, but G_IO_ERROR_PERMISSION_DENIED on win32.
Fix that, and add a test to tests/file.c
Pointed out on IRC by Paweł Forysiuk.
https://bugzilla.gnome.org/show_bug.cgi?id=669330
David Zeuthen [Wed, 8 Feb 2012 17:46:04 +0000 (12:46 -0500)]
GDBusProxy: Add G_DBUS_PROXY_FLAGS_GET_INVALIDATED_PROPERTIES flag
This is useful when using certain D-Bus services where the
PropertiesChanged signal does not include the property value such as
e.g. various systemd mechanisms, see e.g.
https://bugs.freedesktop.org/show_bug.cgi?id=37632
Signed-off-by: David Zeuthen <davidz@redhat.com>
Jesse van den Kieboom [Wed, 8 Feb 2012 16:13:34 +0000 (17:13 +0100)]
Retrieve cwd and environ in local GApplicationCommandLine
https://bugzilla.gnome.org/show_bug.cgi?id=669689
Ravi Sankar Guntur [Mon, 6 Feb 2012 17:40:34 +0000 (23:10 +0530)]
glib/tests: mainloop - fix a mem leak.
https://bugzilla.gnome.org/show_bug.cgi?id=669372
Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>
Ravi Sankar Guntur [Sat, 4 Feb 2012 18:12:41 +0000 (23:42 +0530)]
glib/tests: fix memory leak
https://bugzilla.gnome.org/show_bug.cgi?id=669372
Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>
Dan Winship [Wed, 8 Feb 2012 13:39:42 +0000 (08:39 -0500)]
gio: update .gitignore
Dan Winship [Wed, 8 Feb 2012 13:46:03 +0000 (08:46 -0500)]
glib/tests/option-context: remove unused tests
These tests were written, but then never used since it was decided to
add g_warnings() to goption.c in the cases they were supposed to be
testing. So anyway, just remove them.
Chun-wei Fan [Wed, 8 Feb 2012 12:41:13 +0000 (20:41 +0800)]
config.h.win32.in: Add note on if_nametoindex
This explains the current disabling of HAVE_IF_NAMETOINDEX as we are
still supporting Windows XP. This is expected to change when the patch
for XP support for if_nametoindex in accepted into master.
Chun-wei Fan [Wed, 8 Feb 2012 11:52:55 +0000 (19:52 +0800)]
config.h.win32.in: Updates
Make this more like the config.h.in template
Chun-wei Fan [Wed, 8 Feb 2012 07:09:13 +0000 (15:09 +0800)]
Update VS2010 property sheet
Should be $(CopyDir) not $(OutDir) here for VS2010. Oops :|
Chun-wei Fan [Wed, 8 Feb 2012 06:54:38 +0000 (14:54 +0800)]
Update VS property sheets
...To reflect the correct GIO headers to install
Dan Winship [Tue, 7 Feb 2012 15:54:22 +0000 (10:54 -0500)]
glib-mkenums: fix handling of forward enum declarations
Given
typedef enum MyFoo MyFoo;
glib-mkenums would get confused, not notice the ";", and then keep
skipping lines until it found one that started with a "{", possibly
even going into the next file.
Fix it to just ignore those lines instead (and also, to error out if
it hits eof while parsing an enum).
https://bugzilla.gnome.org/show_bug.cgi?id=669595
Javier Jardón [Tue, 7 Feb 2012 14:37:26 +0000 (15:37 +0100)]
docs: Add win32 gio specific api to the docs
Reported by Lethalman on IRC
Chun-wei Fan [Tue, 7 Feb 2012 09:05:22 +0000 (17:05 +0800)]
Add Visual C++ 2010 projects to compile GResource tools
Added projects to compile the glib-compile-resources and gresource(-tool)
utility programs during the Visual C++ 2010 build process, "install"
the resulting binaries upon successful compilation, and dist the new
.vcxproj and .vcxproj.filters files.
Also updated the property sheet and "install" project to make sure the new
.exe's are indeed "installed" and removed from the "install" project the
dependency on the testglib project as testglib is not an exhausive test on
GLib and people might want to make that project compile different test
programs as they might need.
Just wondering: I have updated the property sheet to create the
gconstructor_as_data.h header for glib-compile-resources, but is it better
to dist that generated header instead as the VS 2008/2010 projects will
depend on a working installation of PERL on Windows?
Chun-wei Fan [Tue, 7 Feb 2012 08:31:53 +0000 (16:31 +0800)]
Update Visual C++ 2008 projects
Make the "install" project depend on the glib-compile-resources gresource
projects so that these tools will be indeed installed. Missed that in my
last commit-oops.
Also make the "install" project not to depend on the testglib project as:
-the test program in the project is not an exhausive test of the GLib
libraries
-One may want to use the project to compile different test program(s), so
it might be better to keep the project but not "install" the resulting
.exe
Chun-wei Fan [Tue, 7 Feb 2012 06:37:57 +0000 (14:37 +0800)]
Add Visual C++ 2008 projects for GResource tools
Add projects to build the glib-compile-resources and gresource(-tool)
utilities, and "install" these tools upon successful compilation, and dist
the new projects.
One piece of note: will it be better to dist gconstructor_as_data.h instead
of generating it in the VS build process (I generated it in the property
sheet update in this commit)?
Visual C++ 2010 projects will follow shortly.
Christian Persch [Mon, 6 Feb 2012 21:33:19 +0000 (22:33 +0100)]
docs: Fix typo
Giovanni Campagna [Wed, 16 Nov 2011 23:52:59 +0000 (00:52 +0100)]
gtimezone: consider a leading : in TZ environment variable
When set to represent a zoneinfo file, TZ may start with :, therefore
glib needs to check it and ignore the first char when building the
resulting filename, or it won't be found.
Also, the path could be absolute, in which case it is wrong to
append /usr/share/timezone
https://bugzilla.gnome.org/show_bug.cgi?id=664237
Swecha Localization Team [Mon, 6 Feb 2012 11:45:14 +0000 (17:15 +0530)]
Updated Telugu Translation
Fran Diéguez [Mon, 6 Feb 2012 01:54:44 +0000 (02:54 +0100)]
Updated Galician translations
Christian Persch [Sun, 5 Feb 2012 19:00:16 +0000 (20:00 +0100)]
Revert "Plug a mem leak in g_environ_unsetenv"
This reverts commit
2f4b46e3783b04cddcb2622a57b2a8e692cff68a, which was
pushed accidentally.
Christian Persch [Sun, 5 Feb 2012 18:55:45 +0000 (19:55 +0100)]
resources: Consolidate creation of GResource into one place
Christian Persch [Sun, 5 Feb 2012 15:44:10 +0000 (16:44 +0100)]
resources: tests: Plug a mem leak
==1265== 84 (8 direct, 76 indirect) bytes in 1 blocks are definitely lost in loss record 793 of 827
==1265== at 0x4029467: calloc (vg_replace_malloc.c:467)
==1265== by 0x408479B: standard_calloc (gmem.c:104)
==1265== by 0x4084846: g_malloc0 (gmem.c:189)
==1265== by 0x4084B2D: g_malloc0_n (gmem.c:385)
==1265== by 0x4228A98: g_resource_load (gresource.c:253)
==1265== by 0x804A56D: test_resource_registred (resources.c:198)
Christian Persch [Sun, 5 Feb 2012 15:39:51 +0000 (16:39 +0100)]
resources: tests: Plug a mem leak
==509== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 828 of 837
==509== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==509== by 0x4084724: standard_malloc (gmem.c:85)
==509== by 0x40847C7: g_malloc (gmem.c:159)
==509== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==509== by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==509== by 0x405390D: g_bytes_new_take (gbytes.c:122)
==509== by 0x804A48C: test_resource_data (resources.c:174)
Christian Persch [Sun, 5 Feb 2012 15:38:36 +0000 (16:38 +0100)]
resources: tests: Plug a mem leak
==29204== 11,456 (84 direct, 11,372 indirect) bytes in 1 blocks are definitely lost in loss record 859 of 861
==29204== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204== by 0x4084724: standard_malloc (gmem.c:85)
==29204== by 0x40847C7: g_malloc (gmem.c:159)
==29204== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204== by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204== by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204== by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204== by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204== by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204== by 0x417C1DB: g_object_new (gobject.c:1535)
==29204== by 0x41E5E29: g_converter_input_stream_new (gconverterinputstream.c:204)
==29204== by 0x4228D38: g_resource_open_stream (gresource.c:363)
Christian Persch [Sun, 5 Feb 2012 15:37:36 +0000 (16:37 +0100)]
resources: Init refcount to 1
This bug was exposed by fixing the following leak in the resources test:
==29204== 11,456 (84 direct, 11,372 indirect) bytes in 1 blocks are definitely lost in loss record 859 of 861
==29204== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204== by 0x4084724: standard_malloc (gmem.c:85)
==29204== by 0x40847C7: g_malloc (gmem.c:159)
==29204== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204== by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204== by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204== by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204== by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204== by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204== by 0x417C1DB: g_object_new (gobject.c:1535)
==29204== by 0x41E5E29: g_converter_input_stream_new (gconverterinputstream.c:204)
==29204== by 0x4228D38: g_resource_open_stream (gresource.c:363)
Christian Persch [Sun, 5 Feb 2012 15:18:34 +0000 (16:18 +0100)]
resources: Plug a mem leak
==29204== 7,192 (76 direct, 7,116 indirect) bytes in 1 blocks are definitely lost in loss record 855 of 861
==29204== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204== by 0x4084724: standard_malloc (gmem.c:85)
==29204== by 0x40847C7: g_malloc (gmem.c:159)
==29204== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204== by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204== by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204== by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204== by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204== by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204== by 0x417C1DB: g_object_new (gobject.c:1535)
==29204== by 0x424E815: g_zlib_decompressor_new (gzlibdecompressor.c:270)
==29204== by 0x4228DD8: g_resource_lookup_data (gresource.c:422)
Christian Persch [Sun, 5 Feb 2012 15:16:37 +0000 (16:16 +0100)]
resources: tests: Plug a mem leak
==28778== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 842 of 863
==28778== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28778== by 0x4084724: standard_malloc (gmem.c:85)
==28778== by 0x40847C7: g_malloc (gmem.c:159)
==28778== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==28778== by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==28778== by 0x405390D: g_bytes_new_take (gbytes.c:122)
==28778== by 0x804C2B1: test_uri_query_info (resources.c:435)
Christian Persch [Sun, 5 Feb 2012 15:14:21 +0000 (16:14 +0100)]
resources: tests: Plug a mem leak
==28318== 38 (12 direct, 26 indirect) bytes in 1 blocks are definitely lost in loss record 613 of 865
==28318== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28318== by 0x4084724: standard_malloc (gmem.c:85)
==28318== by 0x40847C7: g_malloc (gmem.c:159)
==28318== by 0x4084AB4: g_malloc_n (gmem.c:361)
==28318== by 0x4229599: g_resources_enumerate_children (gresource.c:806)
==28318== by 0x804B39E: test_resource_registred (resources.c:283)
Christian Persch [Sun, 5 Feb 2012 15:12:23 +0000 (16:12 +0100)]
resources: tests: Plug a mem leak
==27820== 31 bytes in 1 blocks are definitely lost in loss record 587 of 866
==27820== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27820== by 0x4084724: standard_malloc (gmem.c:85)
==27820== by 0x40847C7: g_malloc (gmem.c:159)
==27820== by 0x4084AB4: g_malloc_n (gmem.c:361)
==27820== by 0x409D6A1: g_strdup (gstrfuncs.c:356)
==27820== by 0x4069FF7: g_get_current_dir (gfileutils.c:2544)
==27820== by 0x804BCA7: test_resource_module (resources.c:370)
Christian Persch [Sun, 5 Feb 2012 15:10:48 +0000 (16:10 +0100)]
resources: Plug a mem leak
==27020== 44 (24 direct, 20 indirect) bytes in 1 blocks are definitely lost in loss record 684 of 936
==27020== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27020== by 0x4084724: standard_malloc (gmem.c:85)
==27020== by 0x40847C7: g_malloc (gmem.c:159)
==27020== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==27020== by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==27020== by 0x40B5277: g_variant_get_variant (gvariant.c:749)
==27020== by 0x4273182: gvdb_table_value_from_item (gvdb-reader.c:478)
==27020== by 0x42731E8: gvdb_table_get_value (gvdb-reader.c:509)
==27020== by 0x4228B36: do_lookup (gresource.c:280)
==27020== by 0x4228F56: g_resource_get_info (gresource.c:492)
Christian Persch [Sun, 5 Feb 2012 15:08:10 +0000 (16:08 +0100)]
resources: Plug a mem leak
==26427== 24 bytes in 1 blocks are definitely lost in loss record 608 of 965
==26427== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==26427== by 0x4084724: standard_malloc (gmem.c:85)
==26427== by 0x40847C7: g_malloc (gmem.c:159)
==26427== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==26427== by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==26427== by 0x40BA89F: g_variant_valist_get (gvariant.c:4482)
==26427== by 0x40BAC23: g_variant_get_va (gvariant.c:4681)
==26427== by 0x40BAB29: g_variant_get (gvariant.c:4633)
==26427== by 0x4228BA5: do_lookup (gresource.c:293)
==26427== by 0x4228F51: g_resource_get_info (gresource.c:493)
Christian Persch [Sun, 5 Feb 2012 15:00:31 +0000 (16:00 +0100)]
Plug a mem leak in g_environ_unsetenv
==9458== 10 bytes in 1 blocks are definitely lost in loss record 16 of 39
==9458== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==9458== by 0x4221A1F: vasprintf (vasprintf.c:78)
==9458== by 0x40C6065: g_vasprintf (gprintf.c:314)
==9458== by 0x409D894: g_strdup_vprintf (gstrfuncs.c:509)
==9458== by 0x409D8C9: g_strdup_printf (gstrfuncs.c:535)
==9458== by 0x40672E9: g_environ_setenv (genviron.c:156)
==9458== by 0x80490E7: test_environ_array (environment.c:78)
==9458== by 0x40A3DB5: test_case_run (gtestutils.c:1662)
==9458== by 0x40A40B2: g_test_run_suite_internal (gtestutils.c:1715)
==9458== by 0x40A417C: g_test_run_suite_internal (gtestutils.c:1726)
==9458== by 0x40A42F9: g_test_run_suite (gtestutils.c:1771)
==9458== by 0x40A3441: g_test_run (gtestutils.c:1319)
==9458== by 0x80493F1: main (environment.c:108)
Bug #669412.
Matthias Clasen [Sun, 5 Feb 2012 03:54:58 +0000 (22:54 -0500)]
Back to odd
Matthias Clasen [Sat, 4 Feb 2012 23:43:13 +0000 (18:43 -0500)]
2.31.16
Matthias Clasen [Sat, 4 Feb 2012 16:51:45 +0000 (11:51 -0500)]
Updates
Ravi Sankar Guntur [Fri, 3 Feb 2012 18:44:56 +0000 (00:14 +0530)]
fix memory leak in g_bookmark_file_parse()
https://bugzilla.gnome.org/show_bug.cgi?id=669334
Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>
Kjartan Maraas [Sat, 4 Feb 2012 11:32:51 +0000 (12:32 +0100)]
Updated Norwegian bokmål translation
Dan Winship [Fri, 3 Feb 2012 16:29:46 +0000 (11:29 -0500)]
gio/tests/file: use g_file_new_tmp()
Rather than misusing g_file_open_tmp(), misuse g_file_new_tmp()
instead. Progress! (Also, gets rid of a compile warning about close()
on win32.)
Dan Winship [Fri, 3 Feb 2012 17:08:40 +0000 (12:08 -0500)]
gio/tests/socket-common.c: add a missing #ifdef G_OS_UNIX
Dan Winship [Fri, 3 Feb 2012 16:39:27 +0000 (11:39 -0500)]
gioenums.h: clean up a few GIOErrorEnum descriptions
Daniel Mustieles [Fri, 3 Feb 2012 15:29:28 +0000 (16:29 +0100)]
Updated Spanish translation
Alexander Larsson [Fri, 3 Feb 2012 14:11:23 +0000 (15:11 +0100)]
Fix warning to refer to to-pixdata, not xmllint
Alexander Larsson [Fri, 3 Feb 2012 14:05:03 +0000 (15:05 +0100)]
Fix GResourceFile get_parent()
This was erronously losing the last char.
Christian Persch [Wed, 1 Feb 2012 13:59:22 +0000 (14:59 +0100)]
resource: tests: Use g_assert_cmp[u]int
... instead of just g_assert(), so when the test does fail, one immediately
can see the actual value the variable had.
Christian Persch [Tue, 31 Jan 2012 17:10:55 +0000 (18:10 +0100)]
resources: compiler: Fix entity processing of xml-stripblanks
Preserve entities instead of replacing them!
Bug #669173.
Christian Persch [Tue, 31 Jan 2012 17:01:25 +0000 (18:01 +0100)]
resources: compiler: Make to-pixbuf failure fatal
Bug #669123.
Ryan Lortie [Thu, 2 Feb 2012 15:48:11 +0000 (10:48 -0500)]
gsettings tool: fix a memory error
8852d4e9a08e7fbc9df7fb99a54b112f5049ee19 introduced a memory error by
taking the type of a GVariant, freeing the GVariant and using the type
after the free.
This delays the free until after we've used the type.
https://bugzilla.gnome.org/show_bug.cgi?id=669253