I do not think there is something that will do this out of the box.
Zephyr has the Stack Sentinel and Stack Canary features in addition to other stack protection features that can be enabled to detect stack corruption issues, but it will be hard to correlate this to the stack usage of the GPS itself.
One approach could be to enable the stack canary and then start to increase the GPS thread size from low to high until your test is complete and no stack overflow trigger has happened.
Zephyr also do static analysis of the theoretical stack use of non-reentrant functions, but that's a theoretical standpoint that cannot align for dynamic allocation of memory, or asynchronous operations (interrupts)
To do this you build the project with -t ram_report , e.g "west build -b nrf9160_pca10090ns -t ram_report"
It sems that increasing the GPS stack size when having long fix try times (~5 mins), the number of reboots is decreasing. Is this just a random coincidence, or is this related?
I apologize for the late reply. When comments are marked as verified answer we do not get notifications on comments as the question is considered resolved.
Well, if the reboots are caused by the GPS thread stack overflowing then I its not a random coincident.
Did you enable the stack canary or sentinel? If you enable the Stack Sentinel then you should get a K_ERR_STACK_CHK_FAIL if a buffer overflow has occured.
