Hi,
Can someone here help me debug the failing build of libosmocore in Ubuntu?
See: https://launchpadlibrarian.net/235791225/buildlog_ubuntu-xenial-amd64.libosm...
The test case "gprs-bssgp" fails with following output:
stderr: MESSAGE to 0x7f0000ff, msg length 12 02 00 81 01 01 82 0b 56 04 82 0b 55 All NS-VCs for NSEI 2901 are either dead or blocked! All NS-VCs for NSEI 2901 are either dead or blocked! BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989 Unable to resolve NSEI 4660 to NS-VC! Assert failed rc >= 0 gb/gprs_bssgp_test.c:234
I think it is related to the hardening option "-D_FORTIFY_SOURCE=2". What is interesting is that it builds correctly in Debian, but not Ubuntu.
The issue has apparently been observed before: http://comments.gmane.org/gmane.comp.mobile.osmocom.baseband.devel/4149
If this gets fixed quickly, it might go into the next Ubuntu LTS version which has import freeze Feb 18th.
Cheers, Ruben
I made a litle bit progress. The problem disappears if "-Wl,-Bsymbolic-functions" is removed from LDFLAGS.
Any idea why?
Ruben
On Wed, Feb 10, 2016 at 07:22:50PM +0100, Ruben Undheim wrote:
Hi,
Can someone here help me debug the failing build of libosmocore in Ubuntu?
See: https://launchpadlibrarian.net/235791225/buildlog_ubuntu-xenial-amd64.libosm...
The test case "gprs-bssgp" fails with following output:
stderr: MESSAGE to 0x7f0000ff, msg length 12 02 00 81 01 01 82 0b 56 04 82 0b 55 All NS-VCs for NSEI 2901 are either dead or blocked! All NS-VCs for NSEI 2901 are either dead or blocked! BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989 Unable to resolve NSEI 4660 to NS-VC! Assert failed rc >= 0 gb/gprs_bssgp_test.c:234
I think it is related to the hardening option "-D_FORTIFY_SOURCE=2". What is interesting is that it builds correctly in Debian, but not Ubuntu.
The issue has apparently been observed before: http://comments.gmane.org/gmane.comp.mobile.osmocom.baseband.devel/4149
If this gets fixed quickly, it might go into the next Ubuntu LTS version which has import freeze Feb 18th.
Cheers, Ruben
On 10 Feb 2016, at 20:20, Ruben Undheim ruben.undheim@gmail.com wrote:
I made a litle bit progress. The problem disappears if "-Wl,-Bsymbolic-functions" is removed from LDFLAGS.
Please see this commit[1]. The GPRS NetworkService (NS) has two backends, one to use GRE and one to send using UDP. For the UDP case we try to override a symbol to see that it is called. With the -Bsymbolic-functions approach this call doesn't go through the symbol table so we will not see the call.
[1] http://git.osmocom.org/libosmocore/commit/?id=e7c18dd59f4f91409e8d8854eee2d2...
Perfect answer! Good to hear that it's not because of any code bug.
I've removed the flag and now it has been built on Ubuntu. This also paves the way libosmo-abis, libosmo-netif, libosmo-sccp and openggsn which have been "dependency-waiting" on the servers.
I notice that libosmo-sccp does not build correctly on powerpc architectures. It fails the sccp test..
Please see here: https://buildd.debian.org/status/fetch.php?pkg=libosmo-sccp&arch=powerpc...
Maybe you have an idea? Is there maybe a struct problem again?
Best regards, Ruben
On Thu, Feb 11, 2016 at 07:48:09AM +0100, Holger Freyther wrote:
On 10 Feb 2016, at 20:20, Ruben Undheim ruben.undheim@gmail.com wrote:
I made a litle bit progress. The problem disappears if "-Wl,-Bsymbolic-functions" is removed from LDFLAGS.
Please see this commit[1]. The GPRS NetworkService (NS) has two backends, one to use GRE and one to send using UDP. For the UDP case we try to override a symbol to see that it is called. With the -Bsymbolic-functions approach this call doesn't go through the symbol table so we will not see the call.
[1] http://git.osmocom.org/libosmocore/commit/?id=e7c18dd59f4f91409e8d8854eee2d2...
On 11 Feb 2016, at 18:35, Ruben Undheim ruben.undheim@gmail.com wrote:
Please see here: https://buildd.debian.org/status/fetch.php?pkg=libosmo-sccp&arch=powerpc...
Maybe you have an idea? Is there maybe a struct problem again?
Interesting. the first/second deployment of the SCCP code has been on 32bit PowerPC code. But most likely some 16bit is going wrong. If you have access to a PowerPC system through the debian project. Could you first look at the tests/testsuite.dir/*/testsuite.log?
kind regards holger
Hi,
I don't have access to a PowerPC shell directly, but I can upload packages for a test build, and I've modified the build script to dump testsuite.log.
See here: http://debomatic-powerpc.debian.net/distribution#unstable/libosmo-sccp/0.7.0...
This is an extract from the log:
- outgoing: dstref(196612) 1 -> 3 + outgoing: dstref(67109632) 1 -> 3 income: 0 -> 3 Writing test data2 incoming data: 4 Returning data3 - outgoing data: dstref(196612) 4 - outgoing: dstref(196612) 3 -> 4 - outgoing: dstref(196612) 4 -> 5 + outgoing data: dstref(67109632) 4 + outgoing: dstref(67109632) 3 -> 4 + outgoing: dstref(67109632) 4 -> 5
Ruben
On Thu, Feb 11, 2016 at 06:38:52PM +0100, Holger Freyther wrote:
Interesting. the first/second deployment of the SCCP code has been on 32bit PowerPC code. But most likely some 16bit is going wrong. If you have access to a PowerPC system through the debian project. Could you first look at the tests/testsuite.dir/*/testsuite.log?
kind regards holger
On 11 Feb 2016, at 21:15, Ruben Undheim ruben.undheim@gmail.com wrote:
Hi!
I am off for today but..
This is an extract from the log:
- outgoing: dstref(196612) 1 -> 3
- outgoing: dstref(67109632) 1 -> 3
uint32_t sccp_src_ref_to_int(struct sccp_source_reference *ref) struct sccp_source_reference sccp_src_ref_from_int(uint32_t int_ref);
are the two candidates. You could have ntohl and htonl in them to make the format/result predictable on LE and BE machines. Or swap it on BE machines.
holger
Surely not elegant or efficient, but it makes the test pass...:
Index: libosmo-sccp/src/sccp.c =================================================================== --- libosmo-sccp.orig/src/sccp.c 2016-02-05 16:56:35.845659264 +0100 +++ libosmo-sccp/src/sccp.c 2016-02-11 21:48:58.066093403 +0100 @@ -1392,14 +1392,26 @@ uint32_t sccp_src_ref_to_int(struct sccp_source_reference *ref) { uint32_t src_ref = 0; +#if OSMO_IS_LITTLE_ENDIAN memcpy(&src_ref, ref, sizeof(*ref)); +#elif OSMO_IS_BIG_ENDIAN + memcpy((((char*)(&src_ref))+3),&(ref->octet1),1); + memcpy((((char*)(&src_ref))+2),&(ref->octet2),1); + memcpy((((char*)(&src_ref))+1),&(ref->octet3),1); +#endif return src_ref; }
struct sccp_source_reference sccp_src_ref_from_int(uint32_t int_ref) { struct sccp_source_reference ref; +#if OSMO_IS_LITTLE_ENDIAN memcpy(&ref, &int_ref, sizeof(ref)); +#elif OSMO_IS_BIG_ENDIAN + memcpy(&(ref.octet1),(((char*)(&int_ref))+3),1); + memcpy(&(ref.octet2),(((char*)(&int_ref))+2),1); + memcpy(&(ref.octet3),(((char*)(&int_ref))+1),1); +#endif return ref; }
Cheers, Ruben
On Thu, Feb 11, 2016 at 09:21:06PM +0100, Holger Freyther wrote:
On 11 Feb 2016, at 21:15, Ruben Undheim ruben.undheim@gmail.com wrote:
Hi!
I am off for today but..
This is an extract from the log:
- outgoing: dstref(196612) 1 -> 3
- outgoing: dstref(67109632) 1 -> 3
uint32_t sccp_src_ref_to_int(struct sccp_source_reference *ref) struct sccp_source_reference sccp_src_ref_from_int(uint32_t int_ref);
are the two candidates. You could have ntohl and htonl in them to make the format/result predictable on LE and BE machines. Or swap it on BE machines.
holger
-
Holger Freyther -
Ruben Undheim