Thread: App for vector renderer maps, using OpenGL ES 2.0
View Single Post
Zeta is offline Zeta
2017-09-18 , 20:34
Posts: 339 | Thanked: 1,623 times | Joined on Oct 2013 @ France
#44
Originally Posted by rinigus View Post
Looking good. Would you mind to add debug info for qmapboxgl and mapbox-sfos. As far as I can see, its packages qmapboxgl-debugsource and mapbox-sfos-debuginfo .
Done.

Translating in commands, for future me (and other who could need to):
Originally Posted by rinigus View Post
Actually, you could add http://repo.merproject.org/obs/home:...mv7hl/armv7hl/ as a repo and then just use
Code:
pkcon install
. It will also allow you to upgrade in future, while we hunt for the bug.
=> (warning, the last "armv7hl" is not part of the repo name)
Code:
 devel-su ssu addrepo mer_rinigus http://repo.merproject.org/obs/home:/rinigus:/maps/sailfish_latest_armv7hl/ 
ssu updaterepos
pkcon refresh
pkcon install mapbox-sfos-debuginfo qmapboxgl-debugsource
Originally Posted by rinigus View Post
If I can get these crash backtraces, we could open an issue for mapbox-gl-native and explain what has been done to make it run on SFOS. Maybe they can help.
Here are the backtraces for 3 consecutive runs : https://pastebin.com/QiPcKsfi

Is there another gdb command output you need ? (my gdb is a bit rusty...)

Originally Posted by rinigus View Post
As for crashes occurring for J1 and Photon Q: I wonder if its some OpenGL limitation of these devices. I haven't fiddled with OpenGL settings while compiling qmapboxgl, but maybe I should (have to look it up). But then not sure why it would crash on free/malloc calls...
Seeing as the last run crashed on QSslConfiguration, we are probably chasing a memory corruption bug. The kind that can corrupt stack or heap at some place in the code, and leaving its effects to something else later (like free and malloc that are using pointers) that is what gdb captures, and not the real thing that broke the stack.
It is usually one variable stored above in the memory that got out of its bounds, but can be more subtle. This can be "quite easy" to find in a small micro-controller, but I don't know how to show it in that case, as there are a lot of allocation/deallocation happening and so it can be difficult to know what was in memory before when the problem happened. Especially as valgrind doesn't run, from your tests.
Some basics tests could be done, like adding tests around all mallocs and pointers usage, leading to a qFatal() call to stop the application with a core dump and details. However, if the problem is on the GPU side (as only the adreno 200 shows it right now), it would not help that much..
 

The Following 3 Users Say Thank You to Zeta For This Useful Post: