Openscad crash on Intersection()

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Openscad crash on Intersection()

Apass
I'm working with a complex model and I get an intereseting crash in shared_ptr.hpp Line: 414 - Expression: px != 0 (see attached picture - I hope I can attach a picture).
I get this crash in all of the last 3 windows releases and also in the latest snapshot.
If you need more info (model files) please contact me directly as I'm not allowed to publish the models.

openscad_crash.JPG (27K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Triffid Hunter
On Wed, Jan 18, 2012 at 8:01 PM, Pasca Andrei <[hidden email]> wrote:
I'm working with a complex model and I get an intereseting crash in shared_ptr.hpp Line: 414 - Expression: px != 0 (see attached picture - I hope I can attach a picture).
I get this crash in all of the last 3 windows releases and also in the latest snapshot.
If you need more info (model files) please contact me directly as I'm not allowed to publish the models.

Please pare your model down to the absolute minimum code that reproduces this issue. That process should also remove the information that you're keeping private.
Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Apass
I tried to do that but it's quite a complex model and I'm kind of time constrained.
Trying to do that, I discovered that changing a model variable creates or solves the issue.
 
The code I'm using looks like this:
 
color([1, 0, 0, 1])
intersection(){
top_comp(top_comp_red, top_comp_green, top_comp_blue, top_comp_alfa, board_height, collision_offset);
top_keepout(top_h_limit_red, top_h_limit_green, top_h_limit_blue, top_h_limit_alfa, board_height, top_max_height, top_draw_max, top_draw_limit);
}
 
The variable that generates the error is top_draw_max and controls an if statement found in top_keepout module. (Basically, together with top_draw_limit, controls if certain height objects are drawn or not).
 
module top_keepout(top_h_limit_red, top_h_limit_green, top_h_limit_blue, top_h_limit_alfa, board_height, top_max_height, top_draw_max, top_draw_limit){
    translate([0, 0, top_max_height + board_height + 1])
    rotate(a=[0,180,0])
    color([top_h_limit_red, top_h_limit_green, top_h_limit_blue, top_h_limit_alfa])
    union(){
        if (( top_draw_max == 1) || (top_draw_limit >= 0.10)){
            linear_extrude(height = top_max_height - 0.10 + 1)
            union(){
             polygon(points = [[... some polygon points... ]], paths = [[... some paths...]]);
            }
        }
    }
}
top_comp module looks like
 
module top_comp(top_comp_red, top_comp_green, top_comp_blue, top_comp_alfa, board_height, collision_offset){
    translate([0, 0, board_height])
    color([top_comp_red, top_comp_green, top_comp_blue, top_comp_alfa])
    union(){
        translate([-80.01, 26.66, 0])
        rotate([0, 0, 90.00])
        some_component_name(collision_offset);
    }
}
 
module some_component_name(collision_offset){
    linear_extrude(height = 1.45 + collision_offset)
    union(){
        union(){
            polygon(points = [[... again, some poly points... ]], paths = [[... some paths....]]);
        }
        if (collision_offset > 0){
            edges(....2 points coordinates..., collision_offset);
            .
            .
            .
            edges(....2 points coordinates..., collision_offset);
        }
    }
}
module edges(x1, y1, x2, y2, collision_offset){
    translate([x1, y1, 0])
    rotate([0, 0, atan2(y2 - y1, x2 - x1)])
    translate([-1 * collision_offset, -1 * collision_offset, 0])
    square([sqrt((x1 - x2)  * (x1 - x2) + (y1 - y2) * (y1 - y2)) + 2 * collision_offset, 2 * collision_offset]);
}
If I'll have some time, maybe I'll try to simplify the model but I can't promisse a thing :(.

From: Triffid Hunter <[hidden email]>
To: Pasca Andrei <[hidden email]>; [hidden email]
Sent: Wednesday, January 18, 2012 11:10 AM
Subject: Re: [OpenSCAD] Openscad crash on Intersection()

On Wed, Jan 18, 2012 at 8:01 PM, Pasca Andrei <[hidden email]> wrote:
I'm working with a complex model and I get an intereseting crash in shared_ptr.hpp Line: 414 - Expression: px != 0 (see attached picture - I hope I can attach a picture).
I get this crash in all of the last 3 windows releases and also in the latest snapshot.
If you need more info (model files) please contact me directly as I'm not allowed to publish the models.

Please pare your model down to the absolute minimum code that reproduces this issue. That process should also remove the information that you're keeping private.


Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

kintel
Administrator
In reply to this post by Apass
Hi again,

Thanks for the privately provided files.
This was a nasty bug which I cannot believe not more people are hit by.
Fixed in master.

https://github.com/openscad/openscad/commit/222d0d16e3383051c6fcef7b5e6de2559868c9fd

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Apass
Hello and thanks for the correction.
I wonder though if the latest development snapshot (from the 25th) includes the bug fix. As I tried using it and got the same error (but this time the error message says line 424 instead of 414).

From: Marius Kintel <[hidden email]>
To: Pasca Andrei <[hidden email]>; [hidden email]
Sent: Wednesday, January 25, 2012 3:22 AM
Subject: Re: [OpenSCAD] Openscad crash on Intersection()

Hi again,

Thanks for the privately provided files.
This was a nasty bug which I cannot believe not more people are hit by.
Fixed in master.

https://github.com/openscad/openscad/commit/222d0d16e3383051c6fcef7b5e6de2559868c9fd

-Marius



Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Brad Pitcher
It should, it was built from this commit: https://github.com/openscad/openscad/commit/d8ee4bdb2ffea5caf2925582bea901aca2746342

You can verify that by opening the Help->About dialog, which should show "OpenSCAD 2012.01.25 (git d8ee4bd)". That's the short version of the same commit hash.

On Wed, Jan 25, 2012 at 1:43 PM, Pasca Andrei <[hidden email]> wrote:
Hello and thanks for the correction.
I wonder though if the latest development snapshot (from the 25th) includes the bug fix. As I tried using it and got the same error (but this time the error message says line 424 instead of 414).

From: Marius Kintel <[hidden email]>

To: Pasca Andrei <[hidden email]>; [hidden email]
Sent: Wednesday, January 25, 2012 3:22 AM

Subject: Re: [OpenSCAD] Openscad crash on Intersection()

Hi again,

Thanks for the privately provided files.
This was a nasty bug which I cannot believe not more people are hit by.
Fixed in master.

https://github.com/openscad/openscad/commit/222d0d16e3383051c6fcef7b5e6de2559868c9fd

-Marius




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

kintel
Administrator
In reply to this post by Apass
On Jan 25, 2012, at 23:08 PM, Pasca Andrei wrote:

> Yes, I'm using the same files, maybe you trimmed down the models I sent to isolate the problem and missed this new error :(.
> I checked the git version and saw that it should include the bug fix.
> git d8ee4bd
>
It works fine on Mac. I also tried under Windows (in a VM with Brad's latest build) and it just hangs after compiling, but doesn't crash.
Any chance you could try slimming down the model?

..or are there anyone else who could try reproducing this under Windows (ask Pasca for the files in question)?

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Apass
I trimmed down the model and sent the new files back to Marius. (I spent a day on that).
I checked the model also on my home machine and still crashes Openscad.
If somebody of you is also intrested in debugging the issue, please let me now so that I can send you the models.
From what I saw, there is some kind of interaction with if statements... but I don't know.

From: Marius Kintel <[hidden email]>
To: Pasca Andrei <[hidden email]>; [hidden email]
Sent: Thursday, January 26, 2012 1:41 PM
Subject: Re: [OpenSCAD] Openscad crash on Intersection()

On Jan 25, 2012, at 23:08 PM, Pasca Andrei wrote:

> Yes, I'm using the same files, maybe you trimmed down the models I sent to isolate the problem and missed this new error :(.
> I checked the git version and saw that it should include the bug fix.
> git d8ee4bd
>
It works fine on Mac. I also tried under Windows (in a VM with Brad's latest build) and it just hangs after compiling, but doesn't crash.
Any chance you could try slimming down the model?

..or are there anyone else who could try reproducing this under Windows (ask Pasca for the files in question)?

-Marius



Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

kintel
Administrator
On Jan 26, 2012, at 20:58 PM, Pasca Andrei wrote:

> I trimmed down the model and sent the new files back to Marius. (I spent a day on that).
> I checked the model also on my home machine and still crashes Openscad.
> If somebody of you is also intrested in debugging the issue, please let me now so that I can send you the models.
> From what I saw, there is some kind of interaction with if statements... but I don't know.
>
Thanks. I now managed to reproduce this on my Mac as well, and I've found and fixed one bug (hopefully _the_ bug ;)).

The problem was that your intersection resulted in an empty model. After the recent improvements in CSG normalization, we can detect this and reduce the tree to nothing. Unfortunately, this was never tested and the client code didn't handle it.

I haven't tested this much, but your example now works (results in an empty model, but I guess that's expected).

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Apass
Hello all
Could someone with a windows build-setup please create a new development snapshop?
Thank you all in advance!
Andrei

From: Marius Kintel <[hidden email]>
To: Pasca Andrei <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, January 27, 2012 1:30 PM
Subject: Re: [OpenSCAD] Openscad crash on Intersection()

On Jan 26, 2012, at 20:58 PM, Pasca Andrei wrote:

> I trimmed down the model and sent the new files back to Marius. (I spent a day on that).
> I checked the model also on my home machine and still crashes Openscad.
> If somebody of you is also intrested in debugging the issue, please let me now so that I can send you the models.
> From what I saw, there is some kind of interaction with if statements... but I don't know.
>
Thanks. I now managed to reproduce this on my Mac as well, and I've found and fixed one bug (hopefully _the_ bug ;)).

The problem was that your intersection resulted in an empty model. After the recent improvements in CSG normalization, we can detect this and reduce the tree to nothing. Unfortunately, this was never tested and the client code didn't handle it.

I haven't tested this much, but your example now works (results in an empty model, but I guess that's expected).

-Marius



Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Brad Pitcher

Yes, I'm working on it, will post an update in an hour or two.

On Jan 27, 2012 2:50 PM, "Pasca Andrei" <[hidden email]> wrote:
Hello all
Could someone with a windows build-setup please create a new development snapshop?
Thank you all in advance!
Andrei

From: Marius Kintel <[hidden email]>
To: Pasca Andrei <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, January 27, 2012 1:30 PM
Subject: Re: [OpenSCAD] Openscad crash on Intersection()

On Jan 26, 2012, at 20:58 PM, Pasca Andrei wrote:

> I trimmed down the model and sent the new files back to Marius. (I spent a day on that).
> I checked the model also on my home machine and still crashes Openscad.
> If somebody of you is also intrested in debugging the issue, please let me now so that I can send you the models.
> From what I saw, there is some kind of interaction with if statements... but I don't know.
>
Thanks. I now managed to reproduce this on my Mac as well, and I've found and fixed one bug (hopefully _the_ bug ;)).

The problem was that your intersection resulted in an empty model. After the recent improvements in CSG normalization, we can detect this and reduce the tree to nothing. Unfortunately, this was never tested and the client code didn't handle it.

I haven't tested this much, but your example now works (results in an empty model, but I guess that's expected).

