Opened 5 years ago

Closed 5 years ago

#1158 closed defect/bug (fixed)

Routing crash on WinCE

Reported by: hyperentang.wordpress.com Owned by: KaZeR
Priority: critical Milestone: version 0.5.1
Component: port/wince Version: git master
Severity: normal Keywords: routing, crash, wince,
Cc: law_ence.dev@…

Description

Op system: Win CE core 5.0. MSTAR ARM9 MSB2501 400MHz 64MB SDRAM

Above is a simple satnav with no debugging tools, so I can't provide much useful information :-(.

I have been running navit on this unit for several years, normally updating to the latest svn every 2 or 3 months.

Around June or maybe earlier, navit started to crash when calculating a route longer than maybe 100km (it depended on the map density in the region, of course).

However, the current svn-5561 now crashes almost all of the time, even on very short routes. At least 5561 reliably triggers the exception trap:

Exception: 0xC00000005 Address: 000343E4

Earlier versions would frequently just silently reboot. Earlier versions could also be rebooted, perhaps 6 times or more, and would eventually successfully calculate a route, and then remained running most of the time.

For what it is worth, I attach the navit.log from 5561 after a crash.

Attachments (16)

navit.log (101.2 KB) - added by hyperentang.wordpress.com 5 years ago.
navit.log after a crash with unhandled exception C. svn-5561. WinCE
track_20130824-5.gpx (3.6 KB) - added by hyperentang.wordpress.com 5 years ago.
Track just before crash: Broadway
track_20130824-6.gpx (3.6 KB) - added by hyperentang.wordpress.com 5 years ago.
track_20130824-7.gpx (3.6 KB) - added by hyperentang.wordpress.com 5 years ago.
Track
track_20130824-8.gpx (2.5 KB) - added by hyperentang.wordpress.com 5 years ago.
Next track before another crash: attemting to route to Somerton. navit 5549
track_20130824-9.gpx (2.5 KB) - added by hyperentang.wordpress.com 5 years ago.
Next track between crashes: attempting route to Somerton.
track_20130824-10.gpx (3.6 KB) - added by hyperentang.wordpress.com 5 years ago.
Next section between crashes
track_20130824-11.gpx (3.6 KB) - added by hyperentang.wordpress.com 5 years ago.
Next track between crashes.
track_20130824-12.gpx (3.6 KB) - added by hyperentang.wordpress.com 5 years ago.
Next section between crashes
track_20130824-13.gpx (3.6 KB) - added by hyperentang.wordpress.com 5 years ago.
Next section between crashes
track_20130824-14.gpx (2.5 KB) - added by hyperentang.wordpress.com 5 years ago.
Next section between crashes
track_20130824-15.gpx (3.6 KB) - added by hyperentang.wordpress.com 5 years ago.
Next section between crashes
track_20130824-16.gpx (3.6 KB) - added by hyperentang.wordpress.com 5 years ago.
Next section between crashes
track_20130814-17.gpx (4.6 KB) - added by hyperentang.wordpress.com 5 years ago.
Next
track_20130824-18.gpx (3.6 KB) - added by hyperentang.wordpress.com 5 years ago.
Another part
navit.log-5385 (6.3 KB) - added by hyperentang.wordpress.com 5 years ago.

Download all attachments as: .zip

Change History (27)

Changed 5 years ago by hyperentang.wordpress.com

navit.log after a crash with unhandled exception C. svn-5561. WinCE

comment:1 Changed 5 years ago by hyperentang.wordpress.com

I have now tried several older versions back to svn-5385. They all crash in various ways on WinCE. So I suspect the underlying bug was introduced last year sometime. I don't have time to try even older versions (if available) just now.

comment:2 Changed 5 years ago by usul

  • Component changed from core to port/wince
  • Keywords routing crash wince added
  • Milestone set to version 0.5.1
  • Priority changed from major to critical
  • Summary changed from svn-5561 broken on WinCE. Unhandled exception. to Routing crash on WinCE

Hi, thanks for your report!

I'm running SVN5539 on WinCE Core 5.0 and works pretty well (even as a cyclist I don't make very large routes). Very similar device (Medion S3857 400MHz, 64MB RAM, 8GB flash).

You wrote that you are a long time user, maybe you can try to reset your configuration temporally to see if there are some bad values causing the crash? You did a clean restart of your PND?

I'm not sure how we can help to offer a debug version, as I'm currently not that involved into the development.

As a hard crash is critical, I will schedule it for the next minor release.

comment:3 Changed 5 years ago by hyperentang.wordpress.com

Sorry for delay: been away, but using navit.

PND = Personal Navigation Device? Not sure about resetting configuration: you mean navit.xml? Otherwise I restart sometimes from a cold boot which does not improve the situation.

While away, I reverted to version 0.5.0 5549. That too has serious problems! I think I choose that version because I thought that I remembered that while it crashed occasionally, it was fairly reliable. Not any more, which suggests that perhaps this is related to more detailed mapping (or new problematic tags?) on OSM.

