Public bug reported:

These leaks has been reported by valgrind (bq aquaris 4.5, 2 SIMs
inserted) after ofono exits:

==8700== 2 bytes in 2 blocks are definitely lost in loss record 3 of 172
==8700==    at 0x483E358: malloc (vg_replace_malloc.c:296)
==8700==    by 0x48D4CC1: g_malloc (gmem.c:97)
==8700==    by 0x48E5CF1: g_memdup (gstrfuncs.c:384)
==8700==    by 0xA2129: sim_efest_read_cb (sim.c:1699)
==8700==    by 0xB7DCB: sim_fs_op_read_block_cb (simfs.c:407)
==8700==    by 0x2EC7F: ril_file_io_cb (sim.c:283)
==8700==    by 0x20F03: handle_response (gril.c:386)
==8700==    by 0x20F03: dispatch (gril.c:547)
==8700==    by 0x20F03: new_bytes (gril.c:641)
==8700==    by 0x21A37: received_data (grilio.c:125)
==8700==    by 0x48D0E8F: g_main_dispatch (gmain.c:3122)
==8700==    by 0x48D0E8F: g_main_context_dispatch (gmain.c:3737)
==8700==    by 0x48D1113: g_main_context_iterate.isra.29 (gmain.c:3808)
==8700==    by 0x48D13AF: g_main_loop_run (gmain.c:4002)
==8700==    by 0x1D865: main (main.c:247)
==8700== 
==8700== 24 bytes in 2 blocks are definitely lost in loss record 89 of 172
==8700==    at 0x4840A6C: calloc (vg_replace_malloc.c:623)
==8700==    by 0x48D4D05: g_malloc0 (gmem.c:127)
==8700==    by 0xAB2C1: __ofono_watchlist_new (watch.c:33)
==8700==    by 0xA0FA1: sim_initialize_after_pin (sim.c:1858)
==8700==    by 0xA1103: sim_pin_query_cb (sim.c:2859)
==8700==    by 0x2F4D5: ril_query_passwd_state (sim.c:967)
==8700==    by 0x2F68D: sim_status_cb (sim.c:804)
==8700==    by 0x20F03: handle_response (gril.c:386)
==8700==    by 0x20F03: dispatch (gril.c:547)
==8700==    by 0x20F03: new_bytes (gril.c:641)
==8700==    by 0x21A37: received_data (grilio.c:125)
==8700==    by 0x48D0E8F: g_main_dispatch (gmain.c:3122)
==8700==    by 0x48D0E8F: g_main_context_dispatch (gmain.c:3737)
==8700==    by 0x48D1113: g_main_context_iterate.isra.29 (gmain.c:3808)
==8700==    by 0x48D13AF: g_main_loop_run (gmain.c:4002)
==8700== 
==8700== 24 bytes in 2 blocks are definitely lost in loss record 90 of 172
==8700==    at 0x483E358: malloc (vg_replace_malloc.c:296)
==8700==    by 0x48D4CC1: g_malloc (gmem.c:97)
==8700==    by 0x48E5CF1: g_memdup (gstrfuncs.c:384)
==8700==    by 0xA0E43: sim_efust_read_cb (sim.c:1744)
==8700==    by 0xB7DCB: sim_fs_op_read_block_cb (simfs.c:407)
==8700==    by 0x2EC7F: ril_file_io_cb (sim.c:283)
==8700==    by 0x20F03: handle_response (gril.c:386)
==8700==    by 0x20F03: dispatch (gril.c:547)
==8700==    by 0x20F03: new_bytes (gril.c:641)
==8700==    by 0x21A37: received_data (grilio.c:125)
==8700==    by 0x48D0E8F: g_main_dispatch (gmain.c:3122)
==8700==    by 0x48D0E8F: g_main_context_dispatch (gmain.c:3737)
==8700==    by 0x48D1113: g_main_context_iterate.isra.29 (gmain.c:3808)
==8700==    by 0x48D13AF: g_main_loop_run (gmain.c:4002)
==8700==    by 0x1D865: main (main.c:247)
==8700== 
==8700== 32 bytes in 2 blocks are definitely lost in loss record 101 of 172
==8700==    at 0x483E358: malloc (vg_replace_malloc.c:296)
==8700==    by 0x48D4CC1: g_malloc (gmem.c:97)
==8700==    by 0x48E5CD1: g_strdup (gstrfuncs.c:356)
==8700==    by 0xA120F: sim_imsi_obtained (sim.c:1442)
==8700==    by 0x2E971: ril_imsi_cb (sim.c:559)
==8700==    by 0x20F03: handle_response (gril.c:386)
==8700==    by 0x20F03: dispatch (gril.c:547)
==8700==    by 0x20F03: new_bytes (gril.c:641)
==8700==    by 0x21A37: received_data (grilio.c:125)
==8700==    by 0x48D0E8F: g_main_dispatch (gmain.c:3122)
==8700==    by 0x48D0E8F: g_main_context_dispatch (gmain.c:3737)
==8700==    by 0x48D1113: g_main_context_iterate.isra.29 (gmain.c:3808)
==8700==    by 0x48D13AF: g_main_loop_run (gmain.c:4002)
==8700==    by 0x1D865: main (main.c:247)