-Marius




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Brad Pitcher
Updated the Windows binary, I hope it fixes the problem for you.

On Fri, Jan 27, 2012 at 2:51 PM, Brad Pitcher <[hidden email]> wrote:

Yes, I'm working on it, will post an update in an hour or two.

On Jan 27, 2012 2:50 PM, "Pasca Andrei" <[hidden email]> wrote:
Hello all
Could someone with a windows build-setup please create a new development snapshop?
Thank you all in advance!
Andrei

From: Marius Kintel <[hidden email]>
To: Pasca Andrei <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, January 27, 2012 1:30 PM
Subject: Re: [OpenSCAD] Openscad crash on Intersection()

On Jan 26, 2012, at 20:58 PM, Pasca Andrei wrote:

> I trimmed down the model and sent the new files back to Marius. (I spent a day on that).
> I checked the model also on my home machine and still crashes Openscad.
> If somebody of you is also intrested in debugging the issue, please let me now so that I can send you the models.
> From what I saw, there is some kind of interaction with if statements... but I don't know.
>
Thanks. I now managed to reproduce this on my Mac as well, and I've found and fixed one bug (hopefully _the_ bug ;)).

The problem was that your intersection resulted in an empty model. After the recent improvements in CSG normalization, we can detect this and reduce the tree to nothing. Unfortunately, this was never tested and the client code didn't handle it.

I haven't tested this much, but your example now works (results in an empty model, but I guess that's expected).

-Marius




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad


Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Apass
Hello again
I checked both the binary and the installer and both fail again with the same error. However, both files report the same date and git version as in the previous build - 2012.01.25 git d8ee4bd.
Was there an error on the upload? (but I guess not, since the intaller from the 25th is smaller by 6 bytes that the installer from the 27th).
And while we're here - I wonder if the bug and the bug fix affects not only the intersection but also the difference, since also this one can result in empty trees after normalization?
 

From: Brad Pitcher <[hidden email]>
To: [hidden email]; Pasca Andrei <[hidden email]>
Sent: Saturday, January 28, 2012 3:04 AM
Subject: Re: [OpenSCAD] Openscad crash on Intersection()

Updated the Windows binary, I hope it fixes the problem for you.

On Fri, Jan 27, 2012 at 2:51 PM, Brad Pitcher <[hidden email]> wrote:
Yes, I'm working on it, will post an update in an hour or two.
On Jan 27, 2012 2:50 PM, "Pasca Andrei" <[hidden email]> wrote:
Hello all
Could someone with a windows build-setup please create a new development snapshop?
Thank you all in advance!
Andrei

From: Marius Kintel <[hidden email]>
To: Pasca Andrei <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, January 27, 2012 1:30 PM
Subject: Re: [OpenSCAD] Openscad crash on Intersection()

On Jan 26, 2012, at 20:58 PM, Pasca Andrei wrote:

> I trimmed down the model and sent the new files back to Marius. (I spent a day on that).
> I checked the model also on my home machine and still crashes Openscad.
> If somebody of you is also intrested in debugging the issue, please let me now so that I can send you the models.
> From what I saw, there is some kind of interaction with if statements... but I don't know.
>
Thanks. I now managed to reproduce this on my Mac as well, and I've found and fixed one bug (hopefully _the_ bug ;)).

The problem was that your intersection resulted in an empty model. After the recent improvements in CSG normalization, we can detect this and reduce the tree to nothing. Unfortunately, this was never tested and the client code didn't handle it.

I haven't tested this much, but your example now works (results in an empty model, but I guess that's expected).

-Marius




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad




Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Brad Pitcher

Sounds like the build may have failed, but still packaged up the old .exe anyway. I'll build again and watch closer this time. I did notice that the build took 2-3 times longer than normal, which seemed a little odd.