This version 5549 crashes very reliably and very promptly when navigating in particular areas. One such that may be useful for debugging when navigatiing from Broadway (http://www.openstreetmap.org/#map=17/50.93356/-2.96845) to Somerton (http://www.openstreetmap.org/#map=19/51.05403/-2.73107). On this section of a journey, I kept restarting the satnav which recorded small portions of the track before crashing again. I append some of the track files in case they are helpful.

Changed 5 years ago by hyperentang.wordpress.com

Track just before crash: Broadway

Changed 5 years ago by hyperentang.wordpress.com

Changed 5 years ago by hyperentang.wordpress.com

Track

Changed 5 years ago by hyperentang.wordpress.com

Next track before another crash: attemting to route to Somerton. navit 5549

Changed 5 years ago by hyperentang.wordpress.com

Next track between crashes: attempting route to Somerton.

Changed 5 years ago by hyperentang.wordpress.com

Next section between crashes

Changed 5 years ago by hyperentang.wordpress.com

Next track between crashes.

Changed 5 years ago by hyperentang.wordpress.com

Next section between crashes

Changed 5 years ago by hyperentang.wordpress.com

Next section between crashes

Changed 5 years ago by hyperentang.wordpress.com

Next section between crashes

Changed 5 years ago by hyperentang.wordpress.com

Next section between crashes

Changed 5 years ago by hyperentang.wordpress.com

Next section between crashes

Changed 5 years ago by hyperentang.wordpress.com

Next

Changed 5 years ago by hyperentang.wordpress.com

Another part

comment:4 Changed 5 years ago by tryagain

Hi!

Most probably, you have run into memory related problems.

OSM data itself has grown significantly these years, we also recognizing now more tags than before. But there are still some options to consider.

Routing is the most memory hungry navit task. So in dense cities, or while computing long routes which pass thru or near such cities, low-end devices might run out of memory.

As a first step, I would suggest setting chache_size attribute of <config tag inside navit.xml to something like 512000, 256000, or even less value. That will make navit to use given memory amount in bytes to cache decompressed map tiles. The default is to use 1 MByte.

It was also reported that big navit.log file sizes on wince were leading to crashes. To disable logging into that file completely, one could remove that file and create a directory named navit.log.

Another probable huge memory consumer is graphics image cache. To verify if it actually has sense to tune that aspect, simply rename your xpm directory to something that navit doesn't know. Then start navit and look if crash still can be reproduced. If that helps, you could use some less resource hungry layout (first idea is to switch off POI icons and/or OSDs).

And, if you happen to use more than one map file at a time, please leave only one of them active. Navit does not attempt to deal with duplicate roads so it will consider each them as separate one. Each node of such road will be treated as a junction, with corresponding performance and memory usage impact, especially notable in routing.

tryagain

comment:5 Changed 5 years ago by hyperentang.wordpress.com

Indeed, I have always suspected memory overflow. But still a bug not to trap/detect that? Maybe Wince doesn't have a proper malloc or similar?

I couldn't find a cache_size (or chache_size) in navit.xml or on the wiki documentation for navit.xml. Not yet had time to try the other options.

I would like to find a more capable satnav, preferably running linux (I know about TomTom? but I don't want to pay for their software and maps that I won't use). Even discovering the specifications is difficult...

comment:6 follow-up: Changed 5 years ago by tryagain

Hi!

Well, let us keep this ticket for making Navit run on your hardware without a crash.

For graceful out of memory event handling, we have another ticket, #1067.

Regarding cache_size (yes, I have misspelled it), just add it to other existing <config> tag attributes.

Commercial devices are usually have no info about their internals. Android cellphone or tablet (depending what screen size do you want) could be a usable platform to run Navit.

tryagain

comment:7 in reply to: ↑ 6 Changed 5 years ago by hyperentang.wordpress.com

Replying to https://wiki.navit-project.org/index.php/user:tryagain:

Regarding cache_size (yes, I have misspelled it), just add it to other existing <config> tag attributes.

Sorry for delay again. I tried cache_size and indeed the couple of tests that I made on version 5549 were successful. So that indeed seems to confirm a memory problem.

Commercial devices are usually have no info about their internals. Android cellphone or tablet (depending what screen size do you want) could be a usable platform to run Navit.

I decided on the Pengpod (running linux). But they are about to release new models, so we will see. I feel far happier on a familiar open source platform. May need an external gps logger, but that will almost certainly give better gps tracking than any tablet with an internal antenna.

Thanks for help. May report back when I have done more extensive testing. The basic problem seems to be covered by #1067...

comment:8 follow-up: Changed 5 years ago by hyperentang.wordpress.com

Problems with version 5385: I just tried setting cache_size and found errors messages in navit.log like: navit:convert_to_attrs:failed to create attribute 'cache_size' with value '512000'

I tried two sizes. navit.log attached.

Changed 5 years ago by hyperentang.wordpress.com

comment:9 in reply to: ↑ 8 Changed 5 years ago by sleske

Replying to http://hyperentang.wordpress.com/:

Problems with version 5385: I just tried setting cache_size and found errors messages in navit.log like: navit:convert_to_attrs:failed to create attribute 'cache_size' with value '512000'

Good catch. The message means that navit did not accept the attribute 'cache_size'.

Your navit version was probably built using autotools (instead of CMake). The autotools build only enabled attribute 'cache_size' if a flag was passed to configure (the CMake build always enables it). If just fixed this (rev. 5630), so the next nightly build should accept 'cache_size'.

comment:10 Changed 5 years ago by hyperentang.wordpress.com

Just tested on svn-5637 with cache_size=256000. No crashes, even when calculating ~200 km route. Excellent.

The onscreen zoom in and zoom out icons seem to have shrunk so they are barely visible. I haven't looked into that yet. I thought that they were specified in pixels in navit.xml: I will have to check.

comment:11 Changed 5 years ago by tryagain

  • Resolution set to fixed
  • Severity set to normal
  • Status changed from new to closed

Closing it, as the ticket subject is solved.

JFYI, wince image sizes were addressed in r5709 and work continues at #1166 ticket.

Note: See TracTickets for help on using tickets.