This patch series fixes some build issues in libosmo-abis. The
failures occurred on a Debian jessie amd64 system, with libosmo* build
dependencies installed into distinct prefixes.
The first patch fixes the build-system wrt. out-of-tree builds, while
the second future-proofs the build system by enabling the
subdir-objects automake option (see commit message for details).
Hi,
On 30.04.2015 20:33, Jacob Erlbeck wrote:
> On 30.04.2015 20:01, Holger Freyther wrote:
> > Did ASAN help?
> No, since the data seems to be taken from then fc struct, so the memory area is
> valid. ASAN was enabled and didn't complain.
It wouldn't have helped here, but since ASAN is discussed in the context of memory errors, I'd like to check that it's been considered that ASAN's ability to detect and report memory errors may be being impaired by the use of talloc - particularly use after free bugs.
I took a very quick look at the talloc code, and it looks like the Valgrind memory poisoning macros are added, but not in a way that I can see as being active (missing #include of the Valgrind API headers + DEVELOPER needs to be defined). The 2.1.2 version of talloc looks to be perhaps more complete in this respect.
I'm not sure if ASAN can utilise the Valgrind macros though - perhaps something like Mozilla's approach to cover poisoning is needed: https://dxr.mozilla.org/mozilla-central/source/mfbt/MemoryChecking.h
Also I noticed that there is a --disable-talloc option to configure. I hoped this would fall back to libc malloc/free, but it actually disables use of the packaged talloc.c, and links with -ltalloc instead i.e. talloc isn't actually disabled:
if ENABLE_TALLOC
libosmocore_la_SOURCES += talloc.c
else
libosmocore_la_LIBADD += -ltalloc
endif
It may be better named --disable-builtin-talloc.
Kind Regards,
Mike
Hi
We
have configured OsmoNITB, OsmoBTS and OsmoTRX to run two transceivers
using UmTRX. But somehow when the spectrum is monitored, the only
frequency that is detected is the one TRX0 is tuned to. ARFCN set for
TRX1 is not detected i.e. TRX1 does not seem to be transmitting on the
specified frequency.
Can anyone please tell what possibly could be the issue?
Thanks & Regards,
Amber & Sarosh
Currently the DL sometimes hangs and sometimes a lot of messages
(still not able to send PDU) are logged. This is caused by an invalid
timer delay computation, setting msecs either to 0 or to some big value.
This is due to an '&' operator at the wrong place, accessing some
parts in fc instead of the first element of the list.
This commit fixes that issue.
Sponsored-by: On-Waves ehf
---
src/gb/gprs_bssgp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gb/gprs_bssgp.c b/src/gb/gprs_bssgp.c
index 4c93b69..fe4fcca 100644
--- a/src/gb/gprs_bssgp.c
+++ b/src/gb/gprs_bssgp.c
@@ -628,7 +628,7 @@ static int fc_queue_timer_cfg(struct bssgp_flow_control *fc)
if (llist_empty(&fc->queue))
return 0;
- fcqe = llist_entry(&fc->queue.next, struct bssgp_fc_queue_element,
+ fcqe = llist_entry(fc->queue.next, struct bssgp_fc_queue_element,
list);
if (fc->bucket_leak_rate != 0) {
--
1.9.1