** Affects: ofono (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Phonedations bugs, which is subscribed to ofono in Ubuntu.
https://bugs.launchpad.net/bugs/1510131

Title:
  ofono leaks memory when reading SIM files

Status in ofono package in Ubuntu:
  New

Bug description:
  These leaks has been reported by valgrind (bq aquaris 4.5, 2 SIMs
  inserted) after ofono exits:

  ==8700== 2 bytes in 2 blocks are definitely lost in loss record 3 of 172
  ==8700==    at 0x483E358: malloc (vg_replace_malloc.c:296)
  ==8700==    by 0x48D4CC1: g_malloc (gmem.c:97)
  ==8700==    by 0x48E5CF1: g_memdup (gstrfuncs.c:384)
  ==8700==    by 0xA2129: sim_efest_read_cb (sim.c:1699)
  ==8700==    by 0xB7DCB: sim_fs_op_read_block_cb (simfs.c:407)
  ==8700==    by 0x2EC7F: ril_file_io_cb (sim.c:283)
  ==8700==    by 0x20F03: handle_response (gril.c:386)
  ==8700==    by 0x20F03: dispatch (gril.c:547)
  ==8700==    by 0x20F03: new_bytes (gril.c:641)
  ==8700==    by 0x21A37: received_data (grilio.c:125)
  ==8700==    by 0x48D0E8F: g_main_dispatch (gmain.c:3122)
  ==8700==    by 0x48D0E8F: g_main_context_dispatch (gmain.c:3737)
  ==8700==    by 0x48D1113: g_main_context_iterate.isra.29 (gmain.c:3808)
  ==8700==    by 0x48D13AF: g_main_loop_run (gmain.c:4002)
  ==8700==    by 0x1D865: main (main.c:247)
  ==8700== 
  ==8700== 24 bytes in 2 blocks are definitely lost in loss record 89 of 172
  ==8700==    at 0x4840A6C: calloc (vg_replace_malloc.c:623)
  ==8700==    by 0x48D4D05: g_malloc0 (gmem.c:127)
  ==8700==    by 0xAB2C1: __ofono_watchlist_new (watch.c:33)
  ==8700==    by 0xA0FA1: sim_initialize_after_pin (sim.c:1858)
  ==8700==    by 0xA1103: sim_pin_query_cb (sim.c:2859)
  ==8700==    by 0x2F4D5: ril_query_passwd_state (sim.c:967)
  ==8700==    by 0x2F68D: sim_status_cb (sim.c:804)
  ==8700==    by 0x20F03: handle_response (gril.c:386)
  ==8700==    by 0x20F03: dispatch (gril.c:547)
  ==8700==    by 0x20F03: new_bytes (gril.c:641)
  ==8700==    by 0x21A37: received_data (grilio.c:125)
  ==8700==    by 0x48D0E8F: g_main_dispatch (gmain.c:3122)
  ==8700==    by 0x48D0E8F: g_main_context_dispatch (gmain.c:3737)
  ==8700==    by 0x48D1113: g_main_context_iterate.isra.29 (gmain.c:3808)
  ==8700==    by 0x48D13AF: g_main_loop_run (gmain.c:4002)
  ==8700== 
  ==8700== 24 bytes in 2 blocks are definitely lost in loss record 90 of 172
  ==8700==    at 0x483E358: malloc (vg_replace_malloc.c:296)
  ==8700==    by 0x48D4CC1: g_malloc (gmem.c:97)
  ==8700==    by 0x48E5CF1: g_memdup (gstrfuncs.c:384)
  ==8700==    by 0xA0E43: sim_efust_read_cb (sim.c:1744)
  ==8700==    by 0xB7DCB: sim_fs_op_read_block_cb (simfs.c:407)
  ==8700==    by 0x2EC7F: ril_file_io_cb (sim.c:283)
  ==8700==    by 0x20F03: handle_response (gril.c:386)
  ==8700==    by 0x20F03: dispatch (gril.c:547)
  ==8700==    by 0x20F03: new_bytes (gril.c:641)
  ==8700==    by 0x21A37: received_data (grilio.c:125)
  ==8700==    by 0x48D0E8F: g_main_dispatch (gmain.c:3122)
  ==8700==    by 0x48D0E8F: g_main_context_dispatch (gmain.c:3737)
  ==8700==    by 0x48D1113: g_main_context_iterate.isra.29 (gmain.c:3808)
  ==8700==    by 0x48D13AF: g_main_loop_run (gmain.c:4002)
  ==8700==    by 0x1D865: main (main.c:247)
  ==8700== 
  ==8700== 32 bytes in 2 blocks are definitely lost in loss record 101 of 172
  ==8700==    at 0x483E358: malloc (vg_replace_malloc.c:296)
  ==8700==    by 0x48D4CC1: g_malloc (gmem.c:97)
  ==8700==    by 0x48E5CD1: g_strdup (gstrfuncs.c:356)
  ==8700==    by 0xA120F: sim_imsi_obtained (sim.c:1442)
  ==8700==    by 0x2E971: ril_imsi_cb (sim.c:559)
  ==8700==    by 0x20F03: handle_response (gril.c:386)
  ==8700==    by 0x20F03: dispatch (gril.c:547)
  ==8700==    by 0x20F03: new_bytes (gril.c:641)
  ==8700==    by 0x21A37: received_data (grilio.c:125)
  ==8700==    by 0x48D0E8F: g_main_dispatch (gmain.c:3122)
  ==8700==    by 0x48D0E8F: g_main_context_dispatch (gmain.c:3737)
  ==8700==    by 0x48D1113: g_main_context_iterate.isra.29 (gmain.c:3808)
  ==8700==    by 0x48D13AF: g_main_loop_run (gmain.c:4002)
  ==8700==    by 0x1D865: main (main.c:247)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1510131/+subscriptions

-- 
Mailing list: https://launchpad.net/~ubuntu-phonedations-bugs
Post to     : ubuntu-phonedations-bugs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phonedations-bugs
More help   : https://help.launchpad.net/ListHelp

Reply via email to