Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SegFault: Linux, gcc-4.8.2 #514

Closed
pdbogen opened this issue Oct 26, 2013 · 58 comments
Closed

SegFault: Linux, gcc-4.8.2 #514

pdbogen opened this issue Oct 26, 2013 · 58 comments

Comments

@pdbogen
Copy link
Contributor

pdbogen commented Oct 26, 2013

Summary:

  • Frequent crashes on Linux when using gcc-4.8.2
  • Reported to also crash with clang 3.3 and 3.4 (trunk)
  • Some reports show that gcc-4.8.1 fixes it, but some reports that it crashes also on 4.8.1

Test case:

linear_extrude( height=10, twist=100, slices=25 ) {
    square([1,1,1]);
}

Crash occurs on "Compile and Render (CGAL)", i.e., F6. Backtrace from gdb:

#0  0x00000000004f0220 in CGAL::Sign CGAL::Filtered_predicate<CGAL::CartesianKernelFunctors::Compare_y_3<CGAL::Simple_cartesian<CGAL::Gmpq> >, CGAL::CartesianKernelFunctors::Compare_y_3<CGAL::Simple_cartesian<CGAL::Interval_nt<false> > >, CGAL::Exact_converter<CGAL::Epeck, CGAL::Simple_cartesian<CGAL::Gmpq> >, CGAL::Approx_converter<CGAL::Epeck, CGAL::Simple_cartesian<CGAL::Interval_nt<false> > >, true>::operator()<CGAL::Point_3<CGAL::Epeck>, CGAL::Point_3<CGAL::Epeck> >(CGAL::Point_3<CGAL::Epeck> const&, CGAL::Point_3<CGAL::Epeck> const&) const ()
#1  0x000000000063222b in CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Smaller_than<CGAL::Epeck, CGAL::Object, CGAL::internal::In_place_list_iterator<CGAL::SNC_in_place_list_sm<CGAL::SNC_sphere_map<CGAL::Epeck, CGAL::SNC_indexed_items, bool> >, std::allocator<CGAL::SNC_in_place_list_sm<CGAL::SNC_sphere_map<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >, int>::operator()(CGAL::Object const&, CGAL::Object const&) ()
#2  0x0000000000633b50 in void std::__introselect<__gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >, long, CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Smaller_than<CGAL::Epeck, CGAL::Object, CGAL::internal::In_place_list_iterator<CGAL::SNC_in_place_list_sm<CGAL::SNC_sphere_map<CGAL::Epeck, CGAL::SNC_indexed_items, bool> >, std::allocator<CGAL::SNC_in_place_list_sm<CGAL::SNC_sphere_map<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >, int> >(__gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >, __gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >, __gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >, long, CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Smaller_than<CGAL::Epeck, CGAL::Object, CGAL::internal::In_place_list_iterator<CGAL::SNC_in_place_list_sm<CGAL::SNC_sphere_map<CGAL::Epeck, CGAL::SNC_indexed_items, bool> >, std::allocator<CGAL::SNC_in_place_list_sm<CGAL::SNC_sphere_map<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >, int>) ()
#3  0x0000000000633d54 in CGAL::Plane_3<CGAL::Epeck> CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::construct_splitting_plane<int>(__gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >, __gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >, __gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >&, int) ()
#4  0x0000000000633f90 in CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Node* CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::build_kdtree<int>(std::vector<CGAL::Object, std::allocator<CGAL::Object> >&, __gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >, int, CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Node*, int) ()
#5  0x00000000006347da in CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Node* CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::build_kdtree<int>(std::vector<CGAL::Object, std::allocator<CGAL::Object> >&, __gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >, int, CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Node*, int) ()
#6  0x0000000000634809 in CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Node* CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::build_kdtree<int>(std::vector<CGAL::Object, std::allocator<CGAL::Object> >&, __gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >, int, CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Node*, int) ()
#7  0x00000000006347da in CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Node* CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::build_kdtree<int>(std::vector<CGAL::Object, std::allocator<CGAL::Object> >&, __gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >, int, CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Node*, int) ()
#8  0x0000000000634809 in CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Node* CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::build_kdtree<int>(std::vector<CGAL::Object, std::allocator<CGAL::Object> >&, __gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >, int, CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::Node*, int) ()
#9  0x0000000000634c89 in CGAL::K3_tree<CGAL::SNC_k3_tree_traits<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > > >::K3_tree(std::vector<CGAL::Object, std::allocator<CGAL::Object> >&, __gnu_cxx::__normal_iterator<CGAL::Object*, std::vector<CGAL::Object, std::allocator<CGAL::Object> > >&) ()
#10 0x00000000006351a8 in CGAL::SNC_point_locator_by_spatial_subdivision<CGAL::SNC_decorator<CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> > >::initialize(CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool>*) ()
---Type <return> to continue, or q <return> to quit---
#11 0x000000000061111c in CGAL::SNC_external_structure_base<int, CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> >::create_volumes() ()
#12 0x0000000000611ede in CGAL::SNC_external_structure<CGAL::SNC_indexed_items, CGAL::SNC_structure<CGAL::Epeck, CGAL::SNC_indexed_items, bool> >::build_external_structure() ()
#13 0x0000000000614f26 in CGAL::Nef_polyhedron_3<CGAL::Epeck, CGAL::SNC_indexed_items, bool>::Nef_polyhedron_3<CGAL::Epeck, CGAL::Polyhedron_items_3, CGAL::HalfedgeDS_default, std::allocator<int> >(CGAL::Polyhedron_3<CGAL::Epeck, CGAL::Polyhedron_items_3, CGAL::HalfedgeDS_default, std::allocator<int> >&) ()
#14 0x00000000005ae17b in CGALEvaluator::evaluateCGALMesh(PolySet const&) ()
#15 0x00000000005af132 in CGALEvaluator::visit(State&, AbstractPolyNode const&) ()
#16 0x00000000004afcc1 in Traverser::traverse(AbstractNode const&, State const&) ()
#17 0x00000000004afc1e in Traverser::traverse(AbstractNode const&, State const&) ()
#18 0x00000000004afdf7 in Traverser::execute() ()
#19 0x00000000005a7cb2 in CGALEvaluator::evaluateCGALMesh(AbstractNode const&) ()
#20 0x0000000000702cad in CGALWorker::work() ()
#21 0x000000000070437d in CGALWorker::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) ()
#22 0x00007ffff53a54c8 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#23 0x00007ffff528efd8 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#24 0x00007ffff47f8e0e in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#25 0x00007ffff3d1693d in clone () from /lib/x86_64-linux-gnu/libc.so.6
@kintel
Copy link
Member

