Re: Random "child_info_fork::abort:"

[Evgeny Grin]

On 13.10.2016 10:11, Evgeny Grin wrote:
> On 12.10.2016 21:45, Evgeny Grin wrote:
>> On 12.10.2016 13:59, Evgeny Grin wrote:
>>> On 12.10.2016 8:59, Brian Inglis wrote:
 On 2016-10-11 15:32, Evgeny Grin wrote:
> I'm using Windows Insider (slow ring, prerelease). After recent update
> to build 14931, cygwin keeps randomly fail on fork. This happens not
> every fork, but frequent enough. Simplest way to trigger it is to run
> mandb.
> At variable delay I got something like
> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to
> different address: parent(0x3FEAB) != child(0x1C)
> Dll name and child address may vary.
> I updated cygwin to latest version, but problem remains.
> Exactly the same problem with Msys2, but additionally from time to time
> I got different error:
> *** fatal error - cygheap base mismatch detected - 0x1802FE408/0x106E408.
> This problem is probably due to

> I set variable CYGWIN=detect_bloda, but nothing is detected.
> What else could I check?

 Run rebase -is to check for DLL conflicts.
 After the update did you run "rebase-trigger full" and setup,
 with NO Cygwin processes running, to remap the system DLLs
 and rebase the Cygwin DLLs?
>>>
>>> Done. No conflicts.
>>> Setup run fine, problem is not solved.
>>>
>>> Observation: Cygwin errors appears more often than Msys2 errors.
>>> Even got initial loading on incorrect address:
>>>
>>> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to
>>> different address: parent(0x19) != child(0x3FB70)
>>>
 It's likely the Insider debug builds dynamically enable/disable
 features and functions or run alternate system DLLs which gather
 info by acting as BLODAs.
 MS can mess around with your systems to enable new stuff (possibly
 in different combinations) and see which systems they cause problems
 on.
 Hopefully they can also dynamically revert new releases causing
 problems.
 Your systems are the canaries for their Continuous Delivery QA.

 Make sure you continously back up any work on those systems and
 don't ignore warnings, especially build expiries (you are meant
 to be allowed 3 reboots after expiry before the buildrefuses
 to boot!)
>>>
>>> Thanks!
>>> Not sure that situation is just "test" or "temporary". I'm using
>>> prerelease track so this can go to release.
>>
>> Additionally tested under VM.
>> Clear install of Windows 10 x64 14931 (US English), VM guest tools and
>> Cygwin x64. First run of man-db - same error.
>> Need new workarounds?
>> Seems that will be in all new builds.
> 
> Same happens with new Windows build 14942.
> Both Cygwin and Msys2 is not usable anymore.
> 
> MS is pushing us to "Ubuntu on Windows"?
> 

When trying to actively use cygwin, got same (as in Msys2) errors:

 *** fatal error - cygheap base mismatch detected - 0x180302408/0x1082408.

Is it because of cygwin.dll loaded on incorrect address?

--
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

Cygwin shell eats Windows exceptions?

[Bill Smith]

Hi,
I'm trying to run my Windows C++ application which has a call to DebugBreak() 
to bring up the popup asking if you want to debug this application or terminate 
it.  If I run the program within Cygwin, the program just exits. 

If I run the application from a Windows command prompt, I get the Windows popup 
that I'm expecting.  It seems that the Cygwin shell is eating exceptions 
(sigsegv or similar signals?).  Is there a way for me to disable this behavior? 
 

--
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: uniq not working

[Felipe Vieira]

On Tue, Oct 11, 2016 at 7:43 AM, Felipe Vieira  wrote:
> Dear mailing list,
>
> the uniq program seems to be faulty on my cygwin:
>
> /tmp » cat u.txt
> 1
> 2
> 3
> 4
> 5
> 1
> 2
> 3
> 6
> 7
> 8
>
>
> /tmp » uniq -c u.txt
>   1 1
>   1 2
>   1 3
>   1 4
>   1 5
>   1 1
>   1 2
>   1 3
>   1 6
>   1 7
>   1 8
>   1
> /tmp »
>
> As you can see it does not eliminate duplicate lines.
> This file was created with vim. Same results if created with windows notepad.
> What am I missing?
>
> Best,

Thanks Csaba.

I have read the manual but did not understand it completely; missed
one word (adjacent) and that changed everything.

Best regards : )

--
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: Cygwin shell eats Windows exceptions?

[Brian Inglis]

On 2016-10-13 08:35, Bill Smith wrote:

I'm trying to run my Windows C++ application which has a call to
DebugBreak() to bring up the popup asking if you want to debug this
application or terminate it. If I run the program within Cygwin, the
program just exits.
If I run the application from a Windows command prompt, I get the
Windows popup that I'm expecting. It seems that the Cygwin shell is
eating exceptions (sigsegv or similar signals?). Is there a way for
me to disable this behavior?


Not giving us much info to go on here - is this a Cygwin, curses,
Cygwin/X, or Windows native app, and what kind of popup is used?
If a Windows native app, is it a console app, or do you run it with
cygstart from Cygwin?
If a Cygwin or X app, have you tried running strace, gdb (or a GUI FE)
on it?
If the latter, please post or attach the results, and attach the
output from cygcheck -svr in a reply.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: Random "child_info_fork::abort:"

[Evgeny Grin]

On 13.10.2016 18:24, Evgeny Grin wrote:
> On 13.10.2016 10:11, Evgeny Grin wrote:
>> On 12.10.2016 21:45, Evgeny Grin wrote:
>>> On 12.10.2016 13:59, Evgeny Grin wrote:
 On 12.10.2016 8:59, Brian Inglis wrote:
> On 2016-10-11 15:32, Evgeny Grin wrote:
>> I'm using Windows Insider (slow ring, prerelease). After recent update
>> to build 14931, cygwin keeps randomly fail on fork. This happens not
>> every fork, but frequent enough. Simplest way to trigger it is to run
>> mandb.
>> At variable delay I got something like
>> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to
>> different address: parent(0x3FEAB) != child(0x1C)
>> Dll name and child address may vary.
>> I updated cygwin to latest version, but problem remains.
>> Exactly the same problem with Msys2, but additionally from time to time
>> I got different error:
>> *** fatal error - cygheap base mismatch detected - 0x1802FE408/0x106E408.
>> This problem is probably due to
>
>> I set variable CYGWIN=detect_bloda, but nothing is detected.
>> What else could I check?
>
> Run rebase -is to check for DLL conflicts.
> After the update did you run "rebase-trigger full" and setup,
> with NO Cygwin processes running, to remap the system DLLs
> and rebase the Cygwin DLLs?

 Done. No conflicts.
 Setup run fine, problem is not solved.

 Observation: Cygwin errors appears more often than Msys2 errors.
 Even got initial loading on incorrect address:

 child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to
 different address: parent(0x19) != child(0x3FB70)

> It's likely the Insider debug builds dynamically enable/disable
> features and functions or run alternate system DLLs which gather
> info by acting as BLODAs.
> MS can mess around with your systems to enable new stuff (possibly
> in different combinations) and see which systems they cause problems
> on.
> Hopefully they can also dynamically revert new releases causing
> problems.
> Your systems are the canaries for their Continuous Delivery QA.
>
> Make sure you continously back up any work on those systems and
> don't ignore warnings, especially build expiries (you are meant
> to be allowed 3 reboots after expiry before the buildrefuses
> to boot!)

 Thanks!
 Not sure that situation is just "test" or "temporary". I'm using
 prerelease track so this can go to release.
>>>
>>> Additionally tested under VM.
>>> Clear install of Windows 10 x64 14931 (US English), VM guest tools and
>>> Cygwin x64. First run of man-db - same error.
>>> Need new workarounds?
>>> Seems that will be in all new builds.
>>
>> Same happens with new Windows build 14942.
>> Both Cygwin and Msys2 is not usable anymore.
>>
>> MS is pushing us to "Ubuntu on Windows"?
>>
> 
> When trying to actively use cygwin, got same (as in Msys2) errors:
> 
>  *** fatal error - cygheap base mismatch detected - 0x180302408/0x1082408.
> 
> Is it because of cygwin.dll loaded on incorrect address?
> 

