-
-
-
-
This is not freed properly it seems.
==26145== 167 (88 direct, 79 indirect) bytes in 1 blocks are definitely lost in loss record 6,822 of 7,309 ==26145== at 0x48447E5: malloc (vg_replace_malloc.c:381) ==26145== by 0x4A3DE68: g_malloc (in /usr/lib64/libglib-2.0.so.0.7200.3) ==26145== by 0x4A562C0: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.7200.3) ==26145== by 0x4A56939: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.7200.3) ==26145== by 0x49BB921: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.7200.3) ==26145== by 0x49A0C4C: g_object_new_internal (in /usr/lib64/libgobject-2.0.so.0.7200.3) ==26145== by 0x49A261C: g_object_new_valist (in /usr/lib64/libgobject-2.0.so.0.7200.3) ==26145== by 0x49A2B50: g_object_new (in /usr/lib64/libgobject-2.0.so.0.7200.3) ==26145== by 0x48D34AD: purple_contact_new (purplecontact.c:327) ==26145== by 0x10AE5D: test_purple_contact_manager_remove_all (test_contact_manager.c:172) ==26145== by 0x4A60C05: g_test_run_suite_internal (in /usr/lib64/libglib-2.0.so.0.7200.3) ==26145== by 0x4A6092A: g_test_run_suite_internal (in /usr/lib64/libglib-2.0.so.0.7200.3) -
This seems to be leaking memory (both
contact1andcontact2)==26145== 163 (88 direct, 75 indirect) bytes in 1 blocks are definitely lost in loss record 6,820 of 7,309 ==26145== at 0x48447E5: malloc (vg_replace_malloc.c:381) ==26145== by 0x4A3DE68: g_malloc (in /usr/lib64/libglib-2.0.so.0.7200.3) ==26145== by 0x4A562C0: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.7200.3) ==26145== by 0x4A56939: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.7200.3) ==26145== by 0x49BB921: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.7200.3) ==26145== by 0x49A0C4C: g_object_new_internal (in /usr/lib64/libgobject-2.0.so.0.7200.3) ==26145== by 0x49A261C: g_object_new_valist (in /usr/lib64/libgobject-2.0.so.0.7200.3) ==26145== by 0x49A2B50: g_object_new (in /usr/lib64/libgobject-2.0.so.0.7200.3) ==26145== by 0x48D34AD: purple_contact_new (purplecontact.c:327) ==26145== by 0x10B115: test_purple_contact_manager_find_with_username (test_contact_manager.c:201) ==26145== by 0x4A60C05: g_test_run_suite_internal (in /usr/lib64/libglib-2.0.so.0.7200.3) ==26145== by 0x4A6092A: g_test_run_suite_internal (in /usr/lib64/libglib-2.0.so.0.7200.3) -
Create the new PurpleContactManager
Review Request #1850 — Created Sept. 28, 2022 and submitted
Create the new PurpleContactManager
Ran the unit tests
| Summary | ID |
|---|---|
| a27ad8b2ee3b4fc26ade164a10c9e5569a2d2163 |
| Description | From | Last Updated |
|---|---|---|
|
1) "will be return" -> "will be returned" 2) "will returned" -> "will be returned" |
 ivanhoe
|
|
|
"coniact" -> "contact" |
ivanhoe
|
|
|
Missing a word after the, I assume contact |
 lifesfaded
|
|
|
This is not freed properly it seems. ==26145== 167 (88 direct, 79 indirect) bytes in 1 blocks are definitely lost … |
ivanhoe
|
|
|
This seems to be leaking memory (both contact1 and contact2) ==26145== 163 (88 direct, 75 indirect) bytes in 1 blocks … |
ivanhoe
|
|
|
contact1 and contact2 seem not to be freed properly, similiar to the issue above. |
ivanhoe
|
