2016-06-19 16:06:02 +00:00
|
|
|
/* Test Osmocom SMS queue */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* (C) 2017 by sysmocom s.f.m.c. GmbH
|
|
|
|
* All Rights Reserved
|
|
|
|
*
|
|
|
|
* Author: Neels Hofmeyr <nhofmeyr@sysmocom.de>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU Affero General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 3 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU Affero General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Affero General Public License
|
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <osmocom/core/application.h>
|
|
|
|
|
2017-09-04 13:04:35 +00:00
|
|
|
#include <osmocom/msc/debug.h>
|
|
|
|
#include <osmocom/msc/vlr.h>
|
2018-11-30 01:46:53 +00:00
|
|
|
#include <osmocom/msc/gsm_data.h>
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
#include <osmocom/msc/gsm_04_11.h>
|
2019-02-19 01:36:35 +00:00
|
|
|
#include <osmocom/msc/db.h>
|
|
|
|
#include <osmocom/msc/sms_queue.h>
|
2016-06-19 16:06:02 +00:00
|
|
|
|
|
|
|
static void *talloc_ctx = NULL;
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
extern void *tall_gsms_ctx;
|
2016-06-19 16:06:02 +00:00
|
|
|
|
|
|
|
struct gsm_sms *smsq_take_next_sms(struct gsm_network *net,
|
|
|
|
char *last_msisdn,
|
|
|
|
size_t last_msisdn_buflen);
|
|
|
|
|
|
|
|
static void _test_take_next_sms_print(int i,
|
|
|
|
struct gsm_sms *sms,
|
|
|
|
const char *last_msisdn)
|
|
|
|
{
|
|
|
|
printf("#%d: ", i);
|
|
|
|
if (sms)
|
|
|
|
printf("sending SMS to %s", sms->text);
|
|
|
|
else
|
|
|
|
printf("no SMS to send");
|
|
|
|
printf(" (last_msisdn='%s')\n", last_msisdn? last_msisdn : "NULL");
|
|
|
|
}
|
|
|
|
|
|
|
|
struct {
|
|
|
|
const char *msisdn;
|
|
|
|
int nr_of_sms;
|
|
|
|
int failed_attempts;
|
|
|
|
bool vsub_attached;
|
|
|
|
} fake_sms_db[] = {
|
|
|
|
{
|
|
|
|
.msisdn = "1111",
|
|
|
|
.nr_of_sms = 0,
|
|
|
|
.vsub_attached = true,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.msisdn = "2222",
|
|
|
|
.nr_of_sms = 2,
|
|
|
|
.failed_attempts = 2,
|
|
|
|
.vsub_attached = true,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.msisdn = "3333",
|
|
|
|
.nr_of_sms = 2,
|
|
|
|
.failed_attempts = 3,
|
|
|
|
.vsub_attached = true,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.msisdn = "4444",
|
|
|
|
.nr_of_sms = 0,
|
|
|
|
.vsub_attached = true,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.msisdn = "5555",
|
|
|
|
.nr_of_sms = 2,
|
|
|
|
.failed_attempts = 5,
|
|
|
|
.vsub_attached = false,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
|
|
|
|
/* override, requires '-Wl,--wrap=db_sms_get_next_unsent_rr_msisdn' */
|
|
|
|
struct gsm_sms *__real_db_sms_get_next_unsent_rr_msisdn(struct gsm_network *net,
|
|
|
|
const char *last_msisdn,
|
|
|
|
unsigned int max_failed);
|
|
|
|
struct gsm_sms *__wrap_db_sms_get_next_unsent_rr_msisdn(struct gsm_network *net,
|
|
|
|
const char *last_msisdn,
|
|
|
|
unsigned int max_failed)
|
|
|
|
{
|
2019-02-19 01:36:35 +00:00
|
|
|
static struct vlr_subscr arbitrary_vsub = {};
|
|
|
|
static bool arbitrary_vsub_set_up = false;
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
struct gsm_sms *sms;
|
2019-05-10 20:10:22 +00:00
|
|
|
int i, rc = 0;
|
2016-06-19 16:06:02 +00:00
|
|
|
printf(" hitting database: looking for MSISDN > '%s', failed_attempts <= %d\n",
|
|
|
|
last_msisdn, max_failed);
|
|
|
|
|
2019-02-19 01:36:35 +00:00
|
|
|
if (!arbitrary_vsub_set_up) {
|
|
|
|
osmo_use_count_make_static_entries(&arbitrary_vsub.use_count, arbitrary_vsub.use_count_buf,
|
|
|
|
ARRAY_SIZE(arbitrary_vsub.use_count_buf));
|
|
|
|
arbitrary_vsub_set_up = true;
|
|
|
|
}
|
|
|
|
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
/* Every time we call sms_free(), the internal logic of libmsc
|
|
|
|
* may call vlr_subscr_put() on our arbitrary_vsub, what would
|
|
|
|
* lead to a segfault if its use_count <= 0. To prevent this,
|
|
|
|
* let's ensure a big enough initial value. */
|
2019-05-10 20:10:22 +00:00
|
|
|
rc += osmo_use_count_get_put(&arbitrary_vsub.use_count, VSUB_USE_SMS_RECEIVER, 1000);
|
|
|
|
rc += osmo_use_count_get_put(&arbitrary_vsub.use_count, VSUB_USE_SMS_PENDING, 1000);
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
arbitrary_vsub.lu_complete = true;
|
2019-05-10 20:10:22 +00:00
|
|
|
OSMO_ASSERT(rc == 0);
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
for (i = 0; i < ARRAY_SIZE(fake_sms_db); i++) {
|
|
|
|
if (!fake_sms_db[i].nr_of_sms)
|
|
|
|
continue;
|
|
|
|
if (strcmp(fake_sms_db[i].msisdn, last_msisdn) <= 0)
|
|
|
|
continue;
|
|
|
|
if (fake_sms_db[i].failed_attempts > max_failed)
|
|
|
|
continue;
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
|
|
|
|
sms = sms_alloc();
|
|
|
|
OSMO_ASSERT(sms);
|
|
|
|
|
|
|
|
osmo_strlcpy(sms->dst.addr, fake_sms_db[i].msisdn,
|
|
|
|
sizeof(sms->dst.addr));
|
|
|
|
sms->receiver = fake_sms_db[i].vsub_attached? &arbitrary_vsub : NULL;
|
|
|
|
osmo_strlcpy(sms->text, fake_sms_db[i].msisdn, sizeof(sms->text));
|
2016-06-19 16:06:02 +00:00
|
|
|
if (fake_sms_db[i].vsub_attached)
|
2018-02-06 18:31:08 +00:00
|
|
|
fake_sms_db[i].nr_of_sms--;
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
return sms;
|
2016-06-19 16:06:02 +00:00
|
|
|
}
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void show_fake_sms_db()
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < ARRAY_SIZE(fake_sms_db); i++) {
|
|
|
|
printf(" %s%s has %u SMS pending, %u failed attempts\n",
|
|
|
|
fake_sms_db[i].msisdn,
|
|
|
|
fake_sms_db[i].vsub_attached ? "" : " (NOT attached)",
|
|
|
|
fake_sms_db[i].nr_of_sms,
|
|
|
|
fake_sms_db[i].failed_attempts);
|
|
|
|
}
|
|
|
|
printf("-->\n");
|
|
|
|
}
|
|
|
|
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
/* sms_free() is not safe against NULL */
|
|
|
|
#define sms_free_safe(sms) \
|
|
|
|
if (sms != NULL) sms_free(sms)
|
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
static void test_next_sms()
|
|
|
|
{
|
|
|
|
int i;
|
2019-05-25 12:27:17 +00:00
|
|
|
char last_msisdn[GSM23003_MSISDN_MAX_DIGITS+1] = "";
|
2016-06-19 16:06:02 +00:00
|
|
|
|
|
|
|
printf("Testing smsq_take_next_sms()\n");
|
|
|
|
|
|
|
|
printf("\n- vsub 2, 3 and 5 each have 2 SMS pending, but 5 is not attached\n");
|
|
|
|
last_msisdn[0] = '\0';
|
|
|
|
show_fake_sms_db();
|
|
|
|
for (i = 0; i < 7; i++) {
|
|
|
|
struct gsm_sms *sms = smsq_take_next_sms(NULL, last_msisdn, sizeof(last_msisdn));
|
|
|
|
_test_take_next_sms_print(i, sms, last_msisdn);
|
|
|
|
OSMO_ASSERT(i >= 4 || sms);
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
sms_free_safe(sms);
|
2016-06-19 16:06:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
printf("\n- SMS are pending at various nr failed attempts (cutoff at >= 10)\n");
|
|
|
|
last_msisdn[0] = '\0';
|
|
|
|
for (i = 0; i < ARRAY_SIZE(fake_sms_db); i++) {
|
|
|
|
fake_sms_db[i].vsub_attached = true;
|
|
|
|
fake_sms_db[i].nr_of_sms = 1 + i;
|
|
|
|
fake_sms_db[i].failed_attempts = i*5;
|
|
|
|
|
|
|
|
}
|
|
|
|
show_fake_sms_db();
|
|
|
|
for (i = 0; i < 7; i++) {
|
|
|
|
struct gsm_sms *sms = smsq_take_next_sms(NULL, last_msisdn, sizeof(last_msisdn));
|
|
|
|
_test_take_next_sms_print(i, sms, last_msisdn);
|
|
|
|
OSMO_ASSERT(i >= 2 || sms);
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
sms_free_safe(sms);
|
2016-06-19 16:06:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
printf("\n- iterate the SMS DB at most once\n");
|
|
|
|
osmo_strlcpy(last_msisdn, "2345", sizeof(last_msisdn));
|
|
|
|
for (i = 0; i < ARRAY_SIZE(fake_sms_db); i++) {
|
|
|
|
fake_sms_db[i].vsub_attached = false;
|
|
|
|
fake_sms_db[i].nr_of_sms = 1;
|
|
|
|
fake_sms_db[i].failed_attempts = 0;
|
|
|
|
}
|
|
|
|
show_fake_sms_db();
|
|
|
|
for (i = 0; i < 3; i++) {
|
|
|
|
struct gsm_sms *sms = smsq_take_next_sms(NULL, last_msisdn, sizeof(last_msisdn));
|
|
|
|
_test_take_next_sms_print(i, sms, last_msisdn);
|
|
|
|
OSMO_ASSERT(!sms);
|
|
|
|
}
|
|
|
|
|
|
|
|
printf("\n- there are no SMS in the DB\n");
|
|
|
|
last_msisdn[0] = '\0';
|
|
|
|
for (i = 0; i < ARRAY_SIZE(fake_sms_db); i++) {
|
|
|
|
fake_sms_db[i].vsub_attached = true;
|
|
|
|
fake_sms_db[i].nr_of_sms = 0;
|
|
|
|
fake_sms_db[i].failed_attempts = 0;
|
|
|
|
}
|
|
|
|
show_fake_sms_db();
|
|
|
|
for (i = 0; i < 3; i++) {
|
|
|
|
struct gsm_sms *sms = smsq_take_next_sms(NULL, last_msisdn, sizeof(last_msisdn));
|
|
|
|
_test_take_next_sms_print(i, sms, last_msisdn);
|
|
|
|
OSMO_ASSERT(!sms);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static struct log_info_cat sms_queue_test_categories[] = {
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct log_info info = {
|
|
|
|
.cat = sms_queue_test_categories,
|
|
|
|
.num_cat = ARRAY_SIZE(sms_queue_test_categories),
|
|
|
|
};
|
|
|
|
|
|
|
|
int main(int argc, char **argv)
|
|
|
|
{
|
2017-11-21 22:01:39 +00:00
|
|
|
void *msgb_ctx;
|
2018-03-30 21:04:04 +00:00
|
|
|
void *logging_ctx;
|
2017-11-21 22:01:39 +00:00
|
|
|
|
2019-03-30 08:31:47 +00:00
|
|
|
/* Track the use of talloc NULL memory contexts */
|
|
|
|
talloc_enable_null_tracking();
|
|
|
|
|
2017-11-21 22:01:39 +00:00
|
|
|
talloc_ctx = talloc_named_const(NULL, 0, "sms_queue_test");
|
2018-03-30 21:04:04 +00:00
|
|
|
msgb_ctx = msgb_talloc_ctx_init(talloc_ctx, 0);
|
|
|
|
logging_ctx = talloc_named_const(talloc_ctx, 0, "logging");
|
|
|
|
osmo_init_logging2(logging_ctx, &info);
|
2016-06-19 16:06:02 +00:00
|
|
|
|
libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:
- MSC_Tests.TC_lu_and_mo_sms,
- MSC_Tests.TC_lu_and_mt_sms.
The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.
As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.
This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.
Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...
In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().
The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.
Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().
Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-03-28 14:25:14 +00:00
|
|
|
/* Share our talloc context with libmsc's GSM 04.11 code,
|
|
|
|
* so sms_alloc() would use it instead of NULL. */
|
|
|
|
tall_gsms_ctx = talloc_ctx;
|
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
OSMO_ASSERT(osmo_stderr_target);
|
|
|
|
log_set_use_color(osmo_stderr_target, 0);
|
|
|
|
log_set_print_timestamp(osmo_stderr_target, 0);
|
2021-02-19 12:37:00 +00:00
|
|
|
log_set_print_filename2(osmo_stderr_target, LOG_FILENAME_NONE);
|
2016-06-19 16:06:02 +00:00
|
|
|
log_set_print_category(osmo_stderr_target, 1);
|
|
|
|
log_parse_category_mask(osmo_stderr_target, "DLOAP,1");
|
|
|
|
|
|
|
|
test_next_sms();
|
|
|
|
printf("Done\n");
|
|
|
|
|
2017-11-21 22:01:39 +00:00
|
|
|
if (talloc_total_blocks(msgb_ctx) != 1
|
|
|
|
|| talloc_total_size(msgb_ctx) != 0) {
|
|
|
|
talloc_report_full(msgb_ctx, stderr);
|
|
|
|
fflush(stderr);
|
|
|
|
}
|
|
|
|
|
|
|
|
OSMO_ASSERT(talloc_total_blocks(msgb_ctx) == 1);
|
|
|
|
OSMO_ASSERT(talloc_total_size(msgb_ctx) == 0);
|
|
|
|
talloc_free(msgb_ctx);
|
2018-03-30 21:04:04 +00:00
|
|
|
talloc_free(logging_ctx);
|
2017-11-21 22:01:39 +00:00
|
|
|
|
|
|
|
if (talloc_total_blocks(talloc_ctx) != 1
|
|
|
|
|| talloc_total_size(talloc_ctx) != 0)
|
|
|
|
talloc_report_full(talloc_ctx, stderr);
|
|
|
|
|
|
|
|
OSMO_ASSERT(talloc_total_blocks(talloc_ctx) == 1);
|
|
|
|
OSMO_ASSERT(talloc_total_size(talloc_ctx) == 0);
|
|
|
|
talloc_free(talloc_ctx);
|
|
|
|
|
2019-03-30 08:31:47 +00:00
|
|
|
talloc_report_full(NULL, stderr);
|
|
|
|
talloc_disable_null_tracking();
|
|
|
|
|
2016-06-19 16:06:02 +00:00
|
|
|
return 0;
|
|
|
|
}
|