Hi.
Anyone else experienced this with latest libosmocore from git?
./testsuite.at:124: $abs_top_builddir/tests/gb/gprs_bssgp_test 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:229 /home/user/source/libosmocore/tests/testsuite.dir/at-groups/19/test-source: line 25: 8497 Aborted (core dumped) $abs_top_builddir/tests/gb/gprs_ bssgp_test
Pardon for multiple copies, but this is really curious: gbprocy test also fails for me during OpenBSC build at gbproxy_test.c:1922 which also contains following misterious comment:
/* TODO: The following breaks with the current libosmocore, enable it * again (and remove the plain expect_msg), when the msgb_bssgph patch * is integrated */
What is the status of this "msgb_bssgph patch" patch? Is there patchwork link available?
I suspect it's still unmerged because swapping the lines as instructed in comment still results in crash with the latest libosmocore from git.
Commenting out both lines produce sane-looking output but the test expectedly fails due to mismatch with expected output.
I wonder if should comment out the 2nd line until the libosmocore patch is merged or perhaps consider merging the necessary patch?
22.05.2015 15:38, ☎ пишет:
Hi.
Anyone else experienced this with latest libosmocore from git?
./testsuite.at:124: $abs_top_builddir/tests/gb/gprs_bssgp_test 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:229 /home/user/source/libosmocore/tests/testsuite.dir/at-groups/19/test-source: line 25: 8497 Aborted (core dumped) $abs_top_builddir/tests/gb/gprs_ bssgp_test
Another person reproduced this on ubuntu 15.04 x86_64. Have anyone else hit it recently?
01.06.2015 15:58, ☎ пишет:
Pardon for multiple copies, but this is really curious: gbprocy test also fails for me during OpenBSC build at gbproxy_test.c:1922 which also contains following misterious comment:
/* TODO: The following breaks with the current libosmocore, enable it * again (and remove the plain expect_msg), when the msgb_bssgph patch * is integrated */
What is the status of this "msgb_bssgph patch" patch? Is there patchwork link available?
I suspect it's still unmerged because swapping the lines as instructed in comment still results in crash with the latest libosmocore from git.
Commenting out both lines produce sane-looking output but the test expectedly fails due to mismatch with expected output.
I wonder if should comment out the 2nd line until the libosmocore patch is merged or perhaps consider merging the necessary patch?
22.05.2015 15:38, ☎ пишет:
Hi.
Anyone else experienced this with latest libosmocore from git?
./testsuite.at:124: $abs_top_builddir/tests/gb/gprs_bssgp_test 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:229 /home/user/source/libosmocore/tests/testsuite.dir/at-groups/19/test-source: line 25: 8497 Aborted (core dumped) $abs_top_builddir/tests/gb/gprs_ bssgp_test
On 05 Jun 2015, at 15:07, ☎ Max.Suraev@fairwaves.co wrote:
Another person reproduced this on ubuntu 15.04 x86_64. Have anyone else hit it recently?
https://build.opensuse.org/package/live_build_log/home:zecke23:stp/libosmoco...
hits something like this too. Try to understand the difference between debian and the ubuntu toolchain. E.g. does the overload of “sendto” work with the gold linker?
05.06.2015 17:36, Holger Freyther пишет:
On 05 Jun 2015, at 15:07, ☎ Max.Suraev@fairwaves.co wrote:
Another person reproduced this on ubuntu 15.04 x86_64. Have anyone else hit it recently?
https://build.opensuse.org/package/live_build_log/home:zecke23:stp/libosmoco...
hits something like this too. Try to understand the difference between debian and the ubuntu toolchain. E.g. does the overload of “sendto” work with the gold linker?
Hmm.. so it works on Debian but not on Ubuntu? How do I check if gold is used as linker?
On 05 Jun 2015, at 18:05, ☎ Max.Suraev@fairwaves.co wrote:
Hmm.. so it works on Debian but not on Ubuntu? How do I check if gold is used as linker?
it is not only gold. My first suspicion would be to put a break point in sendto and see which is executed (the system one or the overload)
After some further digging I've found that "make check" do not see this error but "dpkg-buildpackage -tc -uc -us" does. So apparently .deb build invoke different linker or same linker with different options which in turn triggers this bug.
No idea how to track down this difference.
05.06.2015 18:19, Holger Freyther пишет:
On 05 Jun 2015, at 18:05, ☎ Max.Suraev@fairwaves.co wrote:
Hmm.. so it works on Debian but not on Ubuntu? How do I check if gold is used as linker?
it is not only gold. My first suspicion would be to put a break point in sendto and see which is executed (the system one or the overload)
On 06 Jul 2015, at 16:54, ☎ Max.Suraev@fairwaves.co wrote:
After some further digging I've found that "make check" do not see this error but "dpkg-buildpackage -tc -uc -us" does. So apparently .deb build invoke different linker or same linker with different options which in turn triggers this bug.
No idea how to track down this difference.
export DEB_BUILD_HARDENING=1
will enable extra flags. E.g. -fPIE -pie might be a candidate?
baseband-devel@lists.osmocom.org