kintel commented Oct 27, 2013

Which version of OpenSCAD, which OS, and how did you install it?

@pdbogen
Copy link
Contributor Author

pdbogen commented Oct 27, 2013

Git commit 54595cc (i.e. latest when I reported it), Debian Sid, compiled from source. Just checked it against f708f5e (i.e., latest now) and it still segfaults.

@TakeItAndRun
Copy link

This works just fine on Win this OpenSCAD http://www.openscad.org version
2013.05.12

Sincerely,

TakeItAndRun

linear_extrude( height=10, twist=100, slices=25 ) {
square([1,1,1]);
}

2013/10/27 Patrick Bogen notifications@github.com

Git commit #54595cc9bfc64cb383790fb18efcdad16e8fe0b0 (i.e. latest when I
reported it), Debian Sid, compiled from source. Just checked it against
f708f5ehttps://github.com/openscad/openscad/commit/f708f5e82bd78fd90b6433d9956f5d0f46c62222(i.e., latest now) and it still segfaults.


Reply to this email directly or view it on GitHubhttps://github.com//issues/514#issuecomment-27164803
.

stempeldergeschichte@googlemail.com karsten@rohrbach.de

P.S. Falls meine E-Mail kürzer ausfällt als Dir angenehm ist:
Ich probiere gerade aus kurze Antworten statt gar keine Antworten zu
schreiben.
Wenn Du gerne mehr lesen möchtest, dann lass es mich bitte wissen.

