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@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?

Hey.

A little heads-up on this - I've converted libosmocore test to use --wrap linker feature (see http://patchwork.ozlabs.org/patch/491690/ for patch) but attempts to do the same with gbproxy test of OpenBSC fails exactly the same way as before:

Assert failed expect_msg() gbproxy_test.c:1922 backtrace() returned 5 addresses ./gbproxy_test() [0x40aa12] ./gbproxy_test() [0x40291a] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7efd2814da40] ./gbproxy_test() [0x408009]

The test is compiled as follows: gcc -Wall -ggdb3 -I/usr/include/ -I/usr/include/ -I/usr/include/ -g -O2 -Wl,-static,--wrap=gprs_ns_sendmsg,--wrap=sendto,-Bdynamic -o gbproxy_test gbproxy_test.o ../../src/gprs/gb_proxy.o ../../src/gprs/gb_proxy_patch.o ../../src/gprs/gb_proxy_peer.o ../../src/gprs/gb_proxy_tlli.o ../../src/gprs/gprs_gb_parse.o ../../src/gprs/gprs_llc_parse.o ../../src/gprs/crc24.o ../../src/gprs/gprs_utils.o ../../src/libcommon/libcommon.a ../../src/libbsc/libbsc.a ../../src/libtrau/libtrau.a -losmocore -losmogb -losmovty -losmogsm -losmovty -losmoabis -ldl -lrt

Does it mean that the wrappers are not applied properly? Or it's because of mysterious "msgb_bssgph" patch mentioned in the comments next to assert?