What I got from strace (typical output):

 649705 [main] mandb 6288 child_info::sync: n 2, waiting for
subproc_ready(0x280) and child process(0x1CC)
   6358 [main] mandb 7888 child_info_fork::abort:
T:\cygwin64\bin\cyggdbm-4.dll: Loaded to different address:
parent(0x1FFFC51) != child(0x15)
--- Process 7888 created
--- Process 7888 loaded C:\Windows\System32\ntdll.dll at 7FFE2FF7
--- Process 7888 loaded C:\Windows\System32\kernel32.dll at 7FFE2D60
--- Process 7888 loaded C:\Windows\System32\KernelBase.dll at
7FFE2C73
--- Process 7888 thread 912 created
--- Process 7888 thread 10792 created
--- Process 7888 loaded T:\cygwin64\bin\cygmandb-2-7-5.dll at
01FFFB8F
--- Process 7888 loaded T:\cygwin64\bin\cygwin1.dll at 00018004
--- Process 7888 loaded T:\cygwin64\bin\cygintl-8.dll at 0003FBB9
--- Process 7888 thread 14024 created
--- Process 7888 loaded T:\cygwin64\bin\cygiconv-2.dll at 0003FBBF
--- Process 7888 loaded T:\cygwin64\bin\cygpipeline-1.dll at
01FFFB47
--- Process 7888 loaded T:\cygwin64\bin\cygman-2-7-5.dll at 01FFFB90
--- Process 7888 loaded T:\cygwin64\bin\cyggdbm-4.dll at 0015
--- Process 7888 loaded T:\cygwin64\bin\cygman-2-7-5.dll at 0017
--- Process 7888 unloaded DLL at 0017
--- Process 7888 loaded T:\cygwin64\bin\cygz.dll at 01FFFACF
--- Process 7888 loaded T:\cygwin64\bin\cyggdbm-4.dll at 01FFFC51
--- Process 7888 unloaded DLL at 01FFFC51
   6358 [main] mandb 7888 child_info_fork::abort:
T:\cygwin64\bin\cyggdbm-4.dll: Loaded to different address:
parent(0x1FFFC51) != child(0x15)
--- Process 7888 thread 14024 exited with status 0x80
--- Process 7888 thread 10144 exited with status 0x80
--- Process 7888 thread 10792 exited with status 0x80

RE: Cygwin shell eats Windows exceptions?

[Bill Smith]

> On 2016-10-13 08:35, Bill Smith wrote:
> > I'm trying to run my Windows C++ application which has a call to
> > DebugBreak() to bring up the popup asking if you want to debug this
> > application or terminate it. If I run the program within Cygwin, the
> > program just exits.
> > If I run the application from a Windows command prompt, I get the
> > Windows popup that I'm expecting. It seems that the Cygwin shell is
> > eating exceptions (sigsegv or similar signals?). Is there a way for me
> > to disable this behavior?
> 
> Not giving us much info to go on here - is this a Cygwin, curses, Cygwin/X, or
> Windows native app, and what kind of popup is used?
> If a Windows native app, is it a console app, or do you run it with cygstart
> from Cygwin?
> If a Cygwin or X app, have you tried running strace, gdb (or a GUI FE) on it?
> If the latter, please post or attach the results, and attach the output from
> cygcheck -svr in a reply.
[Bill Smith] 
Sorry for the lack of info.  This is a Windows native console application.  
Here's the source code:

#include 

int main()
{
  DebugBreak();
}

Compiled it with Visual Studio 2010:

cl debug.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

debug.cpp
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:debug.exe
debug.obj

When you run the application from a Windows command prompt, you get a popup 
similar to:
http://imgur.com/a/VCgeW

