-
-
libpurple/purplecontactmanager.h (Diff revision 1) 1) "will be return" -> "will be returned"
2) "will returned" -> "will be returned" -
-
libpurple/tests/test_contact_manager.c (Diff revision 1) 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) -
libpurple/tests/test_contact_manager.c (Diff revision 1) 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) -
libpurple/tests/test_contact_manager.c (Diff revision 1) contact1andcontact2seem not to be freed properly, similiar to the issue above.
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
|
Change Summary:
address issues and fix leaks
Commits: |
|
|||||||
|---|---|---|---|---|---|---|---|---|
Diff: |
Revision 2 (+1656) |