==7347== 1,201 bytes in 1 blocks are definitely lost in loss record 5,016 of 5,107
==7347== at 0x4A06B0F: calloc (vg_replace_malloc.c:593)
==7347== by 0x39B90548E6: g_malloc0 (gmem.c:189)
==7347== by 0x39B9026F8D: g_base64_decode (gbase64.c:407)
==7347== by 0x4C51CA1: parse_old_openssl_key_file (crypto.c:227)
==7347== by 0x4C51EC3: crypto_decrypt_private_key_data (crypto.c:497)
==7347== by 0x4C529BE: crypto_verify_private_key_data (crypto.c:706)
==7347== by 0x4C52B7B: crypto_verify_private_key (crypto.c:735)
==7347== by 0x4C5CCC5: nm_setting_802_1x_set_private_key (nm-setting-8021x.c:1633)
==7347== by 0xC8F64D4: eap_tls_reader (reader.c:2270)
==7347== by 0xC8F4886: fill_8021x (reader.c:2704)
==7347== by 0xC8F8311: wireless_connection_from_ifcfg (reader.c:2825)
==7347== by 0xC8FAFD2: connection_from_file (reader.c:4303)
==23089== 342 bytes in 38 blocks are definitely lost in loss record 4,870 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B906A4BB: g_strdup (gstrfuncs.c:356)
==23089== by 0x31FC02DA90: set_property (nm-setting-pppoe.c:220)
==23089== by 0x39B9819972: g_object_set_property (gobject.c:1352)
==23089== by 0x31FC01A9A7: nm_setting_enumerate_values (nm-setting.c:589)
==23089== by 0x31FC01AA81: nm_setting_duplicate (nm-setting.c:264)
==23089== by 0x31FC01633B: duplicate_cb (nm-connection.c:1182)
==23089== by 0x39B903F8DF: g_hash_table_foreach (ghash.c:1524)
==23089== by 0x31FC01756C: nm_connection_duplicate (nm-connection.c:1203)
==23089== by 0x4A7BE3: get_settings_auth_cb (nm-settings-connection.c:1062)
==23089== by 0x4A5624: auth_start (nm-settings-connection.c:1008)
'str' was not freed anywhere.
==23089== 2,072 (24 direct, 2,048 indirect) bytes in 1 blocks are definitely lost in loss record 5,063 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089== by 0x39B906C7FA: g_string_sized_new (gstring.c:121)
==23089== by 0x39B906CE75: g_string_new_len (gstring.c:186)
==23089== by 0x31FC0149CE: parse_old_openssl_key_file (crypto.c:150)
==23089== by 0x31FC014E33: crypto_decrypt_private_key_data (crypto.c:494)
==23089== by 0x31FC01592E: crypto_verify_private_key_data (crypto.c:703)
==23089== by 0x31FC015AEB: crypto_verify_private_key (crypto.c:732)
==23089== by 0x31FC0200E5: nm_setting_802_1x_set_private_key (nm-setting-8021x.c:1640)
==23089== by 0xC694304: eap_tls_reader (reader.c:2280)
==23089== by 0xC692756: fill_8021x (reader.c:2714)
If the certificate's format was valid, but we're asked to refer to it by
paths instead of using the raw data, 'data' would be leaked.
==23089== 8,232 (40 direct, 8,192 indirect) bytes in 1 blocks are definitely lost in loss record 5,109 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089== by 0x39B9024539: g_array_sized_new (garray.c:195)
==23089== by 0x31FC0146EA: file_to_g_byte_array (crypto.c:319)
==23089== by 0x31FC01543B: crypto_load_and_verify_certificate (crypto.c:606)
==23089== by 0x31FC01ED26: nm_setting_802_1x_set_client_cert (nm-setting-8021x.c:819)
==23089== by 0xC6944A4: eap_tls_reader (reader.c:2316)
==23089== by 0xC692756: fill_8021x (reader.c:2714)
==23089== by 0xC696151: wireless_connection_from_ifcfg (reader.c:2832)
==23089== by 0xC698E3A: connection_from_file (reader.c:4316)
==23089== by 0xC69135C: nm_ifcfg_connection_new (nm-ifcfg-connection.c:119)
==23089==
==23089== 8,352 (160 direct, 8,192 indirect) bytes in 4 blocks are definitely lost in loss record 5,110 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089== by 0x39B9024539: g_array_sized_new (garray.c:195)
==23089== by 0x31FC0146EA: file_to_g_byte_array (crypto.c:319)
==23089== by 0x31FC01543B: crypto_load_and_verify_certificate (crypto.c:606)
==23089== by 0x31FC01E5E6: nm_setting_802_1x_set_ca_cert (nm-setting-8021x.c:538)
==23089== by 0xC694DD8: eap_peap_reader (reader.c:2358)
==23089== by 0xC692756: fill_8021x (reader.c:2714)
==23089== by 0xC696151: wireless_connection_from_ifcfg (reader.c:2832)
==23089== by 0xC698E3A: connection_from_file (reader.c:4316)
==23089== by 0xC69135C: nm_ifcfg_connection_new (nm-ifcfg-connection.c:119)
==23089== 7,293 (1,248 direct, 6,045 indirect) bytes in 39 blocks are definitely lost in loss record 5,100 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089== by 0x39B9024E90: g_ptr_array_sized_new (garray.c:884)
==23089== by 0x31FB81B3FC: ptrarray_copy (dbus-gvalue-utils.c:1047)
==23089== by 0x31FB81845C: proxy_value_copy (dbus-gtype-specialized.c:446)
==23089== by 0x39B980F51E: g_boxed_copy (gboxed.c:359)
==23089== by 0x31FC03134C: set_property (nm-setting-wired.c:619)
==23089== by 0x39B9819972: g_object_set_property (gobject.c:1352)
==23089== by 0x31FC01A9A7: nm_setting_enumerate_values (nm-setting.c:589)
==23089== by 0x31FC01AA81: nm_setting_duplicate (nm-setting.c:264)
==23089== by 0x31FC01633B: duplicate_cb (nm-connection.c:1182)
==23089== 38,232 (4,248 direct, 33,984 indirect) bytes in 177 blocks are definitely lost in loss record 5,122 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089== by 0x39B98371B1: g_value_array_new (gvaluearray.c:140)
==23089== by 0x31FB81B67D: valuearray_constructor (dbus-gvalue-utils.c:771)
==23089== by 0x42DD8F: get_property (nm-device.c:4675)
==23089== by 0x39B9819C64: g_object_get_property (gobject.c:1289)
==23089== by 0x31FB80DA49: object_registration_message (dbus-gobject.c:1322)
==23089== by 0x363961DA44: _dbus_object_tree_dispatch_and_unlock (dbus-object-tree.c:858)
==23089== by 0x363960FA82: dbus_connection_dispatch (dbus-connection.c:4685)
==23089== by 0x31FB80AC44: message_queue_dispatch (dbus-gmain.c:90)
==23089== by 0x39B904EC54: g_main_context_dispatch (gmain.c:2539)
'device' is freed by nm_ip6_manager_cancel_addrconf(). Plus if
addrconf fails, the DHCP options should be ignored anyway.
==23089== Thread 1:
==23089== Invalid read of size 4
==23089== at 0x4861E0: finish_addrconf (nm-ip6-manager.c:444)
==23089== by 0x39B904F7EA: g_timeout_dispatch (gmain.c:3882)
==23089== by 0x39B904EC54: g_main_context_dispatch (gmain.c:2539)
==23089== by 0x39B904EF87: g_main_context_iterate.isra.23 (gmain.c:3146)
==23089== by 0x39B904F381: g_main_loop_run (gmain.c:3340)
==23089== by 0x426188: main (main.c:614)
==23089== Address 0xcdb791c is 60 bytes inside a block of size 152 free'd
==23089== at 0x4A07786: free (vg_replace_malloc.c:446)
==23089== by 0x39B905499E: g_free (gmem.c:252)
==23089== by 0x39B90692FE: g_slice_free1 (gslice.c:1111)
==23089== by 0x39B903EC49: g_hash_table_remove_internal (ghash.c:1274)
==23089== by 0x4861DC: finish_addrconf (nm-ip6-manager.c:443)
==23089== by 0x39B904F7EA: g_timeout_dispatch (gmain.c:3882)
==23089== by 0x39B904EC54: g_main_context_dispatch (gmain.c:2539)
==23089== by 0x39B904EF87: g_main_context_iterate.isra.23 (gmain.c:3146)
==23089== by 0x39B904F381: g_main_loop_run (gmain.c:3340)
==23089== by 0x426188: main (main.c:614)
Just code cleanup: This is much less error-prone than manual nesting,
and will mesh very well with future changes to use the libgsystem
cleanup macros.
Accomodate nm-netlink-monitor.c to the change by moving around utility
functions and making them static (removing if not used). Unsubscription
of rtnl groups is not necessary and the whole process will be eventually
moved to nm-platform.
Confusingly, nm-platform-compat's rtnl_link_set_oif adds a new nexthop
with ifindex set, while rtnl_link_set_gateway sets gateway for an
existing nexthop. Keeping the behavior to avoid potential problems.
device_sync_from_netlink() and nm_netlink_request_ip6_info() are now
delayed, so that they are called only once for a series of events. This
makes the IPv6 processing and especially debug messages more sane.
NL_AUTO_PROVIDE is not a valid flag for this call and it's coincidental
with ROUTE_CACHE_CONTENT, which is certainly not what we want.
NETLINK_ROUTE is a netlink family, not an address family. It is
coincidental with AF_UNSPEC which is what we actually want.
Stop logging the whole list of addresses as we already have new and lost
addresses logged. Stop putting 'state' and 'ra_flags' in almost every
message since changes of those are already logged. Log target state
change.
The config file can specify a dhclient script, which gets used instead
of what NM passes on the command-line. Make sure that script gets
ignored in the final dhclient config, because the script NM passes
is the script that needs to be used to pass data back to NM. People
may have old dhclient.conf files lying around that get picked up and
we don't want any script specified there to interfere.
GValueArray is deprecated. Unfortunately, it's part of our API right now,
so we have to keep it around for a while. But since it's deprecated, and
we want to know about *other* deprecations, we have to suppress deprecations
about GValueArray. Unfortunately using macros to do that (eg in
nm-gvaluearray-compat.h) exposes some compiler bugs due to the combination
of parentheses/braces and #pragma from G_GNUC_BEGIN_IGNORE_DEPRECATIONS,
resulting in warnings like:
nm-utils.c:920:9: error: expected expression before ‘#pragma’
Work around this by not trying to stuff what's now a macro (eg
g_value_array_get_nth) into what's already a macro (G_VALUE_TYPE).
There's probably a better way to do this...
Remove the HostnameThread stuff from nm-policy-hostname and just use
GResolver instead. Move the one remaining nm-policy-hostname function
into nm-policy.
Avoid warnings about GValueArray being deprecated by adding macros
that wrap G_GNUC_BEGIN_IGNORE_DEPRECATIONS /
G_GNUC_END_IGNORE_DEPRECATIONS around the GValueArray calls.
