bssgp test

[☎]

That makes it even more strange: I do see the fprintf, moreover if I explicitly print
value of real_sendto in sendto wrapper from gprs_bssgp_test.c I got 0.

Here is what I got when manually starting ./gprs_bssgp_test in libosmocore/tests/gb/.libs

MESSAGE to 0x7f0000ff, msg length 12
02 00 81 01 01 82 0b 56 04 82 0b 55
===== BSSGP test START
----- test_bssgp_suspend_resume START
BSSGP primitive, SAP 16777219, prim = 3, op = 0, msg = 0b 1f 84 f0 12 34 56 1b 86 0f
f1 80 20 37 00
All NS-VCs for NSEI 2901 are either dead or blocked!
BSSGP primitive, SAP 16777219, prim = 4, op = 0, msg = 0e 1f 84 f0 12 34 56 1b 86 0f
f1 80 20 37 00 1d 81 01
All NS-VCs for NSEI 2901 are either dead or blocked!
----- test_bssgp_suspend_resume END
----- test_bssgp_status START
BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified
BSSGP primitive, SAP 16777221, prim = 11, op = 2, msg = 41 07 81 27
BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI
BSSGP primitive, SAP 16777221, prim = 11, op = 2, msg = 41 07 81 05 04 82 04 d2
----- test_bssgp_status END
NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989
----- test_bssgp_flow_control_bvc START
Unable to resolve NSEI 4660 to NS-VC!
Assert failed rc >= 0 gb/gprs_bssgp_test.c:229
backtrace() returned 4 addresses
./gprs_bssgp_test() [0x4013c9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f0786082a40]
./gprs_bssgp_test() [0x4014e9]
fish: Job 1, './gprs_bssgp_test' terminated by signal SIGABRT (Abort)


Seems like it's not the linker to be blamed.

When I try to gdb it I've got following backtrace:

(gdb) bt full
#0  0x00007ffff7407267 in __GI_raise (sig=sig at entry=6) at
../sysdeps/unix/sysv/linux/raise.c:55
        resultvar = 0
        pid = 19343
        selftid = 19343
#1  0x00007ffff7408eca in __GI_abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x7fffffffdef0, sa_sigaction =
0x7fffffffdef0}, sa_mask = {__val = {0, 4199616, 140737351974688, 6311344,
              140737347502393, 0, 0, 42, 4294967274, 6311344, 22136, 0,
140737354092544, 0, 0, 0}}, sa_flags = 825242744, sa_restorer = 0x1}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00000000004013ce in test_bssgp_suspend_resume () at gb/gprs_bssgp_test.c:135
No locals.
#3  main (argc=19343, argv=0x4b8f) at gb/gprs_bssgp_test.c:272
        bss_peer = {sin_family = 2, sin_port = 125, sin_addr = {s_addr = 4278190207},
sin_zero = "\000\000\000\000\000\000\000"}

The gb/gprs_bssgp_test.c:135 is following:

OSMO_ASSERT(last_oph.primitive == PRIM_BSSGP_GMM_RESUME);

Although I don't get yet what suspend-resume supposed to do in there and how it
corresponds to printed log above.

08.06.2015 09:06, Jacob Erlbeck пишет:
> Hi
> 
> On 05.06.2015 15:15, ☎ wrote:
>> Could you perhaps summarize what's happening around tests/gb/gprs_bssgp_test.c:229?
> 
> The line before the failing test is
> 
>   rc = bssgp_tx_fc_bvc(&bctx, tag, bmax, rate, bmax_ms, rate_ms,
> 		NULL, NULL);
> 
> The bssgp_tx_fc_bvc function will in general call gprs_ns_sendmsg ->
> gprs_ns_tx -> nsip_sendmsg -> sendto. The sendto function had been
> "replaced" by redefining it locally which worked at least with the
> default ld up to ubuntu 14.04. (see Holger's replies).
> 
> The system's sendto will fail in the test, since the UDP socket has not
> been configured. The local replacement (see gprs_bbsgp_test.c:37) will call
> 
> fprintf(stderr, "MESSAGE to 0x%08x, msg length %d\n%s\n",
> 		dest_host, len, osmo_hexdump(buf, len));
> 
> so you just need to look into the stderr output to see, whether this is
> a linker issue.
> 
> If yes, the issue will appear in more test programs, since that pattern
> has been used many times.
> 
> If there is no way to trick the linker to use the "old" behaviour, those
> test programs will have to be changed to use another mocking mechanism,
> e.g. by using the --wrap feature (if it is supported by the linker), see
> openbsc:openbsc/tests/sgsn/sgsn_test.c.
> 
> HTH
> 
> Jacob
> 
>>
>> The test fails for me (and another person with ubuntu 15.04 x86_64) on OSMO_ASSERT(rc
>>> = 0);
>>
>> This is 100% reproducible but I don't know much about Gb part so I'm not sure how to
>> track this down properly. Any ideas/advices?
>>
> 
> 


-- 
best regards,
Max, http://fairwaves.co