P.S. In case my e-mail is shorter than you enjoy:
I am currently trying short replies instead of no replies at all.
Please let me know, if you like to read more.

Enjoy!

@kintel
Copy link
Member

kintel commented Oct 27, 2013

It works on Mac as well, with the latest git.

This issue could be environment-dependent (compiler, library versions etc. on your computer), or Linux-specific. I'll try to give it a spin in a VM.

In the meantime, it would be interesting if you tested a few things:

  • Run OpenSCAD on the cmd-line without GUI (e.g. openscad myfile.scad -o out.stl)
  • Check out the latest tagged release from git and rebuild (to limit the scope): git checkout openscad-2013.06

@kintel
Copy link
Member

kintel commented Oct 29, 2013

I did a test compile on the master branch an Ubuntu 12.10 VM, and it worked fine there.
I've got old versions of the libraries though.

@kintel
Copy link
Member

kintel commented Oct 29, 2013

Could you run ./scripts/check-dependencies.sh and see if you can find any similarities to #518?

@pdbogen
Copy link
Contributor Author

pdbogen commented Oct 29, 2013

I see you fixed that script. :)
Note that this is on a different system (still Debian Sid), but I'm getting the same segfault with the same code mentioned above. Also note that the GMP detection is broken on my system; I have version 5.1.2.

pdbogen@serendipity:~/openscad$ scripts/check-dependencies.sh 
depname     minimum     found       OKness      
qt4         4.4         4.8.6       OK
cgal        3.6         4.2         OK
gmp         5.0         ..          NotOK
mpfr        3.0         3.1.2       OK
boost       1.35        1.54        OK
opencsg     1.3.2       1.3.2       OK
glew        1.5.4       1.7.0       OK
eigen       2.0.0       3.2.0       OK
gcc         4.2         4.8.2       OK
bison       2.4         2.7.12      OK
flex        2.5.35      2.5.35      OK
make        3           3.81        OK

@kintel
Copy link
Member

kintel commented Oct 30, 2013

Hm, tough one.
From the list of dependencies, my only guess right now is that you found a bug related to boost.
The drawback is that if you downgrade boost you have to recompile both CGAL and OpenSCAD.

Perhaps building a debug version would provide more info? (qmake CONFIG+=debug)

@kintel
Copy link
Member

kintel commented Oct 30, 2013

Info from duplicate issue #518:

Failed examples:
minkowski() { cube([10,10,1]); cylinder(r=2,h=1); }
hull() { sphere(1); translate([4,0,0]) sphere(1); }

OS: Arch Linux 64-bit

Failed OpenSCAD versions: 2013.06, git f708f5e and git b04734c

Failed with both CGAL 4.3 and CGAL 4.0.2

@kintel
Copy link
Member

kintel commented Oct 30, 2013

@pdbogen Could you verify that what's listed above (#518) is actually giving you the same problems?

@kintel
Copy link
Member

kintel commented Oct 30, 2013

As comparison, Ubuntu 12.10 32-bit with git f708f5e and the following libraries works fine.

depname     minimum     found       OKness      
qt4         4.4         4.8.3       OK          
cgal        3.6         4.0.2       OK          
gmp         5.0         5.0.2       OK          
mpfr        3.0         3.1.0       OK          
boost       1.35        1.49        OK          
opencsg     1.3.2       1.3.2       OK          
glew        1.5.4       1.7.0       OK          
eigen       2.0.0       3.0.93      OK          
gcc         4.2         4.7.2       OK          
bison       2.4         2.5         OK          
flex        2.5.35      2.5.35      OK          
make        3           3.81        OK          

@kintel
Copy link
Member

kintel commented Oct 30, 2013

@pdbogen Could it be related to 32- vs. 64-bit builds? Which variant did you build?

@pdbogen
Copy link
Contributor Author

pdbogen commented Oct 30, 2013

Hmm. I just did qmake -> make -> run. I'm presuming it built 64-bit by default, since I'm on 64-bit. I'll check the other test case later this afternoon, and I'll also try pulling the Ubuntu libs down one by one and seeing if the I can pin the problem down to a specific lib.

