viking
viking copied to clipboard
buffer overflow detected after commit 8a439f317d60281cdb3f6dab57dd51b7315a90de
When I open anyone file .gpx show this error
*** buffer overflow detected ***: /usr/bin/viking terminated
Thread 1 "viking" received signal SIGABRT, Aborted.
0x00007ffff30e5b98 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff30e5b98 in raise () from /lib64/libc.so.6
#1 0x00007ffff30e768e in abort () from /lib64/libc.so.6
#2 0x00007ffff312c0b7 in ?? () from /lib64/libc.so.6
#3 0x00007ffff31c635e in ?? () from /lib64/libc.so.6
#4 0x00007ffff31c63a1 in __fortify_fail () from /lib64/libc.so.6
#5 0x00007ffff31c39e0 in __chk_fail () from /lib64/libc.so.6
#6 0x00007ffff31c419b in __realpath_chk () from /lib64/libc.so.6
#7 0x00005555555d75b4 in realpath (__resolved=0x7fffffffbf50 "", __name=0x555555de72b0 "/home/fran/Descargas/rutas/bexti.gpx") at /usr/include/bits/stdlib.h:45
#8 file_realpath (real=0x7fffffffbf50 "", path=0x555555de72b0 "/home/fran/Descargas/rutas/bexti.gpx") at fileutils.c:55
#9 file_realpath_dup (path=0x555555de72b0 "/home/fran/Descargas/rutas/bexti.gpx", path@entry=0x555555bfee80 "\226") at fileutils.c:70
#10 0x00005555555d65e5 in a_file_load (top=0x7fffffff, vp=vp@entry=0x555555a6e0a0, vtl=vtl@entry=0x0, filename_or_uri=
If you could attach the failing gpx file (or directly message me it to: rw underscore norris at hotmail dot com - as listed in many of the source files) that would be great help.
Ok, I sent some examples gpx.zip
I don't think I have a system with a security hardened "__fortify_fail ()" enabled, (or Viking doesn't trigger it for me). Hopefully the change incorporated above should address this issue. It would be great if you (inode64) could test with the latest source code to confirm this has fixed it.
I'm Sorry, It Has failed yet :-(
And It fails with files .gpx or .vik
Can you please tell me which OS & Version you are using?
Hopefully then I'll be able to reproduce it locally, e.g. in a virtual machine and investigate deeper, as ATM I don't really understand why it would be failing.
This is my system.
Portage 2.3.40 (python 2.7.14-final-0, default/linux/amd64/17.0/desktop/gnome, gcc-7.3.0, glibc-2.26-r7, 4.14.35-gentoo x86_64)
System uname: Linux-4.14.35-gentoo-x86_64-AMD_FX-tm-6100_Six-Core_Processor-with-gentoo-2.4.1 KiB Mem: 16453528 total, 5557052 free KiB Swap: 2104472 total, 330500 free Timestamp of repository gentoo: Mon, 09 Jul 2018 14:00:01 +0000 Head commit of repository gentoo: 77f0dfa9e5769421d4f4a542dc5ffe6551068c01 sh bash 4.4_p12 ld GNU ld (Gentoo 2.30 p2) 2.30.0 ccache version 3.3.4 [enabled] app-shells/bash: 4.4_p12::gentoo dev-java/java-config: 2.2.0-r4::gentoo dev-lang/perl: 5.24.3-r1::gentoo dev-lang/python: 2.7.14-r1::gentoo, 3.6.5::gentoo dev-util/ccache: 3.3.4-r1::gentoo dev-util/cmake: 3.9.6::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.4.1-r2::gentoo sys-apps/openrc: 0.34.11::gentoo sys-apps/sandbox: 2.13::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.11.6-r3::gentoo, 1.13.4-r2::gentoo, 1.15.1-r2::gentoo sys-devel/binutils: 2.30-r2::gentoo sys-devel/gcc: 7.3.0-r3::gentoo sys-devel/gcc-config: 1.8-r1::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1::gentoo sys-kernel/linux-headers: 4.13::gentoo (virtual/os-headers) sys-libs/glibc: 2.26-r7::gentoo
Can you specify what the compiler options you use for Viking are please?
-O2 -march=k8-sse3 -pipe -msahf -mcx16 -mno-3dnow and make -j6 My CPU is a AMD FX(tm)-6100 Six-Core Processor but I when used -march=native is same result :-(
I'm sorry but I don't really have the time or inclination to get working a Gentoo setup (my initial attempts didn't work in a VM). So without fully understanding why the program fails with the initial stack trace, a work around would be for the latest code in file.c around line 684:
gchar *absolute = file_realpath_dup ( filename );
-->
gchar *absolute = NULL;
Hopefully that should stop it crashing, but with the caveat that loading DEM files / Waypoint Images etc.. that are referenced via a relative file path wouldn't work. [Since it now doesn't know what it's relative to]