It says "debug.exe has stopped working" and it gives you the option of closing 
the program, checking online for a solution, or to debug the program.

From a Cygwin shell, nothing happens.

Another example is to do an access violation (segv) with a program like this:


int main() {
 int* f = 0;

  *f = 1234; 
}

In Cygwin, It'll say "Segmentation Fault" and fail.  In Windows command prompt, 
I get the same popup with the other program which gives me the option to bring 
up the debugger.

Our product is built using the Visual Studio compiler and we do the build & 
test from within a Cygwin shell (c:\cygwin\bin\sh.exe).

I attached the cygcheck -svr output to this email.


Thanks,
--Bill





cygcheck_svr.txt.gz
Description: cygcheck_svr.txt.gz
--
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: Cygwin shell eats Windows exceptions?

[Bill Smith]

> > Sorry for the lack of info.  This is a Windows native console application.
> Here's the source code:
> >
> > #include 
> >
> A "console application" doesn't require windows.h but this isn't the issue.
[Bill Smith] 
Not sure that I understand.  Is your point that because it includes Windows.h, 
it's a GUI application?
I was just following the docs here:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms679297%28v=vs.85%29.aspx?f=255=-2147217396



> The Windows cmd console and the Cygwin console behave differently to the
> exception.  Not a bug, just not what you wanted.
[Bill Smith] 
Ok, understood.

 
> What if you 'cmd.exe /c foo.exe' from the Cygwin shell?  Will the Dialogue
> popup box occur?  If so you can provide a sh script foo to execute the
> foo.exe file.
[Bill Smith] 
Thanks for the suggestion but that doesn't work.  If I try to open a command 
prompt from a Cygwin shell (just type in "cmd"), I get the same behavior where 
I don't see the popup.  If I run "cygstart cmd.exe", then running the program 
from the command prompt will generate the popup.

Re: Random "child_info_fork::abort:"

[Evgeny Grin]

On 13.10.2016 19:58, Evgeny Grin wrote:
> On 13.10.2016 18:24, Evgeny Grin wrote:
> 
> What I got from strace (typical output):
> 
>  649705 [main] mandb 6288 child_info::sync: n 2, waiting for
> subproc_ready(0x280) and child process(0x1CC)
>6358 [main] mandb 7888 child_info_fork::abort:
> T:\cygwin64\bin\cyggdbm-4.dll: Loaded to different address:
> parent(0x1FFFC51) != child(0x15)
> --- Process 7888 created
> --- Process 7888 loaded C:\Windows\System32\ntdll.dll at 7FFE2FF7
> --- Process 7888 loaded C:\Windows\System32\kernel32.dll at 7FFE2D60
> --- Process 7888 loaded C:\Windows\System32\KernelBase.dll at
> 7FFE2C73
> --- Process 7888 thread 912 created
> --- Process 7888 thread 10792 created
> --- Process 7888 loaded T:\cygwin64\bin\cygmandb-2-7-5.dll at
> 01FFFB8F
> --- Process 7888 loaded T:\cygwin64\bin\cygwin1.dll at 00018004
> --- Process 7888 loaded T:\cygwin64\bin\cygintl-8.dll at 0003FBB9
> --- Process 7888 thread 14024 created
> --- Process 7888 loaded T:\cygwin64\bin\cygiconv-2.dll at 0003FBBF
> --- Process 7888 loaded T:\cygwin64\bin\cygpipeline-1.dll at
> 01FFFB47
> --- Process 7888 loaded T:\cygwin64\bin\cygman-2-7-5.dll at 01FFFB90
> --- Process 7888 loaded T:\cygwin64\bin\cyggdbm-4.dll at 0015
> --- Process 7888 loaded T:\cygwin64\bin\cygman-2-7-5.dll at 0017
> --- Process 7888 unloaded DLL at 0017
> --- Process 7888 loaded T:\cygwin64\bin\cygz.dll at 01FFFACF
> --- Process 7888 loaded T:\cygwin64\bin\cyggdbm-4.dll at 01FFFC51
> --- Process 7888 unloaded DLL at 01FFFC51
>6358 [main] mandb 7888 child_info_fork::abort:
> T:\cygwin64\bin\cyggdbm-4.dll: Loaded to different address:
> parent(0x1FFFC51) != child(0x15)
> --- Process 7888 thread 14024 exited with status 0x80
> --- Process 7888 thread 10144 exited with status 0x80
> --- Process 7888 thread 10792 exited with status 0x80
> --- Process 7888 exited with status 0x80
>  663649 [main] mandb 6288 child_info::sync: pid 7888, WFMO returned 1,
> exit_code 0x80, res 0
>  663743 [main] mandb 6288 sig_send: sendsig 0xD8, pid 6288, signal -73,
> its_me 1
>  663771 [main] mandb 6288 sig_send: wakeup 0x2EC
>  663800 [main] mandb 6288 sig_send: Waiting for pack.wakeup 0x2EC
>  663840 [sig] mandb 6288 wait_sig: signalling pack.wakeup 0x2EC
>  663886 [main] mandb 6288 sig_send: returning 0x0 from sending signal -73
> mandb: fork failed: Resource temporarily unavailable
> 
> 
> The cyggdbm-4.dll is loaded two times: at 0x15 and at 0x1FFFC51,
> but for some reason unloaded from 0x1FFFC51.
> This looks like a bug in cygwin.
> 