Marius Kintel notifications@github.com wrote:

@pdbogen Could it be related to 32- vs. 64-bit builds? Which variant
did you build?


Reply to this email directly or view it on GitHub:
#514 (comment)

Patrick Bogen

@kintel
Copy link
Member

kintel commented Oct 30, 2013

I'm not sure how to generate 32-bit builds under Linux - it might be tricky since you need 32-bit build of all libraries.
Perhaps it's time to set up a 64-bit VM..

@pdbogen
Copy link
Contributor Author

pdbogen commented Oct 30, 2013

On Wed, Oct 30, 2013 at 02:16:16PM -0700, Marius Kintel wrote:

I'm not sure how to generate 32-bit builds under Linux - it might be tricky since you need 32-bit build of all libraries.
Perhaps it's time to set up a 64-bit VM..

It's not too hard on Debian-based systems. Multiarch stuff is super friendly.
Just have to figure out how to tell qmake/make to use 32-bit stuff, but that's
a low bar.

But also, IMO, the wrong answer. :) I'm setting up an Ubuntu chroot now to see
if it's an Ubuntu vs Debian problem.

         .

Patrick Bogen .
...

@benpye
Copy link

benpye commented Oct 31, 2013

I'm am also getting this issue, both with building openscad from source and from the 06 release. I have tried both with the newest and also the libraries as downloaded by the script in the openscad source and get the same issue. I am running Arch Linux (x86_64). https://gist.github.com/benpye/df34110801da93d9d9b5 is the Library Info for the from master build with the libraries it downloaded.

@kintel
Copy link
Member

kintel commented Oct 31, 2013

It also works for me on Debian 6.0.4 64-bit with the following libraries

depname     minimum     found       OKness      
qt4         4.4         4.6.3       OK          
cgal        3.6         4.1         OK          
gmp         5.0         5.0.5       OK          
mpfr        3.0         3.1.1       OK          
boost       1.35        1.49        OK          
opencsg     1.3.2       1.3.2       OK          
glew        1.5.4       1.7.0       OK          
eigen       2.0.0       3.1.1       OK          
gcc         4.2         4.4.5       OK          
bison       2.4         2.4.1       OK          
flex        2.5.35      2.5.35      OK          
make        3           3.81        OK          

@benpye
Copy link

benpye commented Oct 31, 2013

depname     minimum     found       OKness      
qt4         4.4         4.8.5       OK          
cgal        3.6         4.0.2       OK          
gmp         5.0         5.0.5       OK          
mpfr        3.0         3.1.1       OK          
boost       1.35        1.53        OK          
opencsg     1.3.2       1.3.2       OK          
glew        1.5.4       1.7.0       OK          
eigen       2.0.0       3.1.1       OK          
gcc         4.2         4.8.2       OK          
bison       2.4         3.0         OK          
flex        2.5.35      2.5.37      OK          
make        3           4.0         OK          

is what I am running.

@benpye
Copy link

benpye commented Oct 31, 2013

depname     minimum     found       OKness      
qt4         4.4         4.8.5       OK          
cgal        3.6         4.0.2       OK          
gmp         5.0         5.0.5       OK          
mpfr        3.0         3.1.1       OK          
boost       1.35        1.50        OK          
opencsg     1.3.2       1.3.2       OK          
glew        1.5.4       1.7.0       OK          
eigen       2.0.0       3.1.1       OK          
gcc         4.2         4.8.2       OK          
bison       2.4         3.0         OK          
flex        2.5.35      2.5.37      OK          
make        3           4.0         OK          

Still produces the error, cannot test boost 1.49 as it is not compatible with newer versions of GCC.

@benpye
Copy link

benpye commented Oct 31, 2013

To rule out another issue, just build with clang 3.4 (trunk) and got the same seg fault, with the following libraries.

