PostFrontal Forum
PostFrontal Forum
PF Home | International_Forum | Profile | Register | Active Topics | Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?


 All Forums
 LK8000 International Support
 Developers
 LK8000 6.1r / Kobo / GPSbip crashes on disconnect
 New Topic  Reply to Topic
Author Previous Topic Topic Next Topic  

raffaele
Pulcino

Switzerland
6 Posts

Posted - 03/06/2018 :  21:13:17  Show Profile  Reply with Quote
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
Aquila imperiale

France
541 Posts

Posted - 04/06/2018 :  10:05:46  Show Profile  Reply with Quote
please send to me your complete LK8000 directory for replicate
Go to Top of Page

raffaele
Pulcino

Switzerland
6 Posts

Posted - 04/06/2018 :  17:48:51  Show Profile  Reply with Quote
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.
Go to Top of Page

brunotl
Aquila imperiale

France
541 Posts

Posted - 04/06/2018 :  20:02:46  Show Profile  Reply with Quote
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 ...
Go to Top of Page

raffaele
Pulcino

Switzerland
6 Posts

Posted - 04/06/2018 :  22:19:09  Show Profile  Reply with Quote
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.
Go to Top of Page

brunotl
Aquila imperiale

France
541 Posts

Posted - 04/06/2018 :  23:58:00  Show Profile  Reply with Quote
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 ?

Go to Top of Page

raffaele
Pulcino

Switzerland
6 Posts

Posted - 05/06/2018 :  07:17:26  Show Profile  Reply with Quote
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.
Go to Top of Page

brunotl
Aquila imperiale

France
541 Posts

Posted - 05/06/2018 :  10:26:08  Show Profile  Reply with Quote
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
Go to Top of Page

raffaele
Pulcino

Switzerland
6 Posts

Posted - 05/06/2018 :  11:09:04  Show Profile  Reply with Quote
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
Go to Top of Page

brunotl
Aquila imperiale

France
541 Posts

Posted - 05/06/2018 :  22:08:57  Show Profile  Reply with Quote
ok, what about include ?

your toolchain have builtin include directory for it's own version of glibc, so maybe that can be a problem
Go to Top of Page

raffaele
Pulcino

Switzerland
6 Posts

Posted - 08/06/2018 :  17:31:25  Show Profile  Reply with Quote
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.
Go to Top of Page

brunotl
Aquila imperiale

France
541 Posts

Posted - 08/06/2018 :  19:58:39  Show Profile  Reply with Quote
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
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
Jump To:
PostFrontal Forum © PostFrontal - La community del Volo a Vela Go To Top Of Page
This page was generated in 0.17 seconds. Snitz Forums 2000

Suggerimenti dello staff:

               

Note legali (italiano):
Privacy Policy Cookie Policy
Legal notice (english):
Privacy Policy Cookie Policy

PostFrontal S.A.S. di Giuliano Golfieri & c. - P.I. 05264240960