Hi Pablo, all
I have pushed GNU autotest[1] integration of libosmocore into the
zecke/gnu-autotest branch and invoking make check will execute the testsuite.
The output looks like this:
## ------------------------------------- ##
## libosmocore 0.4.0.10-c015 test suite. ##
## ------------------------------------- ##
Regression tests.
1: bits ok
2: msgfile ok
3: sms ok
4: smscb ok
5: timer FAILED (testsuite.at:38)
6: ussd FAILED (testsuite.at:44)
GNU autotest will execute an external application and then can check the exit
code, compare the stdout/stderr to a file. In this case the timer test fails
as the test itself is randomized and does not always provide the same output.
Pablo if your time permits it would be nice if you could:
- Provide a cli option to make the test have less iterations (to make
make check run faster)
- Provide a cli option to produce a repeatable output (e.g. by
omitting the expired output).
What do you think? In some ways I think that executing the timer test as part
of our regression tests makes sense but maybe specially on a loaded machine
the test might be flaky...
holger
[1] http://www.gnu.org/s/hello/manual/autoconf/Using-Autotest.html#Using-Autote…
If the timer test takes more than 2 * (number of steps + 10), we
abort the test. This calculation is based on the maximum timeout
randomly set (10 seconds) plus the number of steps (some existing
timers may be reset in each step). We double this to have some
extra grace time to finish.
---
tests/timer/timer_test.c | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/tests/timer/timer_test.c b/tests/timer/timer_test.c
index 72c07a9..3775151 100644
--- a/tests/timer/timer_test.c
+++ b/tests/timer/timer_test.c
@@ -24,6 +24,7 @@
#include <stdio.h>
#include <stdlib.h>
+#include <signal.h>
#include <getopt.h>
#include <osmocom/core/talloc.h>
@@ -137,10 +138,22 @@ static void secondary_timer_fired(void *data)
}
}
+static void alarm_handler(int signum)
+{
+ fprintf(stderr, "ERROR: We took too long to run the timer test, "
+ "something seems broken, aborting.\n");
+ exit(EXIT_FAILURE);
+}
+
int main(int argc, char *argv[])
{
int c;
+ if (signal(SIGALRM, alarm_handler) == SIG_ERR) {
+ perror("cannot register signal handler");
+ exit(EXIT_FAILURE);
+ }
+
while ((c = getopt_long(argc, argv, "s:", NULL, NULL)) != -1) {
switch(c) {
case 's':
@@ -162,6 +175,12 @@ int main(int argc, char *argv[])
osmo_timer_schedule(&main_timer, 1, 0);
+ /* if the test takes too long, we may consider that the timer scheduler
+ * has hung. We set some maximum wait time which is the double of the
+ * maximum timeout randomly set (10 seconds, worst case) plus the
+ * number of steps (since some of them are reset each step). */
+ alarm(2 * (10 + timer_nsteps));
+
#ifdef HAVE_SYS_SELECT_H
while (1) {
osmo_select_main(0);
--
1.7.2.5
--fdj2RfSjLxBAspz7--
Hi,
While updating libosmocore in osmocom-bb, a problem arised: 100%CPU
usage and hanging. Turns out 'mobile' sometimes call
osmo_timer_schedule for an already scheduled timer.
Obviously this used to work and now it doesn't. The question is : Was
there a defined semantics for this case previously ? Or is it supposed
to be unsupported ? What would you expect it to do ?
Cheers,
Sylvain
On Sun, Nov 13, 2011 at 11:45:28AM +0100, Harald Welte wrote:
> Hi Pablo and Sylvain,
>
> On Sun, Nov 13, 2011 at 01:28:30AM +0100, Pablo Neira Ayuso wrote:
>
> > Hm, I think I found one weird scenario which is not handled fine with
> > your patch. [...]
> >
> > Yes, this scenario is strange, but I think we try to cover all possible
> > situations. So I think my patch should be applied instead.
>
> Will the two of you please figure out what is the best option to
> proceed? Revert one of Sylvains patches and apply Pablos patch?
I think so. I can make it myself if you want.
Hi,
>> Yes, this scenario is strange, but I think we try to cover all possible
>> situations. So I think my patch should be applied instead.
>
> Will the two of you please figure out what is the best option to
> proceed? Revert one of Sylvains patches and apply Pablos patch?
I applied Pablo's patch this morning after testing it worked as well.
Cheers,
Sylvain
Hi all,
i compiled and configured all (mISDN, lcr, asterisk, etc...), unfortunately, when i try to place a call from the softphone to the MS, i can ear only the voice originated from the laptop to the MS and not viceversa.
I'm using it on an Ubuntu 10.4, Asterisk 1.6.2.5 and the others sources from "last git".
Configurations:
- extension.conf: http://pastebin.com/mHH46HbQ
- sip.conf: http://pastebin.com/SkPN3z6q
- gsm.conf: http://pastebin.com/C1Eckdgh
- interface.conf: http://pastebin.com/ctGapa1F
- options.conf: http://pastebin.com/6xhgL0P1
- routing.conf: http://pastebin.com/TVNvwTEB
Logs:
- osmo-nitb's log: http://pastebin.com/X10B5NjE
- lcr's log: http://pastebin.com/uLY9VAiB
- Asterisk's log: http://pastebin.com/8qzw6aMn
As you can see from Asterisk, there is a mismatch:
"NOTICE[2315]: channel.c:2960 __ast_read: Dropping incompatible voice frame on lcr/1 of format alaw since our native format has changed to 0x0 (nothing) "
I tried to set alaw / ulaw on the configurations, to change efr, fr and amr, but it didn't change nothing.
Ideas or hints for further investigations are welcome.
Regards,
Luca
Hi Jolly, all,
I spent some time figuring out why LCR and OpenBSC wouldn't want to work with
each other. The reason was the addition of an element to the MNCC structure. I
propose to send a hello packet down the MNCC socket and leave it to the client
to decide if the version is acceptable.
I will need to move the mncc header to libosmocore as osmocomBB is currently
using a copy of the OpenBSC header.
comments
holger