SOLVESPACE -- parametric 2d/3d CAD

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

'solvespace-cli thumbnail' problem in master (by Sebastian Kuzminsky)
'solvespace-cli thumbnail' crashes every time, with this error message:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

Strace reveals a crazy-sized malloc():

mmap(NULL, 336805789696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)

The size appears random, and independent of what I pass in as --size WIDTHxHEIGHT.

2.x does not have this problem.
Mon Feb 13 2017, 14:41:08
(no subject) (by whitequark)
Um... 2.x doesn't have solvesace-cli.

Can you provide some more details? Ideally a backtrace towards the failed malloc, with the gdb `backtrace full` command.
Mon Feb 13 2017, 16:01:34
(no subject) (by Sebastian Kuzminsky)
You're right, my bad, 2.x doesn't have solvespace-cli.

The master branch works with -DCMAKE_BUILD_TYPE=Debug, but fails with Release.

Here's the less-useful-than-hoped-for backtrace:

(gdb) bt
#0 __GI_raise ([email protected]=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#1 0x00007ffff67c240a in __GI_abort () at abort.c:89
#2 0x00007ffff70d807d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/
#3 0x00007ffff70d6046 in ?? () from /usr/lib/x86_64-linux-gnu/
#4 0x00007ffff70d6091 in std::terminate() () from /usr/lib/x86_64-linux-gnu/
#5 0x00007ffff70d62a9 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/
#6 0x00007ffff70d67cc in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/
#7 0x00005555556d66b8 in SolveSpace::PaintGraphics() ()
#8 0x00005555555a42d3 in std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&), RunCommand(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >)::{lambda(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)#6}>::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#9 0x00005555555a5c7e in RunCommand(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >) ()
#10 0x00005555555a1856 in main ()
Mon Feb 13 2017, 17:41:49
(no subject) (by Sebastian Kuzminsky)
In climain.cpp's RunCommand(), width and height are initialized correctly on line 34, and have the correct value just before the lambda on line 54. But immediately inside the lambda, height has a random crazy value. width is still what it got from sscanf().

I'm building on Debian Stretch, g++ 6.3.0.
Mon Feb 13 2017, 18:12:23
(no subject) (by Sebastian Kuzminsky)
Sorry, my line numbers were off. The sscanf() on 166 gets the right numbers, but they're wrong inside the lambda on 193.
Mon Feb 13 2017, 18:25:45
potential fix (by Sebastian Kuzminsky)
Moving the definition of `unsigned width, height` to the top-level scope of the RunCommand() function makes this work right for me. I wonder if lambda access of pass-by-reference variables is evaluated at run time rather than lambda definition-time (and of course by runtime the variables have passed out of scope).

Alternatively, switching the thumbnail runner lambda from pass-by-reference to pass-by-value also makes the problem go away on my machine.
Mon Feb 13 2017, 18:30:40
(no subject) (by whitequark)
Gah! C++ is full of footguns. I've created an issue to track this,, which you may subscribe to.
Tue Feb 14 2017, 01:20:05
(no subject) (by whitequark)
Fixed in master.
Thu Feb 16 2017, 21:54:44
Post a reply to this comment:
Your Name:
Your Email:
(no HTML tags; use plain text, and hit Enter for a line break)
Attached file (if you want, 5 MB max):
© 2008-2018 SolveSpace contributors. Most recent update Nov 22 2018.