On Sat, Jan 28, 2012 at 9:13 AM, Pasca Andrei <[hidden email]> wrote:
Hello again
I checked both the binary and the installer and both fail again with the same error. However, both files report the same date and git version as in the previous build - 2012.01.25 git d8ee4bd.
Was there an error on the upload? (but I guess not, since the intaller from the 25th is smaller by 6 bytes that the installer from the 27th).
And while we're here - I wonder if the bug and the bug fix affects not only the intersection but also the difference, since also this one can result in empty trees after normalization?
 

From: Brad Pitcher <[hidden email]>
To: [hidden email]; Pasca Andrei <[hidden email]>
Sent: Saturday, January 28, 2012 3:04 AM

Subject: Re: [OpenSCAD] Openscad crash on Intersection()

Updated the Windows binary, I hope it fixes the problem for you.

On Fri, Jan 27, 2012 at 2:51 PM, Brad Pitcher <[hidden email]> wrote:
Yes, I'm working on it, will post an update in an hour or two.
On Jan 27, 2012 2:50 PM, "Pasca Andrei" <[hidden email]> wrote:
Hello all
Could someone with a windows build-setup please create a new development snapshop?
Thank you all in advance!
Andrei

From: Marius Kintel <[hidden email]>
To: Pasca Andrei <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Friday, January 27, 2012 1:30 PM
Subject: Re: [OpenSCAD] Openscad crash on Intersection()

On Jan 26, 2012, at 20:58 PM, Pasca Andrei wrote:

> I trimmed down the model and sent the new files back to Marius. (I spent a day on that).
> I checked the model also on my home machine and still crashes Openscad.
> If somebody of you is also intrested in debugging the issue, please let me now so that I can send you the models.
> From what I saw, there is some kind of interaction with if statements... but I don't know.
>
Thanks. I now managed to reproduce this on my Mac as well, and I've found and fixed one bug (hopefully _the_ bug ;)).

The problem was that your intersection resulted in an empty model. After the recent improvements in CSG normalization, we can detect this and reduce the tree to nothing. Unfortunately, this was never tested and the client code didn't handle it.

I haven't tested this much, but your example now works (results in an empty model, but I guess that's expected).

-Marius




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad





Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

kintel
Administrator
In reply to this post by Apass

On Jan 28, 2012, at 18:13 PM, Pasca Andrei wrote:

> I checked both the binary and the installer and both fail again with the same error. However, both files report the same date and git version as in the previous build - 2012.01.25 git d8ee4bd.

Looks like the wrong version.

> And while we're here - I wonder if the bug and the bug fix affects not only the intersection but also the difference, since also this one can result in empty trees after normalization?

Both should be fixed.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Brad Pitcher