depname     minimum     found       OKness      
qt4         4.4         4.8.5       OK          
cgal        3.6         4.0.2       OK          
gmp         5.0         5.0.5       OK          
mpfr        3.0         3.1.1       OK          
boost       1.35        1.53        OK          
opencsg     1.3.2       1.3.2       OK          
glew        1.5.4       1.7.0       OK          
eigen       2.0.0       3.1.1       OK          
gcc         4.2         4.8.2       OK          
bison       2.4         3.0         OK          
flex        2.5.35      2.5.37      OK          
make        3           4.0         OK          

@sjoerdtimmer
Copy link

I had a similar issue (see #528) and solved it by updating eigen3 before recompiling everything(openscad/cgal/etc.). yaourt/the aur does not do this since the old version is within range and it is an optional dependency but with eigen3 version 3.2.0-1 the problem was solved for me. Just hoping this may help someone else. Make sure to rebuild cgal/openscad/etc. after updating eigen3...

@kintel
Copy link
Member

kintel commented Nov 1, 2013

It might be that we're experiencing some issues with memory alignment using components from eigen and that updating eigen is an arbitrary way of mixing things up. It might also have been a bug in eigen.
I'll look into the memory alignment situation and see if I can make it more robust.

@benpye
Copy link

benpye commented Nov 1, 2013

Updated Eigen on my end to 3.2.0 no change.

@donbright
Copy link
Sponsor Member

i would be curious to see a comparison

   ./openscad --info
   ldd ./openscad

another interesting experiment would be to build the tests, ( doc/testing.txt for instructions) then do this:

   ./openscad_nogui --info
    ldd ./openscad_nogui
    ./openscad_nogui whatever.scad -o x.stl

the cmake build system works differently than the qmake build system.

in other words, the question is this - is your binary calling the same library versions it was compiled against? and is check_dependencies.sh just an awful piece of trash that i never should have written?

@pdbogen
Copy link
Contributor Author

pdbogen commented Nov 1, 2013

pdbogen@serendipity:~/openscad$ ./openscad --info
OpenSCAD Version: 2013.10.29
Compiler, build date: GCC "4.8.2", Oct 29 2013
Boost version: 1_54
Eigen version: 3.2.0
CGAL version, kernels: 4.2, Epeck, Extended_cartesian<Gmpq>, Epeck
OpenCSG version: OpenCSG 1.3.2
Qt version: 4.8.6
MingW build: No
OPENSCADPATH: 

GLEW version: 1.7.0
OpenGL Version: 3.0 Mesa 9.2.2
GL Renderer: Mesa DRI Intel(R) Ivybridge Mobile 
GL Vendor: Intel Open Source Technology Center
RGBA(8888), depth(24), stencil(8)
GL_ARB_framebuffer_object: yes
GL_EXT_framebuffer_object: yes
GL_EXT_packed_depth_stencil: yes
GL context creator: GLX
PNG generator: lodepng
GLX version: 1.4
OS info: Linux 3.12.0-rc1cbpxl #2 SMP PREEMPT Wed Sep 18 00:10:17 PDT 2013
Machine: x86_64

pdbogen@serendipity:~/openscad$ ldd ./openscad
    linux-vdso.so.1 (0x00007fff415ff000)
    libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fbf183aa000)
    libmpfr.so.4 => /usr/lib/x86_64-linux-gnu/libmpfr.so.4 (0x00007fbf1814f000)
    libCGAL.so.10 => /usr/lib/libCGAL.so.10 (0x00007fbf17f26000)
    libopencsg.so.1 => /usr/lib/x86_64-linux-gnu/libopencsg.so.1 (0x00007fbf17d09000)
    libGLEW.so.1.7 => /usr/lib/x86_64-linux-gnu/libGLEW.so.1.7 (0x00007fbf17a97000)
    libboost_thread.so.1.54.0 => /usr/lib/libboost_thread.so.1.54.0 (0x00007fbf1787f000)
    libboost_program_options.so.1.54.0 => /usr/lib/libboost_program_options.so.1.54.0 (0x00007fbf1760f000)
    libboost_filesystem.so.1.54.0 => /usr/lib/libboost_filesystem.so.1.54.0 (0x00007fbf173f8000)
    libboost_system.so.1.54.0 => /usr/lib/libboost_system.so.1.54.0 (0x00007fbf171f3000)
    libboost_regex.so.1.54.0 => /usr/lib/libboost_regex.so.1.54.0 (0x00007fbf16ee5000)
    libQtOpenGL.so.4 => /usr/lib/x86_64-linux-gnu/libQtOpenGL.so.4 (0x00007fbf16be7000)
    libQtGui.so.4 => /usr/lib/x86_64-linux-gnu/libQtGui.so.4 (0x00007fbf15f3b000)
    libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4 (0x00007fbf15a57000)
    libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007fbf157f9000)
    libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007fbf1558a000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fbf1524f000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbf15033000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fbf14d2f000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbf14a31000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fbf1481b000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbf1446e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fbf1863e000)
    libXmu.so.6 => /usr/lib/x86_64-linux-gnu/libXmu.so.6 (0x00007fbf14254000)
    libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007fbf14044000)
    libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fbf13e31000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fbf13c29000)
    libicuuc.so.48 => /usr/lib/x86_64-linux-gnu/libicuuc.so.48 (0x00007fbf138bc000)
    libicui18n.so.48 => /usr/lib/x86_64-linux-gnu/libicui18n.so.48 (0x00007fbf134f4000)
    libicudata.so.48 => /usr/lib/x86_64-linux-gnu/libicudata.so.48 (0x00007fbf12184000)
    libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fbf11ee4000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbf11ce0000)
    libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007fbf11ad6000)
    libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007fbf11899000)
    libaudio.so.2 => /usr/lib/x86_64-linux-gnu/libaudio.so.2 (0x00007fbf11680000)
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fbf11381000)
    libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007fbf11159000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fbf10f41000)
    libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fbf10cf1000)
    libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007fbf10ae9000)
    libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007fbf108ce000)
    libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007fbf106a7000)
    libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007fbf104a4000)
    libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007fbf1029e000)
    libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007fbf1009b000)
    libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007fbf0fe83000)
    libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007fbf0fc7e000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fbf0fa5e000)
    libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007fbf0f858000)
    libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007fbf0f64c000)
    libXt.so.6 => /usr/lib/x86_64-linux-gnu/libXt.so.6 (0x00007fbf0f3e5000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fbf0f1bb000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fbf0efb6000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fbf0ed78000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fbf0eb70000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fbf0eb69000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fbf0e964000)

