Hi-
I am following demo app textLoc to explore GPS locationing. I realized that if I added le_gnss_Start() to start GNSS service at beginning for le_gnss_GetLocation(), then le_posCtrl_Request() in the original demo code will return failure.
What could be the reason?
Thanks!
Hui
I suspect the problem here is that the Positioning Control service (le_posCtrl) implementation uses the GNSS service API, and the GNSS service API isn’t designed to have multiple clients. So, if you use le_gnss and le_posCtrl at the same time, you have two clients (your direct usage of le_gnss and your indirect usage through le_posCtrl).
You should really avoid using le_gnss directly.
Cheers,
–Jen
Hi
We are using positioning service api in our app and using the similar api used in textloc sample code but very often we are getting below exception. Please let me know the reason whats wrong here
Legato version 16.10.1
Apr 6 23:02:26 swi-mdm9x15 user.warn kernel: [40042.133308] Exception stack(0xcba23fb0 to 0xcba23ff8)
Apr 6 23:02:26 swi-mdm9x15 user.warn kernel: [40042.137336] 3fa0: 00000001 00000002 00000000 00000001
Apr 6 23:02:26 swi-mdm9x15 user.warn kernel: [40042.159464] 3fc0: b5661e28 0003b3f8 b5661deb b4d00468 00002014 b5662694 00000000 b5661f9c
Apr 6 23:02:26 swi-mdm9x15 user.warn kernel: [40042.175273] 3fe0: b56624e4 b5661de0 b6eecfec b6eed040 20000010 ffffffff
Apr 6 23:02:26 swi-mdm9x15 user.info kernel: [40042.180889] Task in /positioningService killed as a result of limit of /positioningService
Apr 6 23:02:26 swi-mdm9x15 user.info kernel: [40042.199079] memory: usage 39944kB, limit 40000kB, failcnt 1252843
Apr 6 23:02:26 swi-mdm9x15 user.info kernel: [40042.215896] memory+swap: usage 0kB, limit 18014398509481983kB, failcnt 0
Apr 6 23:02:26 swi-mdm9x15 user.info kernel: [40042.221573] kmem: usage 0kB, limit 18014398509481983kB, failcnt 0
Apr 6 23:02:26 swi-mdm9x15 user.info kernel: [40042.241503] Memory cgroup stats for /positioningService: cache:36KB rss:39908KB rss_huge:0KB mapped_file:0KB writeback:0KB inactive_anon:0KB active_anon:39908KB inactive_file:4KB active_file:32KB unevictable:0KB
Apr 6 23:02:26 swi-mdm9x15 user.info kernel: [40042.270436] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
Apr 6 23:02:26 swi-mdm9x15 user.info kernel: [40042.294028] [ 546] 0 546 19690 10255 31 0 0 posDaemon
Apr 6 23:02:26 swi-mdm9x15 user.err kernel: [40042.301353] Memory cgroup out of memory: Kill process 546 (posDaemon) score 998 or sacrifice child
Apr 6 23:02:26 swi-mdm9x15 user.err kernel: [40042.328791] Killed process 546 (posDaemon) total-vm:78760kB, anon-rss:39908kB, file-rss:1112kB
Apr 6 23:02:27 swi-mdm9x15 user.info Legato: INFO | supervisor[481]/supervisor T=main | proc.c proc_SigChildHandler() 1956 | Process ‘posDaemon’ (PID: 546) has exited due to signal 9 (Killed).
Thanks
It looks like the kernel is killing the posDaemon process in the positioningService app because it’s using more RAM than it’s allowed to. You can increase the amount of RAM it’s allowed to use via the maxMemoryBytes setting in the positioningService.adef file or you can override the .adef’s maxMemoryBytes limit in the .sdef file.
But, if the problem is caused by a memory leak, the best thing to do, of course, is find the leak and fix it. The ‘inspect pools’ command (on the target device’s command line) can help with this. Try running it on the posDaemon process after it has been running for a while and again later (before it runs out of memory and gets killed). ‘pstree -p’ or ‘app info positioningService’ can be useful for finding out the PID of the posDaemon process. When you have the PID, run ‘inspect pools PID’ to see the state of the memory pools inside the posDaemon process. If you see a number in the USED_BYTES column that’s continually growing, that’s the pool whose memory is being leaked.
Hi,
I’m not sure if it is the same problem, but there is a memory leak when using the nmea flow
just starting
gnss start
cat /dev/nmea
I can see the constantly increased memory usage for posDaemon process ( MEMORY POOL: le_pa_gnss.PositionEventDataPoo… )
inspect pools $(pidof posDaemon)
TOTAL BLKS | USED BLKS | MAX USED | OVERFLOWS | ALLOCS | BLK BYTES | USED BYTES | MEMORY POOL | SUB-POOL |
8 | 0 | 0 | 0 | 0 | 164 | 0 | framework.SubPools | |
10 | 5 | 5 | 0 | 5 | 148 | 740 | framework.TraceKeys | |
10 | 6 | 6 | 0 | 6 | 92 | 552 | framework.LogSession | |
0 | 0 | 0 | 0 | 0 | 88 | 0 | framework.SigMonitor | |
0 | 0 | 0 | 0 | 0 | 92 | 0 | framework.SigHandler | |
15 | 15 | 15 | 5 | 15 | 116 | 1740 | framework.SafeRef-Map | |
0 | 0 | 0 | 0 | 0 | 712 | 0 | framework.PathIteratorPool | |
8 | 0 | 0 | 0 | 0 | 96 | 0 | framework.hashMap_refPathIterat | |
4 | 0 | 0 | 0 | 0 | 180 | 0 | framework.mutex | |
23 | 22 | 23 | 19 | 23 | 160 | 3520 | framework.semaphore | |
4 | 1 | 1 | 0 | 1 | 244 | 244 | framework.Thread Pool | |
4 | 1 | 1 | 0 | 1 | 96 | 96 | framework.hashMap_refThreadRef | |
1 | 1 | 1 | 1 | 1 | 96 | 96 | framework.DestructorObjs | |
10 | 0 | 7 | 0 | 14 | 96 | 0 | framework.QueuedFunction | |
10 | 1 | 1 | 0 | 1 | 148 | 148 | framework.EventHandler | |
5 | 3 | 3 | 0 | 3 | 148 | 444 | framework.Events | |
4 | 3 | 3 | 0 | 3 | 96 | 288 | framework.hashMap_refEvents | |
8 | 1 | 1 | 0 | 1 | 96 | 96 | framework.hashMap_refEventHandl | |
10 | 5 | 8 | 0 | 8 | 144 | 720 | framework.FdMonitor | |
8 | 5 | 8 | 0 | 8 | 96 | 480 | framework.hashMap_refFdMonitors | |
1 | 0 | 0 | 0 | 0 | 156 | 0 | framework.Default Timer Pool | |
16 | 0 | 0 | 0 | 0 | 96 | 0 | framework.hashMap_refDefault Ti | |
5 | 5 | 5 | 0 | 5 | 216 | 1080 | framework.Protocol | |
32 | 3 | 3 | 0 | 3 | 252 | 756 | framework.MessagingServices | |
32 | 2 | 2 | 0 | 2 | 216 | 432 | framework.MessagingClientInterf | |
192 | 4 | 4 | 0 | 4 | 100 | 400 | framework.HandlerEventPool | |
256 | 4 | 4 | 0 | 4 | 96 | 384 | framework.hashMap_refHandlersRe | |
32 | 3 | 3 | 0 | 3 | 96 | 288 | framework.hashMap_MessagingServ | |
32 | 2 | 2 | 0 | 2 | 96 | 192 | framework.hashMap_MessagingClie | |
10 | 2 | 5 | 0 | 5 | 144 | 288 | framework.Session | |
32 | 0 | 1 | 0 | 10 | 96 | 0 | framework.hashMap_refMsgTxnIDs | |
0 | 0 | 0 | 0 | 0 | 84 | 0 | framework.KillProcs | |
32 | 0 | 0 | 0 | 0 | 96 | 0 | framework.hashMap_KillProcs | |
0 | 0 | 0 | 0 | 0 | 1112 | 0 | framework.PropertiesIterPool | |
0 | 0 | 0 | 0 | 0 | 1148 | 0 | framework.JSON Parser | |
0 | 0 | 0 | 0 | 0 | 88 | 0 | framework.JSON Context | |
1 | 0 | 0 | 0 | 0 | 88 | 0 | framework.PipelineSIGCHLD-repor | |
0 | 0 | 0 | 0 | 0 | 116 | 0 | framework.Pipeline | |
0 | 0 | 0 | 0 | 0 | 92 | 0 | framework.PipelineProcess | |
0 | 0 | 0 | 0 | 0 | 4192 | 0 | framework.AtomicFileAccessPool | |
0 | 0 | 0 | 0 | 0 | 92 | 0 | .le_gnss_ServerData | |
4 | 0 | 0 | 0 | 0 | 96 | 0 | framework.hashMap_refle_gnss_Se | |
10 | 0 | 2 | 0 | 3 | 1208 | 0 | framework.msgs-ff84ab34602f8817 | |
0 | 0 | 0 | 0 | 0 | 92 | 0 | .le_pos_ServerData | |
4 | 0 | 0 | 0 | 0 | 96 | 0 | framework.hashMap_refle_pos_Ser | |
10 | 0 | 1 | 0 | 1 | 1208 | 0 | framework.msgs-f3b96d79b8c5cb34 | |
0 | 0 | 0 | 0 | 0 | 92 | 0 | .le_posCtrl_ServerData | |
4 | 0 | 0 | 0 | 0 | 96 | 0 | framework.hashMap_refle_posCtrl | |
10 | 0 | 1 | 0 | 1 | 1208 | 0 | framework.msgs-6cde5670dcdeaaf8 | |
1 | 1 | 1 | 1 | 1 | 92 | 92 | .le_cfg_ClientData | |
1 | 1 | 1 | 1 | 1 | 84 | 84 | .le_cfg_ClientThreadData | |
4 | 1 | 1 | 0 | 1 | 96 | 96 | framework.hashMap_refle_cfg_Cli | |
10 | 0 | 2 | 0 | 8 | 1708 | 0 | framework.msgs-8a26e6c5c2c76df0 | |
10 | 0 | 2 | 0 | 12 | 404 | 0 | framework.msgs-LogControlProtoc | |
1 | 0 | 0 | 0 | 0 | 212 | 0 | posDaemon.PosSamplePoolRef | |
0 | 0 | 0 | 0 | 0 | 116 | 0 | posDaemon.PosSampleHandlerPoolR | |
4 | 0 | 0 | 0 | 0 | 96 | 0 | framework.hashMap_refPosSampleM | |
16 | 0 | 0 | 0 | 0 | 96 | 0 | framework.hashMap_refPositionin | |
13 | 0 | 0 | 0 | 0 | 92 | 0 | posDaemon.PosCtrlHandlerPoolRef | |
1 | 0 | 1 | 0 | 2458 | 92 | 0 | framework.PositionEvent-reports | |
2458 | 2458 | 2458 | 2458 | 2458 | 2180 | 5358440 | le_pa_gnss.PositionEventDataPoo | |
1 | 0 | 0 | 0 | 0 | 92 | 0 | framework.NmeaEvent-reports | |
0 | 0 | 0 | 0 | 0 | 280 | 0 | le_pa_gnss.NmeaEventDataPool | |
0 | 0 | 0 | 0 | 0 | 92 | 0 | posDaemon.PositionHandlerPoolRe | |
1 | 0 | 0 | 0 | 0 | 2180 | 0 | posDaemon.PositionSamplePoolRef | |
4 | 0 | 0 | 0 | 0 | 96 | 0 | framework.hashMap_refPositionSa | |
tried to use use Legato 16.10.1 and 16.10.3 – same issue
module: WP7502, firmware: SWI9X15Y_07.11.22.00 r33729
That is a known issue that is going to be fixed in 17.05.
The commit is b663b4b
what is the difference between GNSS and Position , if bothe gives same response why we have Two type.
how to provide different constellation type in GNSS .
Any example avaible to provide different constellation type.
GNSS should provide more information than Position .
You can see here:
https://docs.legato.io/latest/c_gnss.html
thanks for reply, any Simple example source available for GNSS with Constellation type
how about this ?
https://docs.legato.io/latest/c_gnssSampleCodeConstellation.html