NH
nop head
Tue, Feb 14, 2017 12:32 AM
I built OpenSCAD from source with MSYS2 and noticed it crashes with
infinite recursion but the last snapshot I download gives a recursion
error. This is on Win7 64 but launched from the MSYS2 command line.
I can't launch it with Explorer because it complains that
libgcc_s_seh-1.dll is missing.
Another odd thing is my build says it is OpenSCAD http://www.openscad.org
version 2017.05.02, which is in the future but I built it on 10/02/2017.
Can anybody shed any light of these oddities?
I built OpenSCAD from source with MSYS2 and noticed it crashes with
infinite recursion but the last snapshot I download gives a recursion
error. This is on Win7 64 but launched from the MSYS2 command line.
I can't launch it with Explorer because it complains that
libgcc_s_seh-1.dll is missing.
Another odd thing is my build says it is OpenSCAD <http://www.openscad.org>
version 2017.05.02, which is in the future but I built it on 10/02/2017.
Can anybody shed any light of these oddities?
HL
Hans L
Tue, Feb 14, 2017 1:21 AM
The format is YYYY.MM.DD so in that case it would be the past.
That's still 5 days before you claim to have built it, not sure what
that's about, maybe its something based on the latest commit date
you've pulled from git?
On Mon, Feb 13, 2017 at 6:32 PM, nop head nop.head@gmail.com wrote:
I built OpenSCAD from source with MSYS2 and noticed it crashes with infinite
recursion but the last snapshot I download gives a recursion error. This is
on Win7 64 but launched from the MSYS2 command line.
I can't launch it with Explorer because it complains that libgcc_s_seh-1.dll
is missing.
Another odd thing is my build says it is OpenSCAD version 2017.05.02, which
is in the future but I built it on 10/02/2017.
Can anybody shed any light of these oddities?
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
The format is YYYY.MM.DD so in that case it would be the past.
That's still 5 days before you claim to have built it, not sure what
that's about, maybe its something based on the latest commit date
you've pulled from git?
On Mon, Feb 13, 2017 at 6:32 PM, nop head <nop.head@gmail.com> wrote:
> I built OpenSCAD from source with MSYS2 and noticed it crashes with infinite
> recursion but the last snapshot I download gives a recursion error. This is
> on Win7 64 but launched from the MSYS2 command line.
>
> I can't launch it with Explorer because it complains that libgcc_s_seh-1.dll
> is missing.
>
> Another odd thing is my build says it is OpenSCAD version 2017.05.02, which
> is in the future but I built it on 10/02/2017.
>
> Can anybody shed any light of these oddities?
>
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
HL
Hans L
Tue, Feb 14, 2017 1:23 AM
Agh, I mixed myself up. But YYYY.MM.DD is how its displayed on my
computer. Your date formatting seems to be different, it may be a
locale based setting?
On Mon, Feb 13, 2017 at 7:21 PM, Hans L thehans@gmail.com wrote:
The format is YYYY.MM.DD so in that case it would be the past.
That's still 5 days before you claim to have built it, not sure what
that's about, maybe its something based on the latest commit date
you've pulled from git?
On Mon, Feb 13, 2017 at 6:32 PM, nop head nop.head@gmail.com wrote:
I built OpenSCAD from source with MSYS2 and noticed it crashes with infinite
recursion but the last snapshot I download gives a recursion error. This is
on Win7 64 but launched from the MSYS2 command line.
I can't launch it with Explorer because it complains that libgcc_s_seh-1.dll
is missing.
Another odd thing is my build says it is OpenSCAD version 2017.05.02, which
is in the future but I built it on 10/02/2017.
Can anybody shed any light of these oddities?
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Agh, I mixed myself up. But YYYY.MM.DD is how its displayed on my
computer. Your date formatting seems to be different, it may be a
locale based setting?
On Mon, Feb 13, 2017 at 7:21 PM, Hans L <thehans@gmail.com> wrote:
> The format is YYYY.MM.DD so in that case it would be the past.
>
> That's still 5 days before you claim to have built it, not sure what
> that's about, maybe its something based on the latest commit date
> you've pulled from git?
>
> On Mon, Feb 13, 2017 at 6:32 PM, nop head <nop.head@gmail.com> wrote:
>> I built OpenSCAD from source with MSYS2 and noticed it crashes with infinite
>> recursion but the last snapshot I download gives a recursion error. This is
>> on Win7 64 but launched from the MSYS2 command line.
>>
>> I can't launch it with Explorer because it complains that libgcc_s_seh-1.dll
>> is missing.
>>
>> Another odd thing is my build says it is OpenSCAD version 2017.05.02, which
>> is in the future but I built it on 10/02/2017.
>>
>> Can anybody shed any light of these oddities?
>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
MK
Marius Kintel
Tue, Feb 14, 2017 3:27 AM
On Feb 13, 2017, at 19:32, nop head nop.head@gmail.com wrote:
I built OpenSCAD from source with MSYS2 and noticed it crashes with infinite recursion but the last snapshot I download gives a recursion error. This is on Win7 64 but launched from the MSYS2 command line.
The last snapshot was build using the MXE cross compiler environment, so that’s one reason why the binaries differ.
Could it be that the MXE binary chooses the POSIX code path, while the MSYS2 one chooses Win32, thus hitting a different stack size check?
See here, where we just assume the default stack size on Win32:
https://github.com/openscad/openscad/blob/master/src/PlatformUtils-win.cc#L98
Another odd thing is my build says it is OpenSCAD version 2017.05.02, which is in the future but I built it on 10/02/2017.
We have some ugly code for detecting today’s date on Windows - it’s likely broken:
https://github.com/openscad/openscad/blob/master/version.pri
Ideas/patches for that would be welcome. We don’t have many Windows natives on our team :)
As you can see, the MSYS2 native Windows build could really need some love.
-Marius
> On Feb 13, 2017, at 19:32, nop head <nop.head@gmail.com> wrote:
>
> I built OpenSCAD from source with MSYS2 and noticed it crashes with infinite recursion but the last snapshot I download gives a recursion error. This is on Win7 64 but launched from the MSYS2 command line.
>
The last snapshot was build using the MXE cross compiler environment, so that’s one reason why the binaries differ.
Could it be that the MXE binary chooses the POSIX code path, while the MSYS2 one chooses Win32, thus hitting a different stack size check?
See here, where we just assume the default stack size on Win32:
https://github.com/openscad/openscad/blob/master/src/PlatformUtils-win.cc#L98
> Another odd thing is my build says it is OpenSCAD version 2017.05.02, which is in the future but I built it on 10/02/2017.
>
We have some ugly code for detecting today’s date on Windows - it’s likely broken:
https://github.com/openscad/openscad/blob/master/version.pri
Ideas/patches for that would be welcome. We don’t have many Windows natives on our team :)
As you can see, the MSYS2 native Windows build could really need some love.
-Marius
TP
Torsten Paul
Tue, Feb 14, 2017 7:47 AM
On 02/14/2017 01:32 AM, nop head wrote:
I built OpenSCAD from source with MSYS2 and noticed it crashes
with infinite recursion but the last snapshot I download gives
a recursion error. This is on Win7 64 but launched from the MSYS2
command line.
My first guess would be that the stack size is not set to 8MB
which, I think, is currently hard coded on Windows as the MinGW
build fixes that at link time:
in mingw-cross-env.pri
WINSTACKSIZE = 8388608 # 8MB # github issue 116
QMAKE_CXXFLAGS += -Wl,--stack,$$WINSTACKSIZE
LIBS += -Wl,--stack,$$WINSTACKSIZE
That might be missing in the MSYS2 build (and maybe there is
a way to actually retrieve the stack size).
ciao,
Torsten.
On 02/14/2017 01:32 AM, nop head wrote:
> I built OpenSCAD from source with MSYS2 and noticed it crashes
> with infinite recursion but the last snapshot I download gives
> a recursion error. This is on Win7 64 but launched from the MSYS2
> command line.
>
My first guess would be that the stack size is not set to 8MB
which, I think, is currently hard coded on Windows as the MinGW
build fixes that at link time:
in mingw-cross-env.pri
WINSTACKSIZE = 8388608 # 8MB # github issue 116
QMAKE_CXXFLAGS += -Wl,--stack,$$WINSTACKSIZE
LIBS += -Wl,--stack,$$WINSTACKSIZE
That might be missing in the MSYS2 build (and maybe there is
a way to actually retrieve the stack size).
ciao,
Torsten.
M
MichaelAtOz
Tue, Feb 14, 2017 9:54 AM
I'll have to search back, but I'm pretty sure there is no fixed stack in
Windows (maybe just 64? maybe not) apps, virtual memory just grows.
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Recursion-check-doesn-t-work-in-the-version-I-compiled-myself-tp20421p20429.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I'll have to search back, but I'm pretty sure there is no fixed stack in
Windows (maybe just 64? maybe not) apps, virtual memory just grows.
-----
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
--
View this message in context: http://forum.openscad.org/Recursion-check-doesn-t-work-in-the-version-I-compiled-myself-tp20421p20429.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
NH
nop head
Tue, Feb 14, 2017 10:16 AM
Isn't that the problem the stack limit is trying to solve. If it grows
forever eventually it will bring the machine to it knees and then crash
when it finally runs out of swap space because OpenSCAD doesn't seem to
notice when there is no more memory virtual memory left.
On 14 February 2017 at 09:54, MichaelAtOz oz.at.michael@gmail.com wrote:
I'll have to search back, but I'm pretty sure there is no fixed stack in
Windows (maybe just 64? maybe not) apps, virtual memory just grows.
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the
Public Domain; to the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. Obviously
inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it!
http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/
Recursion-check-doesn-t-work-in-the-version-I-compiled-
myself-tp20421p20429.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Isn't that the problem the stack limit is trying to solve. If it grows
forever eventually it will bring the machine to it knees and then crash
when it finally runs out of swap space because OpenSCAD doesn't seem to
notice when there is no more memory virtual memory left.
On 14 February 2017 at 09:54, MichaelAtOz <oz.at.michael@gmail.com> wrote:
> I'll have to search back, but I'm pretty sure there is no fixed stack in
> Windows (maybe just 64? maybe not) apps, virtual memory just grows.
>
>
>
> -----
> Admin - PM me if you need anything, or if I've done something stupid...
>
> Unless specifically shown otherwise above, my contribution is in the
> Public Domain; to the extent possible under law, I have waived all
> copyright and related or neighbouring rights to this work. Obviously
> inclusion of works of previous authors is not included in the above.
>
> The TPP is no simple “trade agreement.” Fight it!
> http://www.ourfairdeal.org/ time is running out!
> --
> View this message in context: http://forum.openscad.org/
> Recursion-check-doesn-t-work-in-the-version-I-compiled-
> myself-tp20421p20429.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
A
arnholm@arnholm.org
Tue, Feb 14, 2017 10:46 AM
On 2017-02-14 10:54, MichaelAtOz wrote:
I'll have to search back, but I'm pretty sure there is no fixed stack
in
Windows (maybe just 64? maybe not) apps, virtual memory just grows.
I am pretty sure there is a fixed stack size on windows (and probably
other architectures). That is why you can get stack overflow long before
you run out of physical or virtual memory. Stack memory is fixed size,
but heap memory is only limited to the virtual address space. I think
you refer to heap memory.
Try stuff like this in C++ and you will get stack problems:
char buffer[1024*1024];
I guess the stack size depends on the compiler. The MSVC compiler has a
default stack size of 1MB.
Carsten Arnholm
On 2017-02-14 10:54, MichaelAtOz wrote:
> I'll have to search back, but I'm pretty sure there is no fixed stack
> in
> Windows (maybe just 64? maybe not) apps, virtual memory just grows.
I am pretty sure there is a fixed stack size on windows (and probably
other architectures). That is why you can get stack overflow long before
you run out of physical or virtual memory. Stack memory is fixed size,
but heap memory is only limited to the virtual address space. I think
you refer to heap memory.
Try stuff like this in C++ and you will get stack problems:
char buffer[1024*1024];
I guess the stack size depends on the compiler. The MSVC compiler has a
default stack size of 1MB.
Carsten Arnholm
N
nophead
Tue, Feb 14, 2017 3:09 PM
I ran the qmake again and touched openscad.cc to force a recompile and now
the version number is today's date in the correct format, so I have no idea
what went wrong.
It was 5th of Feb when I last ran qmake but my date format has always been
DD/MM/YYYY so I don't see why it would change between then and now.
--
View this message in context: http://forum.openscad.org/Recursion-check-doesn-t-work-in-the-version-I-compiled-myself-tp20421p20434.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I ran the qmake again and touched openscad.cc to force a recompile and now
the version number is today's date in the correct format, so I have no idea
what went wrong.
It was 5th of Feb when I last ran qmake but my date format has always been
DD/MM/YYYY so I don't see why it would change between then and now.
--
View this message in context: http://forum.openscad.org/Recursion-check-doesn-t-work-in-the-version-I-compiled-myself-tp20421p20434.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
MK
Marius Kintel
Tue, Feb 14, 2017 3:51 PM
On Feb 14, 2017, at 10:09, nophead nop.head@gmail.com wrote:
It was 5th of Feb when I last ran qmake but my date format has always been
DD/MM/YYYY so I don't see why it would change between then and now.
Perhaps there is some heuristic somewhere which tries to guess which is MM vs. DD based on the magnitude of the number?
-Marius
> On Feb 14, 2017, at 10:09, nophead <nop.head@gmail.com> wrote:
>
> It was 5th of Feb when I last ran qmake but my date format has always been
> DD/MM/YYYY so I don't see why it would change between then and now.
>
Perhaps there is some heuristic somewhere which tries to guess which is MM vs. DD based on the magnitude of the number?
-Marius