Incorrect cygwin dll unloaded:

 837063 [main] mandb 5504 child_info::sync: n 2, waiting for
subproc_ready(0x10C) and child process(0x1E4)
--- Process 736 created
--- Process 736 loaded C:\Windows\System32\ntdll.dll at 7FFE2FF7
--- Process 736 loaded C:\Windows\System32\kernel32.dll at 7FFE2D60
--- Process 736 loaded C:\Windows\System32\KernelBase.dll at
7FFE2C73
--- Process 736 thread 8588 created
--- Process 736 thread 14860 created
--- Process 736 loaded T:\cygwin64\bin\cyggdbm-4.dll at 01FFFC51
--- Process 736 thread 10128 created
--- Process 736 loaded T:\cygwin64\bin\cygmandb-2-7-5.dll at
01FFFB8F
--- Process 736 loaded T:\cygwin64\bin\cygiconv-2.dll at 0003FBBF
--- Process 736 loaded T:\cygwin64\bin\cygintl-8.dll at 0003FBB9
--- Process 736 loaded T:\cygwin64\bin\cygpipeline-1.dll at 01FFFB47
--- Process 736 loaded T:\cygwin64\bin\cygman-2-7-5.dll at 01FFFB90
--- Process 736 loaded T:\cygwin64\bin\cygwin1.dll at 00018004
--- Process 736 loaded T:\cygwin64\bin\cygwin1.dll at 00E5
--- Process 736 loaded T:\cygwin64\bin\cygwin1.dll at 019D
--- Process 736 loaded T:\cygwin64\bin\cygwin1.dll at 0141
--- Process 736 loaded T:\cygwin64\bin\cygz.dll at 01FFFACF
--- Process 736 unloaded DLL at 019D
--- Process 736 unloaded DLL at 0141
--- Process 736 unloaded DLL at 00018004
  2 [main] mandb (736) t:\cygwin64\bin\mandb.exe: *** fatal error -
cygheap base mismatch detected - 0x1802FC408/0x110C408.


--
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: Cygwin shell eats Windows exceptions?

[cyg Simple]

On 10/13/2016 1:56 PM, Bill Smith wrote:
> Sorry for the lack of info.  This is a Windows native console application.  
> Here's the source code:
> 
> #include 
> 

A "console application" doesn't require windows.h but this isn't the issue.

> int main()
> {
>   DebugBreak();
> }
> 
> Compiled it with Visual Studio 2010:
> 
> cl debug.cpp
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 
> 80x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> debug.cpp
> Microsoft (R) Incremental Linker Version 10.00.30319.01
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> /out:debug.exe
> debug.obj
> 
> When you run the application from a Windows command prompt, you get a popup 
> similar to:
> http://imgur.com/a/VCgeW
> 
> It says "debug.exe has stopped working" and it gives you the option of 
> closing the program, checking online for a solution, or to debug the program.
> 
> From a Cygwin shell, nothing happens.
> 
> Another example is to do an access violation (segv) with a program like this:
> 
> 
> int main() {
>  int* f = 0;
> 
>   *f = 1234; 
> }
> 
> In Cygwin, It'll say "Segmentation Fault" and fail.  In Windows command 
> prompt, I get the same popup with the other program which gives me the option 
> to bring up the debugger.
> 
> Our product is built using the Visual Studio compiler and we do the build & 
> test from within a Cygwin shell (c:\cygwin\bin\sh.exe).
> 
> I attached the cygcheck -svr output to this email.

The Windows cmd console and the Cygwin console behave differently to the
exception.  Not a bug, just not what you wanted.

What if you 'cmd.exe /c foo.exe' from the Cygwin shell?  Will the
Dialogue popup box occur?  If so you can provide a sh script foo to
execute the foo.exe file.

-- 
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

Re: Cygwin shell eats Windows exceptions?

[Larry Hall (Cygwin)]

On 10/13/2016 03:00 PM, Bill Smith wrote:




What if you 'cmd.exe /c foo.exe' from the Cygwin shell?  Will the Dialogue
popup box occur?  If so you can provide a sh script foo to execute the
foo.exe file.

[Bill Smith]
Thanks for the suggestion but that doesn't work. If I try to open a
command prompt from a Cygwin shell (just type in "cmd"), I get the same
behavior where I don't see the popup. If I run "cygstart cmd.exe", then
running the program from the command prompt will generate the popup.


I believe the heart of your question is whether command-line utilities run
under a Cygwin shell react to a terminal exception the same way as when run
outside the shell.  The answer, as you've found, is no, they don't.  This
is by design and there isn't a "switch" to flip to get around it.  The
point is that on Linux/Unix platforms, command-line utilities do not pop up
windows, or any other kind of UI, which seek user input.  Doing so can
cause scripted processes to appear to "hang" and clutter the desktop.
There was a time, long ago, where Cygwin command line utilities would do
exactly that and the behavior was changed to return the error code and move
on, just as would happen under Linux/Unix.

Hope that helps,

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
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: Cygwin shell eats Windows exceptions?

[Brian Inglis]

On 2016-10-13 11:56, Bill Smith wrote:

On 2016-10-13 08:35, Bill Smith wrote:

I'm trying to run my Windows C++ application which has a call to
DebugBreak() to bring up the popup asking if you want to debug this
application or terminate it. If I run the program within Cygwin, the
program just exits.
If I run the application from a Windows command prompt, I get the
Windows popup that I'm expecting. It seems that the Cygwin shell is
eating exceptions (sigsegv or similar signals?). Is there a way for me
to disable this behavior?


Not giving us much info to go on here - is this a Cygwin, curses, Cygwin/X, or
Windows native app, and what kind of popup is used?
If a Windows native app, is it a console app, or do you run it with cygstart
from Cygwin?
If a Cygwin or X app, have you tried running strace, gdb (or a GUI FE) on it?
If the latter, please post or attach the results, and attach the output from
cygcheck -svr in a reply.

[Bill Smith]
Sorry for the lack of info.  This is a Windows native console application.  
Here's the source code:
#include 
int main()
{
  DebugBreak();
}
Compiled it with Visual Studio 2010:
cl debug.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.
debug.cpp
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.
/out:debug.exe
debug.obj
When you run the application from a Windows command prompt, you get a popup 
similar to:
http://imgur.com/a/VCgeW
It says "debug.exe has stopped working" and it gives you the option of closing 
the program, checking online for a solution, or to debug the program.
From a Cygwin shell, nothing happens.
Another example is to do an access violation (segv) with a program like this:
int main() {
 int* f = 0;
  *f = 1234;
}
In Cygwin, It'll say "Segmentation Fault" and fail.  In Windows command prompt, 
I get the same popup with the other program which gives me the option to bring up the 
debugger.
Our product is built using the Visual Studio compiler and we do the build & 
test from within a Cygwin shell (c:\cygwin\bin\sh.exe).
I attached the cygcheck -svr output to this email.