It likes like a recent commit (https://github.com/openscad/openscad/commit/1ffcaae04d577619c1956e96bec47008098a2ed7) broke the windows build:

i686-pc-mingw32-g++ -c -pipe -fno-keep-inline-dllexport -fno-strict-aliasing -fpermissive -frounding-math -DEIGEN_DONT_ALIGN -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DOPENSCAD_VERSION=2012.01.28 -DOPENSCAD_YEAR=2012.0 -DOPENSCAD_MONTH=01.0 -DOPENSCAD_DAY=28.0 -DOPENSCAD_COMMIT=1202107 -DUSE_PROGRESSWIDGET -DENABLE_CGAL -DENABLE_OPENCSG -DGLEW_STATIC -DBOOST_STATIC -DBOOST_THREAD_USE_LIB -DBoost_USE_STATIC_LIBS -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I'mingw-cross-env/include/eigen2' -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtCore' -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtGui' -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtOpenGL' -I'../mingw-cross-env/usr/i686-pc-mingw32/include' -I'src' -I'/home/brad/code/mingw-cross-env/usr/i686-pc-mingw32/include/ActiveQt' -I'objects' -I'objects' -I'../mingw-cross-env/usr/i686-pc-mingw32/mkspecs/unsupported/win32-g++-4.6-cross' -o objects/CGALRenderer.o src/CGALRenderer.cc

In file included from src/CGAL_renderer.h:30:0,

                 from src/CGALRenderer.cc:37:

src/OGL_helper.h:223:38: error: expected initializer before 'beginCallback'

src/OGL_helper.h:226:38: error: expected initializer before 'endCallback'

src/OGL_helper.h:229:38: error: expected initializer before 'errorCallback'

src/OGL_helper.h:236:38: error: expected initializer before 'vertexCallback'

src/OGL_helper.h:246:38: error: expected initializer before 'combineCallback'

src/CGALRenderer.cc:143:1: error: expected '}' at end of input

src/CGALRenderer.cc:143:1: error: expected '}' at end of input

make[1]: *** [objects/CGALRenderer.o] Error 1

If I switch back to qgl.h, the build succeeds. Apparently there's something needed from qgl.h that's not in GL/gl.h or glew.h?
The Linux build still seems to be working. Any idea how to fix this?

On Sat, Jan 28, 2012 at 10:16 AM, Marius Kintel <[hidden email]> wrote:

On Jan 28, 2012, at 18:13 PM, Pasca Andrei wrote:

> I checked both the binary and the installer and both fail again with the same error. However, both files report the same date and git version as in the previous build - 2012.01.25 git d8ee4bd.

Looks like the wrong version.

> And while we're here - I wonder if the bug and the bug fix affects not only the intersection but also the difference, since also this one can result in empty trees after normalization?

Both should be fixed.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Brad Pitcher
OK, so I managed to get it to compile by including GL/glut.h as well for Windows. I have no idea why that works though, since the compile error isn't one of those helpful messages.

diff --git a/src/OGL_helper.h b/src/OGL_helper.h
index 74f92bf..0a0b606 100644
--- a/src/OGL_helper.h
+++ b/src/OGL_helper.h
@@ -36,6 +36,7 @@
 
 #ifdef _WIN32
 #define CGAL_GLU_TESS_CALLBACK CALLBACK
+#include <GL/glut.h>
 #else
 #define CGAL_GLU_TESS_CALLBACK 
 #endif


On Sat, Jan 28, 2012 at 4:53 PM, Brad Pitcher <[hidden email]> wrote:

It likes like a recent commit (https://github.com/openscad/openscad/commit/1ffcaae04d577619c1956e96bec47008098a2ed7) broke the windows build:

i686-pc-mingw32-g++ -c -pipe -fno-keep-inline-dllexport -fno-strict-aliasing -fpermissive -frounding-math -DEIGEN_DONT_ALIGN -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DOPENSCAD_VERSION=2012.01.28 -DOPENSCAD_YEAR=2012.0 -DOPENSCAD_MONTH=01.0 -DOPENSCAD_DAY=28.0 -DOPENSCAD_COMMIT=1202107 -DUSE_PROGRESSWIDGET -DENABLE_CGAL -DENABLE_OPENCSG -DGLEW_STATIC -DBOOST_STATIC -DBOOST_THREAD_USE_LIB -DBoost_USE_STATIC_LIBS -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I'mingw-cross-env/include/eigen2' -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtCore' -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtGui' -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtOpenGL' -I'../mingw-cross-env/usr/i686-pc-mingw32/include' -I'src' -I'/home/brad/code/mingw-cross-env/usr/i686-pc-mingw32/include/ActiveQt' -I'objects' -I'objects' -I'../mingw-cross-env/usr/i686-pc-mingw32/mkspecs/unsupported/win32-g++-4.6-cross' -o objects/CGALRenderer.o src/CGALRenderer.cc

In file included from src/CGAL_renderer.h:30:0,

                 from src/CGALRenderer.cc:37:

src/OGL_helper.h:223:38: error: expected initializer before 'beginCallback'

src/OGL_helper.h:226:38: error: expected initializer before 'endCallback'

src/OGL_helper.h:229:38: error: expected initializer before 'errorCallback'

src/OGL_helper.h:236:38: error: expected initializer before 'vertexCallback'

src/OGL_helper.h:246:38: error: expected initializer before 'combineCallback'

src/CGALRenderer.cc:143:1: error: expected '}' at end of input

src/CGALRenderer.cc:143:1: error: expected '}' at end of input

make[1]: *** [objects/CGALRenderer.o] Error 1

If I switch back to qgl.h, the build succeeds. Apparently there's something needed from qgl.h that's not in GL/gl.h or glew.h?
The Linux build still seems to be working. Any idea how to fix this?

On Sat, Jan 28, 2012 at 10:16 AM, Marius Kintel <[hidden email]> wrote:

On Jan 28, 2012, at 18:13 PM, Pasca Andrei wrote:

> I checked both the binary and the installer and both fail again with the same error. However, both files report the same date and git version as in the previous build - 2012.01.25 git d8ee4bd.

Looks like the wrong version.

> And while we're here - I wonder if the bug and the bug fix affects not only the intersection but also the difference, since also this one can result in empty trees after normalization?

Both should be fixed.

 -Marius



Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

donbright
imho the problem is that OGL_helper is using gluTessellator, which
needs CALLBACK defined.

under MINGW, windows.h and various other associated include files wind
up defining CALLBACK to be __attribute__((__stdcall__)).

qgl.h includes QtCore/qt_windows.h, which includes windows.h

when you take out qgl.h, but only include glew.h, and gl.h, then
windows.h never gets #included.

glew.h "fakes" windows.h, defines CALLBACK, then undefines it. it
never includes windows.h or windef.h or the rest, and it leaves
CALLBACK undefined, so when you compile OGL_helper.h, the string
"CALLBACK" is just sitting there in your code, "inline void CALLBACK
beginCallback(...", causing the build error you are seeing.

including 'glut.h' will work because under mingw32, glut.h #includes windows.h

imho adding something like this to system-gl.h might work pretty well,
and it will fix problems if someone uses glu callbacks from outside of
OGL_helper.h

#ifdef _WIN32
#include windows.h" // CALLBACK
#endif

-DB

On Sat, Jan 28, 2012 at 9:42 PM, Brad Pitcher <[hidden email]> wrote:

> OK, so I managed to get it to compile by including GL/glut.h as well for
> Windows. I have no idea why that works though, since the compile error isn't
> one of those helpful messages.
>
> diff --git a/src/OGL_helper.h b/src/OGL_helper.h
> index 74f92bf..0a0b606 100644
> --- a/src/OGL_helper.h
> +++ b/src/OGL_helper.h
> @@ -36,6 +36,7 @@
>
>  #ifdef _WIN32
>  #define CGAL_GLU_TESS_CALLBACK CALLBACK
> +#include <GL/glut.h>
>  #else
>  #define CGAL_GLU_TESS_CALLBACK
>  #endif
>
>
> On Sat, Jan 28, 2012 at 4:53 PM, Brad Pitcher <[hidden email]> wrote:
>>
>> It likes like a recent commit
>> (https://github.com/openscad/openscad/commit/1ffcaae04d577619c1956e96bec47008098a2ed7)
>> broke the windows build:
>>
>> i686-pc-mingw32-g++ -c -pipe -fno-keep-inline-dllexport
>> -fno-strict-aliasing -fpermissive -frounding-math -DEIGEN_DONT_ALIGN -O2
>> -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT
>> -DOPENSCAD_VERSION=2012.01.28 -DOPENSCAD_YEAR=2012.0 -DOPENSCAD_MONTH=01.0
>> -DOPENSCAD_DAY=28.0 -DOPENSCAD_COMMIT=1202107 -DUSE_PROGRESSWIDGET
>> -DENABLE_CGAL -DENABLE_OPENCSG -DGLEW_STATIC -DBOOST_STATIC
>> -DBOOST_THREAD_USE_LIB -DBoost_USE_STATIC_LIBS -DQT_NO_DEBUG -DQT_OPENGL_LIB
>> -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT
>> -I'mingw-cross-env/include/eigen2'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtCore'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtGui'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtOpenGL'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/include' -I'src'
>> -I'/home/brad/code/mingw-cross-env/usr/i686-pc-mingw32/include/ActiveQt'
>> -I'objects' -I'objects'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/mkspecs/unsupported/win32-g++-4.6-cross'
>> -o objects/CGALRenderer.o src/CGALRenderer.cc
>>
>> In file included from src/CGAL_renderer.h:30:0,
>>
>>                  from src/CGALRenderer.cc:37:
>>
>> src/OGL_helper.h:223:38: error: expected initializer before
>> 'beginCallback'
>>
>> src/OGL_helper.h:226:38: error: expected initializer before 'endCallback'
>>
>> src/OGL_helper.h:229:38: error: expected initializer before
>> 'errorCallback'
>>
>> src/OGL_helper.h:236:38: error: expected initializer before
>> 'vertexCallback'
>>
>> src/OGL_helper.h:246:38: error: expected initializer before
>> 'combineCallback'
>>
>> src/CGALRenderer.cc:143:1: error: expected '}' at end of input
>>
>> src/CGALRenderer.cc:143:1: error: expected '}' at end of input
>>
>> make[1]: *** [objects/CGALRenderer.o] Error 1
>>
>> If I switch back to qgl.h, the build succeeds. Apparently there's
>> something needed from qgl.h that's not in GL/gl.h or glew.h?
>> The Linux build still seems to be working. Any idea how to fix this?
>>
>> On Sat, Jan 28, 2012 at 10:16 AM, Marius Kintel <[hidden email]> wrote:
>>>
>>>
>>> On Jan 28, 2012, at 18:13 PM, Pasca Andrei wrote:
>>>
>>> > I checked both the binary and the installer and both fail again with
>>> > the same error. However, both files report the same date and git version as
>>> > in the previous build - 2012.01.25 git d8ee4bd.
>>>
>>> Looks like the wrong version.
>>>
>>> > And while we're here - I wonder if the bug and the bug fix affects not
>>> > only the intersection but also the difference, since also this one can
>>> > result in empty trees after normalization?
>>>
>>> Both should be fixed.
>>>
>>>  -Marius
>>>
>>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>

Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Brad Pitcher

I thought it might be something about CALLBACK, I just couldn't see where it was coming from. That sounds like the right assessment and the right fix. I plugged it in and it does compile.

On Sat, Jan 28, 2012 at 8:17 PM, Don Bright <[hidden email]> wrote:
imho the problem is that OGL_helper is using gluTessellator, which
needs CALLBACK defined.

under MINGW, windows.h and various other associated include files wind
up defining CALLBACK to be __attribute__((__stdcall__)).

qgl.h includes QtCore/qt_windows.h, which includes windows.h

when you take out qgl.h, but only include glew.h, and gl.h, then
windows.h never gets #included.

glew.h "fakes" windows.h, defines CALLBACK, then undefines it. it
never includes windows.h or windef.h or the rest, and it leaves
CALLBACK undefined, so when you compile OGL_helper.h, the string
"CALLBACK" is just sitting there in your code, "inline void CALLBACK
beginCallback(...", causing the build error you are seeing.

including 'glut.h' will work because under mingw32, glut.h #includes windows.h

imho adding something like this to system-gl.h might work pretty well,
and it will fix problems if someone uses glu callbacks from outside of
OGL_helper.h

#ifdef _WIN32
#include windows.h" // CALLBACK
#endif

-DB

On Sat, Jan 28, 2012 at 9:42 PM, Brad Pitcher <[hidden email]> wrote:
> OK, so I managed to get it to compile by including GL/glut.h as well for
> Windows. I have no idea why that works though, since the compile error isn't
> one of those helpful messages.
>
> diff --git a/src/OGL_helper.h b/src/OGL_helper.h
> index 74f92bf..0a0b606 100644
> --- a/src/OGL_helper.h
> +++ b/src/OGL_helper.h
> @@ -36,6 +36,7 @@
>
>  #ifdef _WIN32
>  #define CGAL_GLU_TESS_CALLBACK CALLBACK
> +#include <GL/glut.h>
>  #else
>  #define CGAL_GLU_TESS_CALLBACK
>  #endif
>
>
> On Sat, Jan 28, 2012 at 4:53 PM, Brad Pitcher <[hidden email]> wrote:
>>
>> It likes like a recent commit
>> (https://github.com/openscad/openscad/commit/1ffcaae04d577619c1956e96bec47008098a2ed7)
>> broke the windows build:
>>
>> i686-pc-mingw32-g++ -c -pipe -fno-keep-inline-dllexport
>> -fno-strict-aliasing -fpermissive -frounding-math -DEIGEN_DONT_ALIGN -O2
>> -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT
>> -DOPENSCAD_VERSION=2012.01.28 -DOPENSCAD_YEAR=2012.0 -DOPENSCAD_MONTH=01.0
>> -DOPENSCAD_DAY=28.0 -DOPENSCAD_COMMIT=1202107 -DUSE_PROGRESSWIDGET
>> -DENABLE_CGAL -DENABLE_OPENCSG -DGLEW_STATIC -DBOOST_STATIC
>> -DBOOST_THREAD_USE_LIB -DBoost_USE_STATIC_LIBS -DQT_NO_DEBUG -DQT_OPENGL_LIB
>> -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT
>> -I'mingw-cross-env/include/eigen2'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtCore'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtGui'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtOpenGL'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/include' -I'src'
>> -I'/home/brad/code/mingw-cross-env/usr/i686-pc-mingw32/include/ActiveQt'
>> -I'objects' -I'objects'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/mkspecs/unsupported/win32-g++-4.6-cross'
>> -o objects/CGALRenderer.o src/CGALRenderer.cc
>>
>> In file included from src/CGAL_renderer.h:30:0,
>>
>>                  from src/CGALRenderer.cc:37:
>>
>> src/OGL_helper.h:223:38: error: expected initializer before
>> 'beginCallback'
>>
>> src/OGL_helper.h:226:38: error: expected initializer before 'endCallback'
>>
>> src/OGL_helper.h:229:38: error: expected initializer before
>> 'errorCallback'
>>
>> src/OGL_helper.h:236:38: error: expected initializer before
>> 'vertexCallback'
>>
>> src/OGL_helper.h:246:38: error: expected initializer before
>> 'combineCallback'
>>
>> src/CGALRenderer.cc:143:1: error: expected '}' at end of input
>>
>> src/CGALRenderer.cc:143:1: error: expected '}' at end of input
>>
>> make[1]: *** [objects/CGALRenderer.o] Error 1
>>
>> If I switch back to qgl.h, the build succeeds. Apparently there's
>> something needed from qgl.h that's not in GL/gl.h or glew.h?
>> The Linux build still seems to be working. Any idea how to fix this?
>>
>> On Sat, Jan 28, 2012 at 10:16 AM, Marius Kintel <[hidden email]> wrote:
>>>
>>>
>>> On Jan 28, 2012, at 18:13 PM, Pasca Andrei wrote:
>>>
>>> > I checked both the binary and the installer and both fail again with
>>> > the same error. However, both files report the same date and git version as
>>> > in the previous build - 2012.01.25 git d8ee4bd.
>>>
>>> Looks like the wrong version.
>>>
>>> > And while we're here - I wonder if the bug and the bug fix affects not
>>> > only the intersection but also the difference, since also this one can
>>> > result in empty trees after normalization?
>>>
>>> Both should be fixed.
>>>
>>>  -Marius
>>>
>>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: Openscad crash on Intersection()

Brad Pitcher
I just pushed a new Windows snapshot if you want to try it Andrei.

On Sat, Jan 28, 2012 at 9:55 PM, Brad Pitcher <[hidden email]> wrote:

I thought it might be something about CALLBACK, I just couldn't see where it was coming from. That sounds like the right assessment and the right fix. I plugged it in and it does compile.

On Sat, Jan 28, 2012 at 8:17 PM, Don Bright <[hidden email]> wrote:
imho the problem is that OGL_helper is using gluTessellator, which
needs CALLBACK defined.

under MINGW, windows.h and various other associated include files wind
up defining CALLBACK to be __attribute__((__stdcall__)).

qgl.h includes QtCore/qt_windows.h, which includes windows.h

when you take out qgl.h, but only include glew.h, and gl.h, then
windows.h never gets #included.

glew.h "fakes" windows.h, defines CALLBACK, then undefines it. it
never includes windows.h or windef.h or the rest, and it leaves
CALLBACK undefined, so when you compile OGL_helper.h, the string
"CALLBACK" is just sitting there in your code, "inline void CALLBACK
beginCallback(...", causing the build error you are seeing.

including 'glut.h' will work because under mingw32, glut.h #includes windows.h

imho adding something like this to system-gl.h might work pretty well,
and it will fix problems if someone uses glu callbacks from outside of
OGL_helper.h

#ifdef _WIN32
#include windows.h" // CALLBACK
#endif

-DB

On Sat, Jan 28, 2012 at 9:42 PM, Brad Pitcher <[hidden email]> wrote:
> OK, so I managed to get it to compile by including GL/glut.h as well for
> Windows. I have no idea why that works though, since the compile error isn't
> one of those helpful messages.
>
> diff --git a/src/OGL_helper.h b/src/OGL_helper.h
> index 74f92bf..0a0b606 100644
> --- a/src/OGL_helper.h
> +++ b/src/OGL_helper.h
> @@ -36,6 +36,7 @@
>
>  #ifdef _WIN32
>  #define CGAL_GLU_TESS_CALLBACK CALLBACK
> +#include <GL/glut.h>
>  #else
>  #define CGAL_GLU_TESS_CALLBACK
>  #endif
>
>
> On Sat, Jan 28, 2012 at 4:53 PM, Brad Pitcher <[hidden email]> wrote:
>>
>> It likes like a recent commit
>> (https://github.com/openscad/openscad/commit/1ffcaae04d577619c1956e96bec47008098a2ed7)
>> broke the windows build:
>>
>> i686-pc-mingw32-g++ -c -pipe -fno-keep-inline-dllexport
>> -fno-strict-aliasing -fpermissive -frounding-math -DEIGEN_DONT_ALIGN -O2
>> -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT
>> -DOPENSCAD_VERSION=2012.01.28 -DOPENSCAD_YEAR=2012.0 -DOPENSCAD_MONTH=01.0
>> -DOPENSCAD_DAY=28.0 -DOPENSCAD_COMMIT=1202107 -DUSE_PROGRESSWIDGET
>> -DENABLE_CGAL -DENABLE_OPENCSG -DGLEW_STATIC -DBOOST_STATIC
>> -DBOOST_THREAD_USE_LIB -DBoost_USE_STATIC_LIBS -DQT_NO_DEBUG -DQT_OPENGL_LIB
>> -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT
>> -I'mingw-cross-env/include/eigen2'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtCore'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtGui'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/include/QtOpenGL'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/include' -I'src'
>> -I'/home/brad/code/mingw-cross-env/usr/i686-pc-mingw32/include/ActiveQt'
>> -I'objects' -I'objects'
>> -I'../mingw-cross-env/usr/i686-pc-mingw32/mkspecs/unsupported/win32-g++-4.6-cross'
>> -o objects/CGALRenderer.o src/CGALRenderer.cc
>>
>> In file included from src/CGAL_renderer.h:30:0,
>>
>>                  from src/CGALRenderer.cc:37:
>>
>> src/OGL_helper.h:223:38: error: expected initializer before
>> 'beginCallback'
>>
>> src/OGL_helper.h:226:38: error: expected initializer before 'endCallback'
>>
>> src/OGL_helper.h:229:38: error: expected initializer before
>> 'errorCallback'
>>
>> src/OGL_helper.h:236:38: error: expected initializer before
>> 'vertexCallback'
>>
>> src/OGL_helper.h:246:38: error: expected initializer before
>> 'combineCallback'
>>
>> src/CGALRenderer.cc:143:1: error: expected '}' at end of input
>>
>> src/CGALRenderer.cc:143:1: error: expected '}' at end of input
>>
>> make[1]: *** [objects/CGALRenderer.o] Error 1
>>
>> If I switch back to qgl.h, the build succeeds. Apparently there's
>> something needed from qgl.h that's not in GL/gl.h or glew.h?
>> The Linux build still seems to be working. Any idea how to fix this?
>>
>> On Sat, Jan 28, 2012 at 10:16 AM, Marius Kintel <[hidden email]> wrote:
>>>
>>>
>>> On Jan 28, 2012, at 18:13 PM, Pasca Andrei wrote:
>>>
>>> > I checked both the binary and the installer and both fail again with
>>> > the same error. However, both files report the same date and git version as
>>> > in the previous build - 2012.01.25 git d8ee4bd.
>>>
>>> Looks like the wrong version.
>>>
>>> > And while we're here - I wonder if the bug and the bug fix affects not
>>> > only the intersection but also the difference, since also this one can
>>> > result in empty trees after normalization?
>>>
>>> Both should be fixed.
>>>
>>>  -Marius
>>>
>>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad


12