T O P I C R E V I E W |
raffaele |
Posted - 03/06/2018 : 21:13:17 Hi,
When a GPSbip connected over USB to LK8000 6.1r running on my Kobo (GloHD) is disconnected, then LK8000 crashes soon after.
The RUNTIME.log reads:
[000097988] . ComPort RESET ordered
[000097988] . RestartCommPorts begin @h16:39:43 (NO FIX)
[000097988] . Device A is <GPSBip> Port=/dev/ttyACM0
[000097988] . ComPort 1 Initialize </dev/ttyACM0> speed=4800 bit=8
[000098001] . ComPort 1 Init </dev/ttyACM0> end OK
[000098001] . Device B is DISABLED.
[000098001] . Device C is DISABLED.
[000098001] . Device D is DISABLED.
[000098001] . Device E is DISABLED.
[000098001] . Device F is DISABLED.
[000098010] . ComPort 1 ReadThread : started
[000098466] . First GPS DATE: 2018-6-3 h16:39:43 (NO FIX)
[000102988] ... GPS baro source back available h16:37:36 (NO FIX)
[000185166] . ComPort 1 ReadThread : terminated
[000187989] ... GPS no active baro source, and still BaroAltitudeAvailable, forced off h16:38:52 (NO FIX)
The error.log reads:
*** buffer overflow detected ***: /opt/LK8000/bin/LK8000-KOBO terminated
Aborted (core dumped)
What is the best way to approach this? This seems to be a new issue with LK8000 6.0b this does not happen.
Regards, Raffaele |
11 L A T E S T R E P L I E S (Newest First) |
brunotl |
Posted - 08/06/2018 : 19:58:39 personaly in don't use VMware, my workstation run Debian 9 natively
but for build kobo binary i use "croostool-ng" toolchain, made by Max Kellermann for XCSaor.
prebuild toolchain can be found here : http://max.kellermann.name/download/xcsoar/devel/x-tools or you can build one yourself
|
raffaele |
Posted - 08/06/2018 : 17:31:25 That is a good point. From looking through the LK8000 build system I couldn't see any special treatment of the system includes for the Kobo target (as opposed for example the Pi target).
From looking at the output with V=2 i get for example:
arm-linux-gnueabihf-g++ -Wp,-MD,Bin/KOBO/.Battery.o.d -std=gnu++0x -O2 -g -ICommon/Header/linuxcompat -ICommon/Header -ICommon/Source
-ICommon/Source/xcs -DKOBO -DUSE_MEMORY_CANVAS -D__linux__ -DHAVE_POSIX -D__STDC_FORMAT_MACROS -DUSE_POLL_EVENT -DUSE_FB
-DUSE_LINUX_INPUT -DUSE_MEMORY_CANVAS -DGREYSCALE -DDITHER -isystem /opt/kobo/arm-unknown-linux-gnueabi/include
-isystem /opt/kobo/arm-unknown-linux-gnueabi/include -isystem /opt/kobo/arm-unknown-linux-gnueabi/include/freetype2
-isystem /opt/kobo/arm-unknown-linux-gnueabi/include/libpng16 -isystem /opt/kobo/arm-unknown-linux-gnueabi/include -DUSE_FREETYPE
-isystem /opt/kobo/arm-unknown-linux-gnueabi/include/libpng16 -isystem /opt/kobo/arm-unknown-linux-gnueabi/include -DPOCO_NO_UNWINDOWS -DNDEBUG
-Wunused-label -Wunused-variable -Wunused-value -Wuninitialized -Wredundant-decls -Wall -Wno-char-subscripts -fsigned-char -DPOCO_STATIC
-c -o Bin/KOBO/Battery.o Common/Source/Battery.cpp
There we can see the headers installed at by the cross glibc are taken into account ("-isystem /opt/kobo/arm-unknown-linux-gnueabi/include").
So this might also be something else. From looking at XCSoar I also did not find a quick hint (they are using musl libc by now). I might try it using the Debian toolchain instead of the Ubuntu one (like XCSoar does). However, I don't think it is worth it investing much time here since you guys are using the VMware stuff. |
brunotl |
Posted - 05/06/2018 : 22:08:57 ok, what about include ?
your toolchain have builtin include directory for it's own version of glibc, so maybe that can be a problem
|
raffaele |
Posted - 05/06/2018 : 11:09:04 Ok to be more concrete, I created a Docker environment to build LK8000 in: https://github.com/sandrinr/LK8000/blob/raffaele/Scripts/docker/Dockerfile-build-kobo
The compiler version is: arm-linux-gnueabihf-g++ (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
The glibc version is 2.23. It is built in the script where all other Kobo libs are build and I used the same method as XCsoar is using to build its glibc. https://github.com/sandrinr/LK8000/blob/102d4f39a0f703ab2d7fac2a6f01a7d7fe820991/Scripts/kobo-toolchain-install.sh#L25 |
brunotl |
Posted - 05/06/2018 : 10:26:08 quote: Originally posted by raffaele It is true that I did not use the VMware based build environment but one I constructed using the crossbuild tools on Ubuntu Xenial. This impact is rather unexpected.
what gcc and glibc version ?
kobo GloHD kernel are quite old, so problem can come from glibc/kernel incompatibility |
raffaele |
Posted - 05/06/2018 : 07:17:26 Thanks for testing. I now tried the 6.1r build from http://www.postfrontal.com/forum/topic.asp?TOPIC_ID=8737 and it works. I cannot reproduce the issue there.
It is true that I did not use the VMware based build environment but one I constructed using the crossbuild tools on Ubuntu Xenial. This impact is rather unexpected.
Anyway, sorry for the inconvenience. |
brunotl |
Posted - 04/06/2018 : 23:58:00 bad luke, i can't replicate anything ... - core dump file found in your LK8000 folder don't match with "ns" binary ( if you know how to use gdbfor analyse core dump you can try your self) - you use custom map file, maybe it's related to that ?
|
raffaele |
Posted - 04/06/2018 : 22:19:09 Sure: http://sandrini.ch/lk8000/LK8000-KOBO-ns-20180604.zip
You are right, this build is done by myself, on the basis of 6.1r. |
brunotl |
Posted - 04/06/2018 : 20:02:46 it's not 6.1r but 6.1s0, so, i suppose you have build this version your self ...
in your build directory you have file named "LK8000-KOBO-ns" i need it ... |
raffaele |
Posted - 04/06/2018 : 17:48:51 You may find the dump here: http://sandrini.ch/lk8000/LK8000-20180604.zip I removed the maps and track log to reduce the package size. |
brunotl |
Posted - 04/06/2018 : 10:05:46 please send to me your complete LK8000 directory for replicate |