As it pops up a Windows msgbox, and the process is being run under a pty 
(pseudo-tty) without any window available, that will just fail.
Why not just trap and report any exceptions console style and return an error?

If you need to do interactive debugging, run it under cmd or with cygstart.
If you need the best of both worlds, you can translate your scripts from bash 
to cmd and have the option.

--
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: Cygwin shell eats Windows exceptions?

[Peter Rosin]

On 2016-10-14 00:52, Peter Rosin wrote:
> On 2016-10-13 16:35, Bill Smith wrote:
>> Hi,
>> I'm trying to run my Windows C++ application which has a call to 
>> DebugBreak() to bring up the popup asking if you want to debug this 
>> application or terminate it.  If I run the program within Cygwin, the 
>> program just exits. 
>>
>> If I run the application from a Windows command prompt, I get the Windows 
>> popup that I'm expecting.  It seems that the Cygwin shell is eating 
>> exceptions (sigsegv or similar signals?).  Is there a way for me to disable 
>> this behavior?  
> 
> I believe you want the reverse of this program:
> 
> https://github.com/msysgit/msys/blob/master/winsup/utils/error-mode.c
> 
> error-mode can make the popups go away (getting cygwin behavior
> on msys), but it should be possible to modify it to make the
> popup appear instead. I think...

feeep, should have read my old code before I posted. The program
should fit the bill. My memory is apparently bad but short.

Sorry for the noise.

Cheers,
Peter

--
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: Cygwin shell eats Windows exceptions?

[Peter Rosin]

On 2016-10-13 16:35, Bill Smith wrote:
> Hi,
> I'm trying to run my Windows C++ application which has a call to DebugBreak() 
> to bring up the popup asking if you want to debug this application or 
> terminate it.  If I run the program within Cygwin, the program just exits. 
> 
> If I run the application from a Windows command prompt, I get the Windows 
> popup that I'm expecting.  It seems that the Cygwin shell is eating 
> exceptions (sigsegv or similar signals?).  Is there a way for me to disable 
> this behavior?  

I believe you want the reverse of this program:

https://github.com/msysgit/msys/blob/master/winsup/utils/error-mode.c

error-mode can make the popups go away (getting cygwin behavior
on msys), but it should be possible to modify it to make the
popup appear instead. I think...

Cheers,
Peter


--
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: Random "child_info_fork::abort:"

[Evgeny Grin]

On 12.10.2016 21:45, Evgeny Grin wrote:
> On 12.10.2016 13:59, Evgeny Grin wrote:
>> On 12.10.2016 8:59, Brian Inglis wrote:
>>> On 2016-10-11 15:32, Evgeny Grin wrote:
 I'm using Windows Insider (slow ring, prerelease). After recent update
 to build 14931, cygwin keeps randomly fail on fork. This happens not
 every fork, but frequent enough. Simplest way to trigger it is to run
 mandb.
 At variable delay I got something like
 child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to
 different address: parent(0x3FEAB) != child(0x1C)
 Dll name and child address may vary.
 I updated cygwin to latest version, but problem remains.
 Exactly the same problem with Msys2, but additionally from time to time
 I got different error:
 *** fatal error - cygheap base mismatch detected - 0x1802FE408/0x106E408.
 This problem is probably due to
>>>
 I set variable CYGWIN=detect_bloda, but nothing is detected.
 What else could I check?
