Opened 14 years ago
Closed 14 years ago
#272 closed defect/bug (fixed)
M&G: SegFault on OpenMoko FreeRunner in GUI Internal Town Dialog
Reported by: | Pini | Owned by: | KaZeR |
---|---|---|---|
Priority: | critical | Milestone: | version 0.2.0 |
Component: | mapdrivers/M&G | Version: | git master |
Severity: | Keywords: | ||
Cc: | Pini |
Description
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)
Attachments (3)
Change History (11)
Changed 14 years ago by Pini
Changed 14 years ago by Pini
comment:1 Changed 14 years ago by Pini
comment:2 Changed 14 years ago by KaZeR
- Owner changed from cp15 to KaZeR
- Status changed from new to assigned
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?
comment:3 Changed 14 years ago by 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.
comment:4 Changed 14 years ago by 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?
comment:5 Changed 14 years ago by Pini
- Cc Pini added
- Priority changed from major to critical
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".
comment:6 Changed 14 years ago by KaZeR
- Milestone set to version 0.2.0
comment:7 Changed 14 years ago by 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.
comment:8 Changed 14 years ago by Horwitz
- Resolution set to fixed
- Status changed from assigned to closed
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.