This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Cygwin64] dash segfault


On 2013-03-11 17:46, Corinna Vinschen wrote:
> On Mar 11 17:27, Peter Rosin wrote:
>> On 2013-03-11 15:35, Peter Rosin wrote:
>>> Second, there's the non-crash exit (where dash sometimes exits w/o
>>> triggering error_start, this still happens with -3):
>>>
>>> Basically, this time config.status didn't complete, and the configure
>>> output ended with:
>>>
>>> config.status: creating m4/Makefile
>>> config.status: creating libgii.conf
>>>
>>> but it is expected that it carries on with:
>>>
>>> config.status: creating dist/Makefile
>>> config.status: creating dist/rpm/Makefile
>>> config.status: creating dist/rpm/libgii.spec
>>> config.status: creating config.h
>>> config.status: executing depfiles commands
>>> config.status: executing libtool commands
>>>
>>>
>>> That premature unexplained exit later killed make with:
>>>
>>> ...
>>> Making all in input
>>> make[2]: Entering directory `/cygdrive/c/Cygwin/home/peda/ggi/cyg64/gii/input'
>>> Making all in directx
>>> make[3]: Entering directory `/cygdrive/c/Cygwin/home/peda/ggi/cyg64/gii/input/directx'
>>> Makefile:314: .deps/di.Plo: No such file or directory
>>> Makefile:315: .deps/dxguid.Plo: No such file or directory
>>> Makefile:316: .deps/input.Plo: No such file or directory
>>> ...
>>>
>>> due to the deps not being there.
>>>
>>> This bug is really troublesome, it does not give me a cozy feeling when
>>> scripts only get half-done w/o any notice...
>>
>> [I wrote most of this before you asked me to test some assumption]
>>
>> I have now finally managed to collect the exit status after such
>> a premature exit. Zero (or it might not get propagated back to the
>> calling shell by configure). This time, configure output ended
>> with:
>>
>> checking for as... as
>> checking for dlltool... (cached) dlltool
>> checking for objdump... (cached) objdump
>> checking for objdir... .libs
>>
>> The next expected line (which didn't appear) is:
>>
>> checking if gcc supports -fno-rtti -fno-exceptions... no
>>
>> But it seems to happen more often when configure runs config.status
>> near the end. Oh, right, I sometimes see a fourth class of errors,
> 
> Oh no, please don't.  This is getting confusing since I don't know
> where to start anymore.  Can we try to stick with one error at a time
> please?

Ok, let's call it classes of symptoms then, because I don't know how
to distinguish the different errors if there indeed are more than one
error.

The classes are:

1. crash into gdb, but limited bt info.
2. premature exit, no message, exit code zero (I think).
3. crash into gdb, but failing to attach to process.
4. premature exit, "Segmentation fault", exit code 0 (I think).
5. premature exit, "Hangup", exit code 0 (I think).

Cheers,
Peter


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]