Re: gcc segfaults compiling python extensions

Re: gcc segfaults compiling python extensions

[Joachim Metz]

> Was there a stackdump file you could have attached?  What happens if you
> remove the -O3 and -O2 for that matter. I find it interesting that
> you're using a 32bit Cygwin on a server that only executes on a 64bit
> CPU.  Does this happen with 64bit Cygwin?  No, then use it instead.

So this does not happen on 64-bit Cygwin. I use both this is part of
CI testing I want to have the code compile on both, or skip the test
scenario.

> So some anomaly in Windows itself was resolved.  Should we really worry
> about such an issue in Cygwin?  Only if Cygwin is using some API that is
> only available in Windows Server 2016 is my POV.

Recent similar failures have me think the issue is still there even on
newer versions of Windows.
https://ci.appveyor.com/project/joachimmetz/libfwsi/build/job/ljhihmejb6xfyaqe

> You could try debugging the failures.  Follow the gcc issue with an
> strace of the processes.  Attach the stackdump file if one was created, etc.

Seeing the issue seems to be still there, when time permits, I'll see
what information I can collect regarding this issue and update this
thread.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: gcc segfaults compiling python extensions

[cyg Simple]

Please do not add me to the addresses directly.  I get the mail from the
list.  Note, if you're not subscribed you should be, I've removed you
from the address lists as well.

On 8/23/2017 3:38 PM, Joachim Metz wrote:
>> Was there a stackdump file you could have attached?  What happens if you
>> remove the -O3 and -O2 for that matter. I find it interesting that
>> you're using a 32bit Cygwin on a server that only executes on a 64bit
>> CPU.  Does this happen with 64bit Cygwin?  No, then use it instead.
> 
> So this does not happen on 64-bit Cygwin. I use both this is part of
> CI testing I want to have the code compile on both, or skip the test
> scenario.
> 
>> So some anomaly in Windows itself was resolved.  Should we really worry
>> about such an issue in Cygwin?  Only if Cygwin is using some API that is
>> only available in Windows Server 2016 is my POV.
> 
> Recent similar failures have me think the issue is still there even on
> newer versions of Windows.
> https://ci.appveyor.com/project/joachimmetz/libfwsi/build/job/ljhihmejb6xfyaqe
> 
>> You could try debugging the failures.  Follow the gcc issue with an
>> strace of the processes.  Attach the stackdump file if one was created, etc.
> 
> Seeing the issue seems to be still there, when time permits, I'll see
> what information I can collect regarding this issue and update this
> thread.
> 

Until you provide more information there is nothing we can do to help you.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

gcc segfaults compiling python extensions

[Joachim Metz]

Hello CygWin maintainers,

I want to report an observation, which might help address a bug.

This issue has been reported in the past in:
https://cygwin.com/ml/cygwin/2014-10/msg00502.html

I recently ran into the same issue:

On AppVeyor [https://ci.appveyor.com/] running Windows Server 2012 R2
With the latest available cygwin 32-bit
[https://github.com/libyal/libfwnt/blob/master/appveyor.yml#L39]

building a Python module for CygWin python (no Windows Python) causes
gcc to SIGSEGV (11)

gcc -fno-strict-aliasing -ggdb -O2 -pipe
-Wimplicit-function-declaration
-fdebug-prefix-map=/usr/src/ports/python2/python2-2.7.13-1.i686/build=/usr/src/debug/python2-2.7.13-1
-fdebug-prefix-map=/usr/src/ports/python2/python2-2.7.13-1.i686/src/Python-2.7.13=/usr/src/debug/python2-2.7.13-1
-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_CONFIG_H=
-DLOCALEDIR="/usr/share/locale" -Iinclude -Icommon -Ilibcerror
-Ilibcthreads -Ilibcdata -Ilibcnotify -Ilibfwnt
-I/usr/include/python2.7 -c libcerror/libcerror_error.c -o
build/temp.cygwin-2.8.2-i686-2.7/libcerror/libcerror_error.o
error: command 'gcc' terminated by signal 11
Running: 'setup.py build' failed

Also see: https://ci.appveyor.com/project/joachimmetz/libfwnt/build/79/job/l1gqocdqoafax0k7


As per: https://cygwin.com/ml/cygwin/2014-10/msg00552.html I switched
to Windows Server 2016 and this indeed does not show the same issue.

I've been tracking this in: https://github.com/libyal/libyal/issues/34

Hope to have sufficiently informed you.

Let me know if you need additional information.

Kind regards,
Joachim

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: gcc segfaults compiling python extensions

[cyg Simple]

On 8/18/2017 1:21 AM, Joachim Metz wrote:
> Hello CygWin maintainers,
> 
> I want to report an observation, which might help address a bug.
> 
> This issue has been reported in the past in:
> https://cygwin.com/ml/cygwin/2014-10/msg00502.html
> 
> I recently ran into the same issue:
> 
> On AppVeyor [https://ci.appveyor.com/] running Windows Server 2012 R2
> With the latest available cygwin 32-bit
> [https://github.com/libyal/libfwnt/blob/master/appveyor.yml#L39]
> 
> building a Python module for CygWin python (no Windows Python) causes
> gcc to SIGSEGV (11)
> 
> gcc -fno-strict-aliasing -ggdb -O2 -pipe
> -Wimplicit-function-declaration
> -fdebug-prefix-map=/usr/src/ports/python2/python2-2.7.13-1.i686/build=/usr/src/debug/python2-2.7.13-1
> -fdebug-prefix-map=/usr/src/ports/python2/python2-2.7.13-1.i686/src/Python-2.7.13=/usr/src/debug/python2-2.7.13-1
> -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_CONFIG_H=
> -DLOCALEDIR="/usr/share/locale" -Iinclude -Icommon -Ilibcerror
> -Ilibcthreads -Ilibcdata -Ilibcnotify -Ilibfwnt
> -I/usr/include/python2.7 -c libcerror/libcerror_error.c -o
> build/temp.cygwin-2.8.2-i686-2.7/libcerror/libcerror_error.o
> error: command 'gcc' terminated by signal 11
> Running: 'setup.py build' failed
> 

Was there a stackdump file you could have attached?  What happens if you
remove the -O3 and -O2 for that matter. I find it interesting that
you're using a 32bit Cygwin on a server that only executes on a 64bit
CPU.  Does this happen with 64bit Cygwin?  No, then use it instead.

> Also see: https://ci.appveyor.com/project/joachimmetz/libfwnt/build/79/job/l1gqocdqoafax0k7
> 
> 
> As per: https://cygwin.com/ml/cygwin/2014-10/msg00552.html I switched
> to Windows Server 2016 and this indeed does not show the same issue.
> 

So some anomaly in Windows itself was resolved.  Should we really worry
about such an issue in Cygwin?  Only if Cygwin is using some API that is
only available in Windows Server 2016 is my POV.

> I've been tracking this in: https://github.com/libyal/libyal/issues/34
> 
> Hope to have sufficiently informed you.
> 
> Let me know if you need additional information.
You could try debugging the failures.  Follow the gcc issue with an
strace of the processes.  Attach the stackdump file if one was created, etc.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple