Author |
Topic |
|
raffaele
Pulcino
Switzerland
6 Posts |
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 |
Edited by - AlphaLima on 08/06/2018 19:42:34 |
|
brunotl
Pterodattilo
France
1090 Posts |
Posted - 04/06/2018 : 10:05:46
|
please send to me your complete LK8000 directory for replicate |
|
|
raffaele
Pulcino
Switzerland
6 Posts |
|
brunotl
Pterodattilo
France
1090 Posts |
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
Pulcino
Switzerland
6 Posts |
|
brunotl
Pterodattilo
France
1090 Posts |
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
Pulcino
Switzerland
6 Posts |
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
Pterodattilo
France
1090 Posts |
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
Pulcino
Switzerland
6 Posts |
|
brunotl
Pterodattilo
France
1090 Posts |
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
Pulcino
Switzerland
6 Posts |
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
Pterodattilo
France
1090 Posts |
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
|
Edited by - brunotl on 08/06/2018 19:59:07 |
|
|
|
Topic |
|