>>>
>>> Run rebase -is to check for DLL conflicts.
>>> After the update did you run "rebase-trigger full" and setup,
>>> with NO Cygwin processes running, to remap the system DLLs
>>> and rebase the Cygwin DLLs?
>>
>> Done. No conflicts.
>> Setup run fine, problem is not solved.
>>
>> Observation: Cygwin errors appears more often than Msys2 errors.
>> Even got initial loading on incorrect address:
>>
>> child_info_fork::abort: T:\cygwin64\bin\cygman-2-7-5.dll: Loaded to
>> different address: parent(0x19) != child(0x3FB70)
>>
>>> It's likely the Insider debug builds dynamically enable/disable
>>> features and functions or run alternate system DLLs which gather
>>> info by acting as BLODAs.
>>> MS can mess around with your systems to enable new stuff (possibly
>>> in different combinations) and see which systems they cause problems
>>> on.
>>> Hopefully they can also dynamically revert new releases causing
>>> problems.
>>> Your systems are the canaries for their Continuous Delivery QA.
>>>
>>> Make sure you continously back up any work on those systems and
>>> don't ignore warnings, especially build expiries (you are meant
>>> to be allowed 3 reboots after expiry before the buildrefuses
>>> to boot!)
>>
>> Thanks!
>> Not sure that situation is just "test" or "temporary". I'm using
>> prerelease track so this can go to release.
> 
> Additionally tested under VM.
> Clear install of Windows 10 x64 14931 (US English), VM guest tools and
> Cygwin x64. First run of man-db - same error.
> Need new workarounds?
> Seems that will be in all new builds.

Same happens with new Windows build 14942.
Both Cygwin and Msys2 is not usable anymore.

MS is pushing us to "Ubuntu on Windows"?

--
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: Random "child_info_fork::abort:"

[Brian Inglis]

On 2016-10-13 06:31, Eliot Moss wrote:

On 10/13/2016 8:00 AM, Marco Atzeri wrote:

On 13/10/2016 09:11, Evgeny Grin wrote:

MS is pushing us to "Ubuntu on Windows"?

Interesting. Are we back to the old tactics ?
https://en.wikipedia.org/wiki/AARD_code

I don't see the motivation.  We still buy Windows.
Do you think they'll charge extra for UoW?


Nope - they always need a POSIX subsystem available in some form
in order to satisy US Fed government requirements for mandatory
POSIX compatibility on all systems contract bids, even if few
will ever use that capability on their desktops or servers.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: Random "child_info_fork::abort:"

[Eliot Moss]

On 10/13/2016 8:00 AM, Marco Atzeri wrote:

On 13/10/2016 09:11, Evgeny Grin wrote:



MS is pushing us to "Ubuntu on Windows"?



Interesting. Are we back to the old tactics ?

https://en.wikipedia.org/wiki/AARD_code


I don't see the motivation.  We still buy Windows.
Do you think they'll charge extra for UoW?

Regards - Eliot Moss

--
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: Random "child_info_fork::abort:"

[Marco Atzeri]

On 13/10/2016 09:11, Evgeny Grin wrote:


Additionally tested under VM.
Clear install of Windows 10 x64 14931 (US English), VM guest tools and
Cygwin x64. First run of man-db - same error.
Need new workarounds?
Seems that will be in all new builds.


Same happens with new Windows build 14942.
Both Cygwin and Msys2 is not usable anymore.

MS is pushing us to "Ubuntu on Windows"?



Interesting. Are we back to the old tactics ?

https://en.wikipedia.org/wiki/AARD_code

Regards
Marco


--
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: [ITP] alure 1.2

[Bastian Germann]

Hi,

it's almost 4 weeks since I submitted the package. Is there something
wrong with my email to not be answered? I think, I followed the
Contributor's Guide pretty close.

Is someone willing to review the package?

Regards,
Bastian

2016-09-17 12:28 GMT+02:00 Bastian Germann:
> I have packaged alure and would like to become a maintainer for it.
> alure is available at http://kcat.strangesoft.net/alure.html and MIT/X11
> licensed.
>
> The major GNU/Linux distributions include it in their repositories, e.g.
> Debian: https://packages.debian.org/source/jessie/alure