For a few builds, appveyor is failing for squeak.cog.v3 at final link stage:
i686-w64-mingw32-gcc -mwindows -m32 -mthreads -Wl,--large-address-aware,--export-all-symbols -o build/vm/SqueakUnstripped.exe \ ...snip... collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
https://ci.appveyor.com/project/OpenSmalltalk/vm/history shows it happened since https://ci.appveyor.com/project/OpenSmalltalk/vm/build/1.0.710
The same build pass on linux and osx. The tools shall never crash, bu worse problem I have is that I can't reproduce the segfault in my windows VM, even if updating properly cygwin... Any idea of what's going on?
On Thursday 15 June 2017 03:48 AM, Nicolas Cellier wrote:
i686-w64-mingw32-gcc -mwindows -m32 -mthreads -Wl,--large-address-aware,--export-all-symbols -o build/vm/SqueakUnstripped.exe \ ...snip... collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
Looks like a toolchain bug to me. Collect2 is a utility that creates the init glue code before call to main(). ld tools work with the object files created by previous passes. Failing with a seg fault is a symptom of toolchain defect, possibly triggered by size or number of files being processed.
You may want to try a different (older?) version of gcc toolchain.
More info on collect2 at https://gcc.gnu.org/onlinedocs/gccint/Collect2.html
Regards .. Subbu
2017-06-15 8:35 GMT+02:00 K K Subbu kksubbu.ml@gmail.com:
On Thursday 15 June 2017 03:48 AM, Nicolas Cellier wrote:
i686-w64-mingw32-gcc -mwindows -m32 -mthreads -Wl,--large-address-aware,--export-all-symbols -o build/vm/SqueakUnstripped.exe \ ...snip... collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
Looks like a toolchain bug to me. Collect2 is a utility that creates the init glue code before call to main(). ld tools work with the object files created by previous passes. Failing with a seg fault is a symptom of toolchain defect, possibly triggered by size or number of files being processed.
You may want to try a different (older?) version of gcc toolchain.
More info on collect2 at https://gcc.gnu.org/onlinedocs /gccint/Collect2.html
Regards .. Subbu
Yes, what is troubling is that previous build did succeed with no less .o and .lib files, and that other flavours using the exact same toolchain are succeeding... It has to be something specific to v3, but might as well be triggered by a cygwin upgrade... That's a problem with cygwin, because we can't version the tools easily. If we respect coding standards, the tools should not matter that much in theory, but that's the subtle difference with practice ;)
On 15. Jun 2017, at 06:18, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hi!
The same build pass on linux and osx. The tools shall never crash, bu worse problem I have is that I can't reproduce the segfault in my windows VM, even if updating properly cygwin... Any idea of what's going on?
no specific idea here but I once debugged a pharo-vm issue that seems to exist because of mixing cygwin and mingw. What I found helpful was to use the RDP support of Appveyor to access the build VM. In the end I just installed the version of gcc that didn't crash when passed --version.
2017-06-16 9:00 GMT+02:00 Holger Freyther holger@freyther.de:
On 15. Jun 2017, at 06:18, Nicolas Cellier <nicolas.cellier.aka.nice@
gmail.com> wrote:
Hi!
The same build pass on linux and osx. The tools shall never crash, bu worse problem I have is that I can't
reproduce the segfault in my windows VM, even if updating properly cygwin...
Any idea of what's going on?
no specific idea here but I once debugged a pharo-vm issue that seems to exist because of mixing cygwin and mingw. What I found helpful was to use the RDP support of Appveyor to access the build VM. In the end I just installed the version of gcc that didn't crash when passed --version.
Thanks Holger
That's something to try.
vm-dev@lists.squeakfoundation.org
-
Holger Freyther -
K K Subbu -
Nicolas Cellier