I'll try building the tests a little later.

On Fri, Nov 01, 2013 at 04:35:59PM -0700, donbright wrote:

i would be curious to see a comparison

   ./openscad --info
   ldd ./openscad

another interesting experiment would be to build the tests, ( doc/testing.txt for instructions) then do this:

   ./openscad_nogui --info
    ldd ./openscad_nogui
    ./openscad_nogui whatever.scad -o x.stl

the cmake build system works differently than the qmake build system.

in other words, the question is this - is your binary calling the same library versions it was compiled against? and is check_dependencies.sh just an awful piece of trash that i never should have written?


Reply to this email directly or view it on GitHub:
#514 (comment)

         .

Patrick Bogen .
...

@kintel
Copy link
Member

kintel commented Nov 2, 2013

Step-by-step reproduction instructions from @benpye (verified by me in a VirtualBox VM):

To reproduce the segfault do the following:
Install Manjaro Linux 64-Bit (I used the OpenBox edition, it's smaller)
Then once installed do the following in a terminal:
$ sudo pacman -Syu # May have to run this twice
$ sudo pacman -S base-devel git
$ git clone https://github.com/openscad/openscad.git
$ cd openscad
$ source scripts/setenv-unibuild.sh
$ ./scripts/uni-build-dependencies.sh
$ qmake-qt4
$ make
$ ./openscad
If in a virtual machine the preview will fail to render, this doesn't matter, the following script will cause the segfault if you attempt to render (F6)

translate([0,4,0]) cylinder(h=4,r=2);
translate([3.5,6,0]) cylinder(h=4,r=2);
```tps://gist.github.com/benpye/cba2238cb3151e07206d

@kintel
Copy link
Member

kintel commented Nov 4, 2013

I've gotten reports that this appears to be present when using gcc-4.8.2, but work well with both 4.8.1 and 4.7.
One user also reported a crash using clang, although clang on Mac works.

I think the next step would be to get it to crash without OpenSCAD using a pure CGAL example.

@donbright
Copy link
Sponsor Member

i just built dependencies and openscad with clang version 3.2-1~exp9ubuntu1 and there are no crashes.

its definitely an issue with gcc 4.8.x

im not sure about 4.8.1 vs 4.8.2, i built 32 bit mingw with 4.8.1 and it seems OK. will have to do more testing.

gcc 4.8.2 has been disallowed with commit f175bae

@gringer
Copy link
Contributor

gringer commented Dec 3, 2013

Please alter the code to use another gcc version if it exists as a temporary fix. My system has 4.7 present, but this commit means that the code can't compile at all on my system.

@t-paul
Copy link
Member

t-paul commented Dec 8, 2013

There's no need for a code change as workaround (note there is no known code change that triggers the problem in the first place, it might even come from a library used). Normally distributions allow parallel install of both gcc 4.7 and 4.8 (confirmed to work on Debian, Ubuntu and Arch-Linux), so using

qmake-qt4 QMAKE_CC=gcc-4.7 QMAKE_CXX=g++-4.7

forces the OpenSCAD compile to use gcc-4.7 even if the latest one is the system default.

For the test-cases use:

cmake -DCMAKE_C_COMPILER=gcc-4.7 -DCMAKE_CXX_COMPILER=g++-4.7

@GilesBathgate
Copy link
Contributor

@t-paul I think @gringer would like it to detect the 4.7 install automatically and use that if available as per: brodykenrick@3b9b7e6

@t-paul
Copy link
Member

t-paul commented Dec 8, 2013

Maybe the warning could be added to provide the information about the problem and linking here.

Updating the scripts for all systems to detect all possible cases and combinations might be a big task. That would probably need to handle MacOS and MinGW as well. Also some systems might even still have old gcc-4.6 use clang instead. So that's a big can of worms.

@kintel
Copy link
Member

kintel commented Dec 8, 2013

Could this be related to this bug? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58800

@brodykenrick
Copy link
Contributor

I was not thinking those changes would make it back up into the main branch
(I reverted them before that pull request) - they were just local for me to
avoid making time wasting mistakes on compiling to a segfault.

I agree with @t-paul that all the effort of trying to do the auto-correct
compiler options is significant and a simple warning of the issue could be
in place until we eventually find the real fix (or that the problem truly
needs such a workaround) probably makes more sense.

I think there is enough noise/chatter now of how to work around this issue
in GH and the forum that people shouldn't get caught out.

On 9 December 2013 05:43, Giles Bathgate notifications@github.com wrote:

@t-paul https://github.com/t-paul I think @gringerhttps://github.com/gringerwould like it to detect the 4.7 install automatically and use that if
available as per: brodykenrick/openscad@3b9b7e6brodykenrick@3b9b7e6


Reply to this email directly or view it on GitHubhttps://github.com//issues/514#issuecomment-30088021
.

@hroncok
Copy link
Contributor

hroncok commented Dec 11, 2013

Normally distributions allow parallel install of both gcc 4.7 and 4.8
(confirmed to work on Debian, Ubuntu and Arch-Linux)

Doesn't work that way in Fedora. 4.8.2 is the only gcc in Fedora 19+.

This shouldn't go to the new release, as it would mean the openscad package in Fedora would break.

@t-paul
Copy link
Member

t-paul commented Dec 11, 2013

This shouldn't go to the new release, as it would mean the openscad package in Fedora would break.

 

Again: This issue is a bug-report, not a code change. The issue also occurs with the currently released version when compiled with gcc-4.8.2, I think.

 

So "this shouldn't go in" is not really an existing option. There are only 2 options at this time. 1) compile with different gcc, 2) find and fix the bug (with the emphasis on find).

 

Any ideas how to track down and fix the bug are greatly appreciated.

@hroncok
Copy link
Contributor

hroncok commented Dec 11, 2013

I meant this should be considered blocker for the next stable release and should be fixed properly before the release happen.

I cannot reproduce the bug with 2013.06 compiled on 4.8.1, will try to recompile with 4.8.2 soon.

@hroncok
Copy link
Contributor

hroncok commented Dec 11, 2013

So with 4.8.2 it also crashes on 2013.06 on Fedora.

Could this be related to this bug? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58800
This is merged into Fedoras gcc 4.8.2-2, I'll try to use it and we'll see.

@t-paul
Copy link
Member

t-paul commented Dec 11, 2013

I've modified /usr/include/c++/4.8/bits/stl_algo.h (on Debian jessie) and with that change, the crash is gone when compiling with 4.8.2.

BUT: The patch seems to change only one occurrence of the problem, so it might not catch all cases :(.

@t-paul
Copy link
Member

t-paul commented Dec 11, 2013

Ok, Debian ships a different file from what I'm seeing in the gcc svn repo. So all should be fine once the bugfix ends up in the distributions.

@hroncok
Copy link
Contributor

hroncok commented Dec 11, 2013

So in Fedora, we are blocked by http://gcc.gnu.org/PR59470 and then we'll
ship fixed version.

@kintel
Copy link
Member

kintel commented Dec 12, 2013

@hroncok Is the 59470 gcc issue related to 58800 somehow?

@hroncok
Copy link
Contributor

hroncok commented Dec 12, 2013

@kintel No, it only blocks the update for being pushed, don't worry, sorry for not being clear enough.

@t-paul
Copy link
Member

t-paul commented Dec 13, 2013

For reference, debian bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732042

@hroncok
Copy link
Contributor

hroncok commented Dec 23, 2013

OK, fixed in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1025072

@t-paul
Copy link
Member

t-paul commented Jan 14, 2014

Fix migrated to debian jessie/testing with libstdc++-4.8-dev (4.8.2-12).

@t-paul
Copy link
Member

t-paul commented Mar 9, 2014

Fix confirmed for Arch Linux with gcc 4.8.2-8.

shlevy added a commit to NixOS/nixpkgs that referenced this issue Apr 20, 2014
Description from ambrop72:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58800

I have not been able to test this due to nix wanting to rebuild lots of
things before building gcc.
Patch was created with: svn diff -r 203872:203873
http://gcc.gnu.org/svn/gcc/branches

This should fix a crash in OpenSCAD: openscad/openscad#514
@kintel
Copy link
Member

kintel commented Apr 22, 2014

Closing as gcc bug

@memosphere
Copy link

PPS: Compiles and runs without error for me...
When compiling in Ubuntu 14.04.1 LTS, However, the bug's warning has not been fixed.


In file included from src/LibraryInfo.cc:8:0:
src/version_check.h:118:2: warning: #warning "gcc 4.8.2 contains a bug causing a crash in CGAL." [-Wcpp]
 #warning "gcc 4.8.2 contains a bug causing a crash in CGAL."
  ^

Also had to manually install libqscintilla2-dev

ii  libqscintilla2-dev                                          2.8.1-2ubuntu1                                      all          Scintilla source code editing widget for Qt4, development files

depname     minimum     found       OKness      
qt          4.4         5.2.1       OK          
qscintilla2 2.7         2.8.1       OK          
cgal        3.6         4.2         OK          
gmp         5.0         5.1.3       OK          
mpfr        3.0         3.1.2       OK          
boost       1.35        1.54        OK          
opencsg     1.3.2       1.3.2       OK          
glew        1.5.4       1.7.0       OK          
eigen       3.0         3.2.0       OK          
glib2       2.0         2.40.2      OK          
fontconfig  2.10        2.11.       OK          
freetype2   2.4         17.1.11     OK          
harfbuzz    0.9.19      0.9.27      OK          
gcc         4.2         4.8.2       OK          
bison       2.4         3.0.2       OK          
flex        2.5.35      2.5.35      OK         
make        3           3.81        OK          

PPPS: Check dependencies is definitely not a piece of trash. It may not cover everything, but more info is better than less. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests