M&G: SegFault on OpenMoko FreeRunner in GUI Internal Town Dialog

[Pini]

Hello,

I use Marco-Polo Grosse Reiseplaner 2007/2008 on France area (smp2.smp). With the very saem version of Navit (svn1885) and the very same maps, I have different results on OpenMoko FreeRunner? and my i386 Debian/PC.

The scenario: 1- with France as the default country, go to the GUI Internal town selection dialog 2- type 'A' and wait

Result on OpenMokoFreeRunner?: The first town town names displayed are OK, then garbage is displayed for the three next. Then Navit segfaults See attached screenshot: navit-mg-segfault.png

Result on my Debian Lenny box: Works as expected. See attached screenshot: navit-mg-ok.png

Please find below the full backtrace provided by gdb.

Thanks.

pini@debian-gta02:~$ gdb navit
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi"...
(gdb) run
Starting program: /usr/bin/navit 
[Thread debugging using libthread_db enabled]
[New Thread 0x400200a0 (LWP 2114)]
navit:convert_to_attrs:failed to create attribute 'icons_xs' with value '60'
vehicle_gpsd:vehicle_gpsd_try_open:Connected to gpsd fd=6 iochan=0x9ed68 watch=0x2
navit:main:Using '/home/pini/.navit/navit.xml'
gui_internal:gui_internal_cmd_menu:x=0x824e7 y=0x5881a1
gui_internal:gui_internal_search_list_set_default_country:country France
navit:search_list_search:level=0
gui_internal:gui_internal_search_changed:Town now 'A'
gui_internal:gui_internal_search_changed:process
navit:search_list_search:level=1
unknown town type 0xff '��P' '������P' 0x50e9f4,0xfff8f470
unknown town type 0xff '���N' '@U���N' 0x88bafff5,0x54ba004e
unknown town type 0xff 'JS���RF' 'ZS���RF' 0xfff95350,0x46533a
unknown town type 0x0 '' '' 0x0,0x0

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x400200a0 (LWP 2114)]
block_get_byindex (file=0x91940, idx=1643, blk=0x1869f4) at block.c:76
76	block.c: No such file or directory.
	in block.c
(gdb) bt full
#0  block_get_byindex (file=0x91940, idx=1643, blk=0x1869f4) at block.c:76
	__PRETTY_FUNCTION__ = "block_get_byindex"
#1  0x41053b2c in town_search_get_item (mr=0x1869e0) at town.c:279
	dir = <value optimized out>
	leaf = 1856776
	__PRETTY_FUNCTION__ = "town_search_get_item"
#2  0x41051810 in map_search_get_item_mg (ms=0x24312000) at map.c:449
No locals.
#3  0x0002ba04 in map_search_get_item (this_=0x1c5508) at map.c:430
	ret = <value optimized out>
#4  0x0002bfcc in mapset_search_get_item (this=0x18f630) at mapset.c:243
	ret = (struct item *) 0x0
	active_attr = {type = 1604452, u = {str = 0x1f26d0 "", data = 0x1f26d0, num = 2041552, item = 0x1f26d0, item_type = 2041552, projection = 2041552, numd = 0x1f26d0, color = 0x1f26d0, 
    coord_geo = 0x1f26d0, navit = 0x1f26d0, callback = 0x1f26d0, vehicle = 0x1f26d0, layout = 0x1f26d0, layer = 0x1f26d0, map = 0x1f26d0, mapset = 0x1f26d0, log = 0x1f26d0, route = 0x1f26d0, 
    navigation = 0x1f26d0, coord = 0x1f26d0, pcoord = 0x1f26d0, gui = 0x1f26d0, graphics = 0x1f26d0, tracking = 0x1f26d0, itemgra = 0x1f26d0, plugin = 0x1f26d0, plugins = 0x1f26d0, 
    polygon = 0x1f26d0, polyline = 0x1f26d0, circle = 0x1f26d0, text = 0x1f26d0, icon = 0x1f26d0, image = 0x1f26d0, arrows = 0x1f26d0, element = 0x1f26d0, speech = 0x1f26d0, cursor = 0x1f26d0, 
    range = {min = 9936, max = 31}, dash = 0x1f26d0, item_types = 0x1f26d0}}
#5  0x0001b2b4 in search_list_get_result (this_=0x187b38) at search.c:347
	leu = (struct search_list_level *) 0x187b40
	item = (struct item *) 0x187b64
	level = 1
	__PRETTY_FUNCTION__ = "search_list_get_result"
#6  0x40f0c60c in gui_internal_search_idle (this=0x84af8, wm_name=0x3 <Address 0x3 out of bounds>, search_list=0x0, param=0x24312020) at gui_internal.c:2057
	text = <value optimized out>
	name = <value optimized out>
	res = (struct search_list_result *) 0x0
	wc = <value optimized out>
	l = <value optimized out>
#7  0x00023e14 in callback_call (cb=0x1c54e8, pcount=0, p=0x0) at callback.c:144
	pf = {0x84af8, 0x19e160, 0x18f910, 0x3, 0x61140, 0x401247a4, 0x2, 0x401247a4}
	__PRETTY_FUNCTION__ = "callback_call"
#8  0x000219f4 in event_glib_call_idle (ev=<value optimized out>) at callback.h:109
No locals.
#9  0x4009d2c8 in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
(gdb) 

[Pini]

I've checked the md5sums of the M&G files used on the FreeRunner and on the PC. They are OK.

So we can cut off the hypothesis of corrupted map files.

[KaZeR]

unknown town type 0xff '��P' '������P' 0x50e9f4,0xfff8f470
unknown town type 0xff '���N' '@U���N' 0x88bafff5,0x54ba004e
unknown town type 0xff 'JS���RF' 'ZS���RF' 0xfff95350,0x46533a

Makes me think of broken locales on the FR.

What does 'locale' returns on the FR?

[Pini]

After long nights of debugging, I've finally found the problem. It's related to alignment inside the MG files mmaps, and the workaround is to dynamically configure the kernel to fixup alignment errors :

# on arm, enable kernel fixups on alignement errors:
echo 2 > /proc/cpu/alignment

Please advertise this with a BIG FAT WARNING for MG maps users on ARM processors.

[KaZeR]

Actually it's a kernel bug. It either has to segfault the program at an unaligned access or emulate it properly, but not letting it continue with invalid data. What distro/kernel are you using on the FR? Debian, too?

[Pini]

Yes I use Debian.

The kernel does behave correctly. Please see this page that explain ARM kernel alignment handling: <​http://lecs.cs.ucla.edu/wiki/index.php/XScale_alignment>.

0 = ignore (not segfault)

You may also want to read this thread which gives the rationals for the current debian kernel default on ARM alignement handling: <​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397616>

By the way, this problem will eventually be a showstopper for having Navit officially into Debian. The /proc/cpu/alignment thingy won't be accepted. The Debian developper sponsoring my packaging wants that code properly fixed - say by reading marco polo data byte-by-byte only.

Hence raising this bug to "critical".

[Pini]

Alignment patch for the MG plugin

[Pini]

Attached a minimal patch.

I wrote this patch with my kernel alignment handling set to 4 (signal - see ​http://lecs.cs.ucla.edu/wiki/index.php/XScale_alignment#Have_the_kernel_find_the_problem_for_you) to trap actual misaligned accesses only. I've fixed each encountered errors so far.