SolveSpace Logo SOLVESPACE -- parametric 2d/3d CAD
Examples
Tutorials
Features
Download
Reference
Technology
Library
Forum
Contact
USER FORUM

(you are viewing a thread; or go back to list of threads)

core dump loading an assembly (by wolfmanjm)
Loading any drawing that has assemblies in it causes a core dump on linux, latest version built from git.

Even loading the example asm.slvs from the baox parts demo does the same thing.

crash dump... https://gist.github.com/6fbd38beb91cfa73f092

PS I love this program :) Amazing work here.
Sun Nov 16 2014, 01:16:30
(no subject) (by wolfmanjm)
PS Works fine under windows prebuilt version.
Sun Nov 16 2014, 01:25:19
(no subject) (by wolfmanjm)
This is the back trace.. looks like a strcpy overflow

#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb7a0be0f in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7a0f455 in __GI_abort () at abort.c:91
#3 0xb7a48fca in __libc_message (do_abort=2, fmt=0xb7b42127 "*** %s ***: %s terminated\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:201
#4 0xb7ae2bc5 in __GI___fortify_fail (msg=0xb7b420a8 "buffer overflow detected") at fortify_fail.c:32
#5 0xb7ae199a in __GI___chk_fail () at chk_fail.c:29
#6 0xb7ae0ccd in __strcpy_chk (dest=0x86c288c "/", src=0xbfffb8ca "/datadisk/aux/Stuff/solvespace/2020.slvs",
destlen=<optimized out>) at strcpy_chk.c:61
#7 0x080972c8 in strcpy (__src=0xbfffb8ca "/datadisk/aux/Stuff/solvespace/2020.slvs", __dest=0x86c288c "/")
at /usr/include/i386-linux-gnu/bits/string3.h:105
#8 SolveSpace::LoadUsingTable (this=0x81e5580, key=0xbfffb8bc "Group.impFile",
val=0xbfffb8ca "/datadisk/aux/Stuff/solvespace/2020.slvs") at file.cpp:388
#9 0x08097625 in SolveSpace::LoadFromFile (this=0x81e5580,
filename=0xbfffbd1c "/datadisk/aux/Stuff/solvespace/2020-assembly.slvs") at file.cpp:453
#10 0x080c453d in SolveSpace::MenuFile (id=101) at solvespace.cpp:398
#11 0x08118031 in Fl_Menu_::picked(Fl_Menu_Item const*) ()
#12 0x08118a0e in Fl_Menu_Bar::handle(int) ()
#13 0x0810cb4c in send(Fl_Widget*, int) ()
#14 0x0810cf9c in Fl_Group::handle(int) ()
#15 0x0810adff in Fl_Window::handle(int) ()
#16 0x08109842 in send(int, Fl_Widget*, Fl_Window*) ()
#17 0x0810a6ff in Fl::handle_(int, Fl_Window*) ()
#18 0x0810abc5 in Fl::handle(int, Fl_Window*) ()
#19 0x08128108 in fl_handle(_XEvent const&) ()
#20 0x081298f6 in do_queued_events() ()
#21 0x08129b31 in fl_wait(double) ()
#22 0x0810b718 in Fl::wait(double) ()
#23 0x0810b822 in Fl::wait() ()
#24 0x0805267e in main (argc=1, argv=0xbffff494) at fltk/fltkmain.cpp:1277
Sat Dec 6 2014, 06:44:30
(no subject) (by wolfmanjm)
FWIW I was able to work around this by using -fno-stack-protector -U_FORTIFY_SOURCE in the compile for linus.

The issue is that on line 388 in file.cpp the strcpy triggers the builtin GCC protection for strcpy overflow thinking it is copying to a char rather than a char[MAX_PATH]

strcpy(&(p->P), val);

where &(p->P( is seen to the compiler as a pointer to a char thus trigering the cash in __strcpy_chk whihc is bultin.

The compiler options disable this checking. A better solution would be to fix the very odd usage of a union there.
Sat Dec 6 2014, 20:39:26
Post a reply to this comment:
Your Name:
Your Email:
Subject:
(no HTML tags; use plain text, and hit Enter for a line break)
Attached file (if you want, 5 MB max):
© 2008-2022 SolveSpace contributors. Most recent update June 2 2022.