Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating

[JonY via Cygwin]

On 8/18/20 12:20 AM, Ken Brown via Cygwin wrote:
> On 8/17/2020 8:09 PM, JonY via Cygwin wrote:
>> On 8/17/20 8:50 PM, Ken Brown via Cygwin wrote:

 This isn't an issue after all.  The comment I quoted above refers to
 all GCC exceptions, not just STATUS_GCC_THROW.  I'll submit a patch
 after testing.
>>>
>>> I've sent the patch.  The output of the OP's test case is now the same
>>> on 64-bit as on 32-bit:
>>>
>>> $ ./a
>>> terminate called after throwing an instance of 'std::logic_error'
>>>    what():  basic_string::_S_construct null not valid
>>> Aborted (core dumped)
>>>
>>
>> Is the patch on gcc-patches? I'm not seeing it somehow.
> 
> No, it's on cygwin-patches.
> 

OK thanks for working on this.




signature.asc
Description: OpenPGP digital signature
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating

[Ken Brown via Cygwin]

On 8/17/2020 8:09 PM, JonY via Cygwin wrote:

On 8/17/20 8:50 PM, Ken Brown via Cygwin wrote:


This isn't an issue after all.  The comment I quoted above refers to
all GCC exceptions, not just STATUS_GCC_THROW.  I'll submit a patch
after testing.


I've sent the patch.  The output of the OP's test case is now the same
on 64-bit as on 32-bit:

$ ./a
terminate called after throwing an instance of 'std::logic_error'
   what():  basic_string::_S_construct null not valid
Aborted (core dumped)



Is the patch on gcc-patches? I'm not seeing it somehow.


No, it's on cygwin-patches.

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

Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating

[JonY via Cygwin]

On 8/17/20 8:50 PM, Ken Brown via Cygwin wrote:
>>
>> This isn't an issue after all.  The comment I quoted above refers to
>> all GCC exceptions, not just STATUS_GCC_THROW.  I'll submit a patch
>> after testing.
> 
> I've sent the patch.  The output of the OP's test case is now the same
> on 64-bit as on 32-bit:
> 
> $ ./a
> terminate called after throwing an instance of 'std::logic_error'
>   what():  basic_string::_S_construct null not valid
> Aborted (core dumped)
> 

Is the patch on gcc-patches? I'm not seeing it somehow.



signature.asc
Description: OpenPGP digital signature
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

RE: [cygwin] Re: virtual box shares are visible in the window, but not in an ssh session

[Jason Pyeron]

> From: Andrey Repin
> Sent: Monday, August 17, 2020 5:16 PM
> 

> > E: on /cygdrive/e type vboxsharedfolderfs
> > (binary,posix=0,user,noumount,auto)
> 
> Don't map shares to disk letters.
> It's that simple.
> 

> > This is in the remote ssh:
> > $ df
> > Filesystem 1K-blocks Used Available Use% Mounted on
> > C:/cygwin64 51856440 45549844   6306596  88% /
> > D: 4866648666 0 100% /cygdrive/d
> 
> Indeed, logging in via SSH, you get a separate session, in which your drives
> aren't mapped.
> See above, drop this poor habit of mapping them to letters.
> Use UNC paths directly or symlink them at convenient locations.

In my experience it is not that simple, the UNC will still likely have access 
issues, hence my request for tests.

We typically use the fstab to mount them in Cygwin, since things like git 
misbehave with all the slashes. But even then if the user context (due to admin 
or AD) is wonky - no access.

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

Re: virtual box shares are visible in the window, but not in an ssh session

[Andrey Repin]

Greetings, marty leisner!

[ Please do not top-post in this list. ]

> Its a virtual box shared folder -- I'm mapping "src" to /usr/local/src on
> the host system.

> $ df
> Filesystem 1K-blocks  Used Available Use% Mounted on
> C:/cygwin64 51856440  45548104   6308336  88% /
> D: 48666 48666 0 100% /cygdrive/d
> E: 302054400 237185024  64869376  79% /cygdrive/e
> $ mount
> C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin64 on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
> E: on /cygdrive/e type vboxsharedfolderfs
> (binary,posix=0,user,noumount,auto)

Don't map shares to disk letters.
It's that simple.

> $ id
> uid=197609(marty) gid=197609(marty) groups=197609(marty),401408(Medium
> Mandatory Level),545(Users),559(Performance Log
> Users),4(INTERACTIVE),66049(CONSOLE LOGON),11(Authenticated Users),15(This
> Organization),68578(microsoftaccount+martyleis...@yahoo.com),113(Local
> account),4095(CurrentSession),66048(LOCAL),262180(Cloud Account
> Authentication)

> This is in the remote ssh:
> $ df
> Filesystem 1K-blocks Used Available Use% Mounted on
> C:/cygwin64 51856440 45549844   6306596  88% /
> D: 4866648666 0 100% /cygdrive/d

Indeed, logging in via SSH, you get a separate session, in which your drives
aren't mapped.
See above, drop this poor habit of mapping them to letters.
Use UNC paths directly or symlink them at convenient locations.


-- 
With best regards,
Andrey Repin
Tuesday, August 18, 2020 0:13:28

Sorry for my terrible english...

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

Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating

[Ken Brown via Cygwin]

On 8/17/2020 4:40 PM, Ken Brown via Cygwin wrote:

On 8/17/2020 3:06 PM, Ken Brown via Cygwin wrote:

On 8/17/2020 2:13 PM, Corinna Vinschen wrote:

On Aug 17 13:36, Ken Brown via Cygwin wrote:

On 8/16/2020 6:38 PM, Ken Brown via Cygwin wrote:

One further comment, and then I'll shut up


I lied.


...which is ok.


and leave it to people who know what they're talking about: In the
64-bit case, the function _Unwind_RaiseException in libgcc/unwind-seh.c
gets called, and it calls the Win32 function RaiseException as follows:

    RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *));

Then the following comment appears:

    /* The exception handler installed in crt0 will continue any GCC
   exception that reaches there (and isn't marked non-continuable).
   Returning allows the C++ runtime to call std::terminate.  */

Apparently this doesn't actually happen.


I'm beginning to think this is a bug in the Cygwin build of gcc.  The file
unwind-seh.c is compiled on 64-bit Cygwin because __SEH__ is defined.  But
it makes assumptions, such as those in the comment quoted above, that are
not valid on Cygwin.

In fact, if you look at the main exception handler on Cygwin
(exceptions.cc:626), it is clear that the exception code STATUS_GCC_THROW
does not lead to continuation.  It falls under the default case:

 default:
   /* If we don't recognize the exception, we have to assume that
 we are doing structured exception handling, and we let
 something else handle it.  */
   return ExceptionContinueSearch;

[STATUS_GCC_THROW is 0x20474343, which shows up in the gdb output above as
an unknown target exception.]

So it seems to me that either Cygwin's exception handler has to learn to
handle the exception codes defined in unwind-seh.c, or else gcc should be
built with __SEH__ undefined.

JonY, Achim, Corinna, am I missing something?


This stuff isn't really my strong point.  IIUC the above comment correctly,
we might get away with adding another case to the exception handler switch:

   #define STATUS_GCC_THROW 0x20474343
   case STATUS_GCC_THROW:
 return ExceptionContinueExecution;

Did you try that, by any chance?


No, I didn't.  It might well solve the immediate problem of this bug report. 
But then there are two other exception codes that occur in unwind-seh.c that 
we would also have to deal with: STATUS_GCC_UNWIND    and STATUS_GCC_FORCED. 
Someone would have to look at their uses and figure out what, if anything, 
Cygwin should do with them.


This isn't an issue after all.  The comment I quoted above refers to all GCC 
exceptions, not just STATUS_GCC_THROW.  I'll submit a patch after testing.


I've sent the patch.  The output of the OP's test case is now the same on 64-bit 
as on 32-bit:


$ ./a
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct null not valid
Aborted (core dumped)

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

[PATCH] Cygwin: main exception handler (64-bit): continue GCC exceptions

[Ken Brown via Cygwin-patches]

This is necessary in order to be consistent with the following comment
in the definition of _Unwind_RaiseException() in the GCC source file
libgcc/unwind-seh.c:

 The exception handler installed in crt0 will continue any GCC
 exception that reaches there (and isn't marked non-continuable).

Previously we failed to do this and, as a consequence, the C++ runtime
didn't call std::terminate after an unhandled exception.

This fixes the problem reported here:

  https://sourceware.org/pipermail/cygwin/2020-August/245897.html
---
 winsup/cygwin/exceptions.cc | 21 +
 1 file changed, 21 insertions(+)

diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index 0d9e8f70e..f8da7529b 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -647,6 +647,17 @@ exception::handle (EXCEPTION_RECORD *e, exception_list 
*frame, CONTEXT *in,
   if (exit_state || e->ExceptionFlags)
 return ExceptionContinueSearch;
 
+/* From the GCC source file libgcc/unwind-seh.c. */
+#ifdef __x86_64__
+#define STATUS_USER_DEFINED(1U << 29)
+#define GCC_MAGIC  (('G' << 16) | ('C' << 8) | 'C')
+#define GCC_EXCEPTION(TYPE)\
+   (STATUS_USER_DEFINED | ((TYPE) << 24) | GCC_MAGIC)
+#define STATUS_GCC_THROW   GCC_EXCEPTION (0)
+#define STATUS_GCC_UNWIND  GCC_EXCEPTION (1)
+#define STATUS_GCC_FORCED  GCC_EXCEPTION (2)
+#endif
+
   siginfo_t si = {};
   si.si_code = SI_KERNEL;
   /* Coerce win32 value to posix value.  */
@@ -762,6 +773,16 @@ exception::handle (EXCEPTION_RECORD *e, exception_list 
*frame, CONTEXT *in,
 handling.  */
   return ExceptionContinueExecution;
 
+#ifdef __x86_64__
+  /* According to a comment in the GCC function
+_Unwind_RaiseException(), GCC expects us to continue all the
+(continuable) GCC exceptions that reach us. */
+case STATUS_GCC_THROW:
+case STATUS_GCC_UNWIND:
+case STATUS_GCC_FORCED:
+  return ExceptionContinueExecution;
+#endif
+
 default:
   /* If we don't recognize the exception, we have to assume that
 we are doing structured exception handling, and we let
-- 
2.28.0

Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating

[Ken Brown via Cygwin]

On 8/17/2020 3:06 PM, Ken Brown via Cygwin wrote:

On 8/17/2020 2:13 PM, Corinna Vinschen wrote:

On Aug 17 13:36, Ken Brown via Cygwin wrote:

On 8/16/2020 6:38 PM, Ken Brown via Cygwin wrote:

One further comment, and then I'll shut up


I lied.


...which is ok.


and leave it to people who know what they're talking about: In the
64-bit case, the function _Unwind_RaiseException in libgcc/unwind-seh.c
gets called, and it calls the Win32 function RaiseException as follows:

    RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *));

Then the following comment appears:

    /* The exception handler installed in crt0 will continue any GCC
   exception that reaches there (and isn't marked non-continuable).
   Returning allows the C++ runtime to call std::terminate.  */

Apparently this doesn't actually happen.


I'm beginning to think this is a bug in the Cygwin build of gcc.  The file
unwind-seh.c is compiled on 64-bit Cygwin because __SEH__ is defined.  But
it makes assumptions, such as those in the comment quoted above, that are
not valid on Cygwin.

In fact, if you look at the main exception handler on Cygwin
(exceptions.cc:626), it is clear that the exception code STATUS_GCC_THROW
does not lead to continuation.  It falls under the default case:

 default:
   /* If we don't recognize the exception, we have to assume that
 we are doing structured exception handling, and we let
 something else handle it.  */
   return ExceptionContinueSearch;

[STATUS_GCC_THROW is 0x20474343, which shows up in the gdb output above as
an unknown target exception.]

So it seems to me that either Cygwin's exception handler has to learn to
handle the exception codes defined in unwind-seh.c, or else gcc should be
built with __SEH__ undefined.

JonY, Achim, Corinna, am I missing something?


This stuff isn't really my strong point.  IIUC the above comment correctly,
we might get away with adding another case to the exception handler switch:

   #define STATUS_GCC_THROW 0x20474343
   case STATUS_GCC_THROW:
 return ExceptionContinueExecution;

Did you try that, by any chance?


No, I didn't.  It might well solve the immediate problem of this bug report. But 
then there are two other exception codes that occur in unwind-seh.c that we 
would also have to deal with: STATUS_GCC_UNWIND    and STATUS_GCC_FORCED.  
Someone would have to look at their uses and figure out what, if anything, 
Cygwin should do with them.


This isn't an issue after all.  The comment I quoted above refers to all GCC 
exceptions, not just STATUS_GCC_THROW.  I'll submit a patch after testing.


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

Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating

[Ken Brown via Cygwin]

On 8/17/2020 2:13 PM, Corinna Vinschen wrote:

On Aug 17 13:36, Ken Brown via Cygwin wrote:

On 8/16/2020 6:38 PM, Ken Brown via Cygwin wrote:

One further comment, and then I'll shut up


I lied.


...which is ok.


and leave it to people who know what they're talking about: In the
64-bit case, the function _Unwind_RaiseException in libgcc/unwind-seh.c
gets called, and it calls the Win32 function RaiseException as follows:

    RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *));

Then the following comment appears:

    /* The exception handler installed in crt0 will continue any GCC
   exception that reaches there (and isn't marked non-continuable).
   Returning allows the C++ runtime to call std::terminate.  */

Apparently this doesn't actually happen.


I'm beginning to think this is a bug in the Cygwin build of gcc.  The file
unwind-seh.c is compiled on 64-bit Cygwin because __SEH__ is defined.  But
it makes assumptions, such as those in the comment quoted above, that are
not valid on Cygwin.

In fact, if you look at the main exception handler on Cygwin
(exceptions.cc:626), it is clear that the exception code STATUS_GCC_THROW
does not lead to continuation.  It falls under the default case:

 default:
   /* If we don't recognize the exception, we have to assume that
 we are doing structured exception handling, and we let
 something else handle it.  */
   return ExceptionContinueSearch;

[STATUS_GCC_THROW is 0x20474343, which shows up in the gdb output above as
an unknown target exception.]

So it seems to me that either Cygwin's exception handler has to learn to
handle the exception codes defined in unwind-seh.c, or else gcc should be
built with __SEH__ undefined.

JonY, Achim, Corinna, am I missing something?


This stuff isn't really my strong point.  IIUC the above comment correctly,
we might get away with adding another case to the exception handler switch:

   #define STATUS_GCC_THROW 0x20474343
   case STATUS_GCC_THROW:
 return ExceptionContinueExecution;

Did you try that, by any chance?


No, I didn't.  It might well solve the immediate problem of this bug report. 
But then there are two other exception codes that occur in unwind-seh.c that we 
would also have to deal with: STATUS_GCC_UNWIND	and STATUS_GCC_FORCED.  Someone 
would have to look at their uses and figure out what, if anything, Cygwin should 
do with them.


I'd be willing to take a crack at this if no one more knowledgeable steps 
forward.  But keep in mind that I've never looked at the gcc code or Cygwin's 
exception handler until today, so I'm not necessarily the best person to do this.


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

Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating

[Achim Gratz]

Corinna Vinschen writes:
> This stuff isn't really my strong point.  IIUC the above comment correctly,
> we might get away with adding another case to the exception handler switch:
>
>   #define STATUS_GCC_THROW 0x20474343
>   case STATUS_GCC_THROW:
> return ExceptionContinueExecution;
>
> Did you try that, by any chance?

There is a clear expectation that SEH is available on 64bit as expressed
in cygming.h from gcc (but not on 32bit, which explains why there's no
problem there):

#define TARGET_SEH  (TARGET_64BIT_MS_ABI && flag_unwind_tables)

and MS_ABI is the default for 64bit, flag_unwind_tables is a global
variable that is set to 1 by default and very few platforms set it to 0.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Issue in starting the CYGSSHD service

[Bill Stewart]

On Mon, Aug 17, 2020 at 10:37 AM Subramanya Narayanaswamy via Cygwin wrote:

Has anyone faced the same issue I'm facing now ? After installation of
> CYGWIN I tried to run command to start cygsshd in CYGWIN terminal with
> Admin privalages and facing the below error. Any help would be great thanks!
>

Judging from the lack of responses, I would guess that not many are running
into the problem you're having, which is apparently caused by a
configuration problem in your specific cygwin installation.

I would suggest installing a cygwin instance on a different machine and
setting it up per the docs.

Once that's working, compare the configuration files between the one that's
not working and the one that is working.

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

Re: [Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating

[Corinna Vinschen]

On Aug 17 13:36, Ken Brown via Cygwin wrote:
> On 8/16/2020 6:38 PM, Ken Brown via Cygwin wrote:
> > One further comment, and then I'll shut up
> 
> I lied.

...which is ok.

> > and leave it to people who know what they're talking about: In the
> > 64-bit case, the function _Unwind_RaiseException in libgcc/unwind-seh.c
> > gets called, and it calls the Win32 function RaiseException as follows:
> > 
> >    RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *));
> > 
> > Then the following comment appears:
> > 
> >    /* The exception handler installed in crt0 will continue any GCC
> >   exception that reaches there (and isn't marked non-continuable).
> >   Returning allows the C++ runtime to call std::terminate.  */
> > 
> > Apparently this doesn't actually happen.
> 
> I'm beginning to think this is a bug in the Cygwin build of gcc.  The file
> unwind-seh.c is compiled on 64-bit Cygwin because __SEH__ is defined.  But
> it makes assumptions, such as those in the comment quoted above, that are
> not valid on Cygwin.
> 
> In fact, if you look at the main exception handler on Cygwin
> (exceptions.cc:626), it is clear that the exception code STATUS_GCC_THROW
> does not lead to continuation.  It falls under the default case:
> 
> default:
>   /* If we don't recognize the exception, we have to assume that
>we are doing structured exception handling, and we let
>something else handle it.  */
>   return ExceptionContinueSearch;
> 
> [STATUS_GCC_THROW is 0x20474343, which shows up in the gdb output above as
> an unknown target exception.]
> 
> So it seems to me that either Cygwin's exception handler has to learn to
> handle the exception codes defined in unwind-seh.c, or else gcc should be
> built with __SEH__ undefined.
> 
> JonY, Achim, Corinna, am I missing something?

This stuff isn't really my strong point.  IIUC the above comment correctly,
we might get away with adding another case to the exception handler switch:

  #define STATUS_GCC_THROW 0x20474343
  case STATUS_GCC_THROW:
return ExceptionContinueExecution;

Did you try that, by any chance?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[Attn: gcc maintainers] Re: unhandled C++ exceptions not propagating

[Ken Brown via Cygwin]

On 8/16/2020 6:38 PM, Ken Brown via Cygwin wrote:

On 8/16/2020 10:56 AM, Ken Brown via Cygwin wrote:

On 8/16/2020 9:52 AM, Takashi Yano via Cygwin wrote:

On Sun, 16 Aug 2020 09:21:24 -0400
Ken Brown via Cygwin  wrote:

On 8/15/2020 11:53 PM, Takashi Yano via Cygwin wrote:

On Sat, 15 Aug 2020 20:38:01 -0300
David McFarland via Cygwin  wrote:


I was just debugging a c++ app (b2 build system from boost), and noticed
that it would appear to exit unexpectedly without an error.  This turned
out to be when an unhandled C++ exception was thrown.

On a fresh install of cygwin with gcc-g++, this program will throw an
exception from the std::string constructor:

c++ -x c++ - <
int main() { std::string str(nullptr); return 0; }
END

When it's executed from the shell it returns zero, but execution stops
at the exception.

$ ./a; echo $?
0

When executed under gdb, the exception is caught, and the process exits
non-zero when continued:

(gdb) r
Starting program: /home/corngood/a
[New Thread 4300.0x1390]
[New Thread 4300.0x1d24]
[New Thread 4300.0x1d48]
[New Thread 4300.0x80c]
gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799
Thread 1 "a" received signal ?, Unknown signal.
0x7ff8d2cfa799 in RaiseException () from 
/cygdrive/c/WINDOWS/System32/KERNELBASE.dll

(gdb) c
Continuing.
[Thread 4300.0x1d24 exited with code 541541187]
[Thread 4300.0x1870 exited with code 541541187]
[Thread 4300.0x1d48 exited with code 541541187]
[Thread 4300.0x1390 exited with code 541541187]
[Inferior 1 (process 4300) exited with code 04021641503]
(gdb)

When executed under strace, it exits with an error as expected:

$ strace -o /dev/null a; echo $?
67

That's as far as I've investigated so far.


Is this the same issue with
https://cygwin.com/pipermail/cygwin/2019-October/242795.html ?

As far as I tested, this does not occur in 32-bit cygwin.


This doesn't seem to be a new issue.  I found the following report from 6 years
ago, on Cygwin 1.7.30 with GCC 4.9.0:

https://stackoverflow.com/questions/24402412/program-executed-on-cygwin-does-not-report-a-thrown-exception 



Thanks for the information. But I still wonder why 32-bit and 64-bit
cygwin behave differently.


I'm no C++ expert, but my understanding after a brief internet search is that 
an uncaught exception is supposed to cause std::terminate to be called.  So I 
installed gcc-debuginfo and ran the OP's test case under gdb with a breakpoint 
at 'terminate'.  On 32-bit Cygwin I got the expected behavior:


Thread 1 "exception_test" hit Breakpoint 1, std::terminate ()
 at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_terminate.cc:96
96    __atomic_load (&__terminate_handler, , __ATOMIC_ACQUIRE);
(gdb) bt
#0  std::terminate ()
 at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_terminate.cc:96
#1  0x57c45909 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x800396e8,
 tinfo=tinfo@entry=0x57c646a8 ,
 dest=0x57be6c60 )
 at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/libsupc++/eh_throw.cc:95
#2  0x57c49223 in std::__throw_logic_error (
 __s=__s@entry=0x57c60160  
"basic_string::

_S_construct null not valid")
 at /usr/src/debug/gcc-9.3.0-2/libstdc++-v3/src/c++11/functexcept.cc:66
[...]

On 64-bit Cygwin, however, I got the behavior reported by the OP:

gdb: unknown target exception 0x20474343 at 0x7ff8a719

Thread 1 "exception_test" received signal ?, Unknown signal.
0x7ff8a719 in RaiseException () from /c/WINDOWS/System32/KERNELBASE.dll
(gdb) c
Continuing.
[Thread 4508.0x3e20 exited with code 541541187]
[Thread 4508.0x5bc exited with code 541541187]
[Thread 4508.0x5ee8 exited with code 541541187]
[Thread 4508.0x1cd0 exited with code 541541187]
[Inferior 1 (process 4508) exited with code 04021641503]

Note that the breakpoint at 'terminate' is not reached.  I tried putting a 
breakpoint at __cxa_throw and stepping through from there, but I don't really 
understand what's going on.  Someone who knows the innards of exception 
handling will have to look at this.


One further comment, and then I'll shut up


I lied.

and leave it to people who know what 
they're talking about: In the 64-bit case, the function _Unwind_RaiseException 
in libgcc/unwind-seh.c gets called, and it calls the Win32 function 
RaiseException as follows:


   RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *));

Then the following comment appears:

   /* The exception handler installed in crt0 will continue any GCC
  exception that reaches there (and isn't marked non-continuable).
  Returning allows the C++ runtime to call std::terminate.  */

Apparently this doesn't actually happen.


I'm beginning to think this is a bug in the Cygwin build of gcc.  The file 
unwind-seh.c is compiled on 64-bit Cygwin because __SEH__ is defined.  But it 
makes assumptions, such as those in the comment quoted above, that are not valid 
on Cygwin.


In fact, if you look at the main exception handler on Cygwin 
(exceptions.cc:626), it is clear that the exception 

Issue in starting the CYGSSHD service

[Subramanya Narayanaswamy via Cygwin]

Hi Team,

 

Has anyone faced the same issue I'm facing now ? After installation of CYGWIN I 
tried to run command to start cygsshd in CYGWIN terminal with Admin privalages 
and facing the below error. Any help would be great thanks!!

 



 

 



 



 



 

Subramanya

-- 
http://www.oracle.com/
Subramanya Narayanswamy, Staff Consultant, Infrastructure
Mobile: +919900036638
Oracle Consulting | IaaS

Oracle India 

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

Re: [cygwin] Re: virtual box shares are visible in the window, but not in an ssh session

[Eliot Moss]

Indeed Jason has a good point.

IIRC, VBox shares are normally privileged, so if in one case the logged in user has more rights, 
that could explain the difference.  I do see that 'id' reports somewhat different things in the two 
cases, though I am not enough of an expert on Windows users and their permissions to point to the 
"smoking gun" that might cause the difference.


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

Re: virtual box shares are visible in the window, but not in an ssh session

[Eliot Moss]

On 8/17/2020 12:11 PM, marty leisner wrote:

Its a virtual box shared folder -- I'm mapping "src" to /usr/local/src on the 
host system.

$ df
Filesystem     1K-blocks      Used Available Use% Mounted on
C:/cygwin64     51856440  45548104   6308336  88% /
D:                 48666     48666         0 100% /cygdrive/d
E:             302054400 237185024  64869376  79% /cygdrive/e
$ mount
C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin64 on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
E: on /cygdrive/e type vboxsharedfolderfs (binary,posix=0,user,noumount,auto)

$ id
uid=197609(marty) gid=197609(marty) groups=197609(marty),401408(Medium Mandatory 
Level),545(Users),559(Performance Log Users),4(INTERACTIVE),66049(CONSOLE LOGON),11(Authenticated 
Users),15(This Organization),68578(microsoftaccount+martyleis...@yahoo.com 
),113(Local 
account),4095(CurrentSession),66048(LOCAL),262180(Cloud Account Authentication)


This is in the remote ssh:
$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
C:/cygwin64     51856440 45549844   6306596  88% /
D:                 48666    48666         0 100% /cygdrive/d

marty@windows10 ~
$ mount
C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin64 on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)

marty@windows10 ~
$ id
uid=197609(marty) gid=197609(marty) groups=197609(marty),197121(None),114(Local account and member 
of Administrators group),544(Administrators),545(Users),2(NETWORK),11(Authenticated Users),15(This 
Organization),113(Local account),4095(CurrentSession),68578(microsoftaccount+martyleis...@yahoo.com 
),262154(NTLM Authentication),405504(High 
Mandatory Level)


So we see that in the second case, E: is not seen by Cygwin.  Does Windows show it to be mounted?  I 
am wondering if the difference is something about VBox and Windows not mounting E: in the second 
case, or if it is something about Cygwin not picking up on E: even if it _is_ mounted.  In the first 
case, it's not a Cygwin issue, but a Windows/VBox one.  In the second case, it's something about 
Cygwin, and we would want information about what Windows shows about the mounted E: share.


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

RE: [cygwin] Re: virtual box shares are visible in the window, but not in an ssh session

[Jason Pyeron]

> -Original Message-
> From: Eliot Moss
> Sent: Monday, August 17, 2020 12:04 PM
> 
> On 8/17/2020 11:36 AM, marty leisner via Cygwin wrote:
> > This is interesting...
> >
> > I'm running windows 10 in Vbox on linux and use cygwin with a bash shell.
> >
> > When I start my shell on the windows (and if I run konsole to get screen on
> > my xdesktop) I see the virtual box share.
> >
> > But when I ssh in I don't.

Please understand that if the user is an admin, it will be with the highest 
permissions. Also if logging in via PKI instead of password you will have a 
slightly different security token. Is this a an Active Directory joined machine?

> >
> > Not sure why
> 

Please test/demonstrate the following:

Run CMD.exe

dir \\virtual\box\share\folder\

Run CMD as admin

dir \\virtual\box\share\folder\

Run cygterm

ls //virtual/box/share/folder/

Run cygterm as admin

ls //virtual/box/share/folder/

create local user, not in the Administrators group (regular user)

ssh in "your normal way"

id -G
# does it have 544 listed?

ssh in using password

ls //virtual/box/share/folder/

> Dear Marty: I think we (I, anyway) can be more helpful with some more 
> information.
> 
> - What is "the virtual box share" here?

If it is like VMWare, then it is a windows file share provided by a special 
device driver.

If not, it ***MAY*** require some agent to run at user log on.

> 
> - What does "see" mean?  That is, what specific command(s) are you using, and 
> what are the
>outputs you get that lead you to this conclusion?
> 
> - Are we talking about Cygwin bash in both cases?  The same user logged in?

@Marty - please answer Eliot's questions too,


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

Re: virtual box shares are visible in the window, but not in an ssh session

[marty leisner via Cygwin]

Its a virtual box shared folder -- I'm mapping "src" to /usr/local/src on
the host system.

$ df
Filesystem 1K-blocks  Used Available Use% Mounted on
C:/cygwin64 51856440  45548104   6308336  88% /
D: 48666 48666 0 100% /cygdrive/d
E: 302054400 237185024  64869376  79% /cygdrive/e
$ mount
C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin64 on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
E: on /cygdrive/e type vboxsharedfolderfs
(binary,posix=0,user,noumount,auto)

$ id
uid=197609(marty) gid=197609(marty) groups=197609(marty),401408(Medium
Mandatory Level),545(Users),559(Performance Log
Users),4(INTERACTIVE),66049(CONSOLE LOGON),11(Authenticated Users),15(This
Organization),68578(microsoftaccount+martyleis...@yahoo.com),113(Local
account),4095(CurrentSession),66048(LOCAL),262180(Cloud Account
Authentication)

This is in the remote ssh:
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
C:/cygwin64 51856440 45549844   6306596  88% /
D: 4866648666 0 100% /cygdrive/d

marty@windows10 ~
$ mount
C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin64 on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)

marty@windows10 ~
$ id
uid=197609(marty) gid=197609(marty)
groups=197609(marty),197121(None),114(Local account and member of
Administrators
group),544(Administrators),545(Users),2(NETWORK),11(Authenticated
Users),15(This Organization),113(Local account),4095(CurrentSession),68578(
microsoftaccount+martyleis...@yahoo.com),262154(NTLM
Authentication),405504(High Mandatory Level)

marty

On Mon, Aug 17, 2020 at 12:03 PM Eliot Moss  wrote:

> On 8/17/2020 11:36 AM, marty leisner via Cygwin wrote:
> > This is interesting...
> >
> > I'm running windows 10 in Vbox on linux and use cygwin with a bash shell.
> >
> > When I start my shell on the windows (and if I run konsole to get screen
> on
> > my xdesktop) I see the virtual box share.
> >
> > But when I ssh in I don't.
> >
> > Not sure why
>
> Dear Marty: I think we (I, anyway) can be more helpful with some more
> information.
>
> - What is "the virtual box share" here?
>
> - What does "see" mean?  That is, what specific command(s) are you using,
> and what are the
>outputs you get that lead you to this conclusion?
>
> - Are we talking about Cygwin bash in both cases?  The same user logged in?
>
> Regards - Eliot Moss
>
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: virtual box shares are visible in the window, but not in an ssh session

[Eliot Moss]

On 8/17/2020 11:36 AM, marty leisner via Cygwin wrote:

This is interesting...

I'm running windows 10 in Vbox on linux and use cygwin with a bash shell.

When I start my shell on the windows (and if I run konsole to get screen on
my xdesktop) I see the virtual box share.

But when I ssh in I don't.

Not sure why


Dear Marty: I think we (I, anyway) can be more helpful with some more 
information.

- What is "the virtual box share" here?

- What does "see" mean?  That is, what specific command(s) are you using, and 
what are the
  outputs you get that lead you to this conclusion?

- Are we talking about Cygwin bash in both cases?  The same user logged in?

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

virtual box shares are visible in the window, but not in an ssh session

[marty leisner via Cygwin]

This is interesting...

I'm running windows 10 in Vbox on linux and use cygwin with a bash shell.

When I start my shell on the windows (and if I run konsole to get screen on
my xdesktop) I see the virtual box share.

But when I ssh in I don't.

Not sure why

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

Re: [ITP] python-getdevinfo

[Hamish McIntyre-Bhatty via Cygwin-apps]

On 17/08/2020 14:33, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> Hello,
>
> This email signals my intent to package getdevinfo.
>
> (https://www.hamishmb.com/html/downloads.php?program_name=getdevinfo)
> for Cygwin.
>
> getdevinfo is module I wrote for collecting device information, and is a
> dependency for DDRescue-GUI, which I intend to package next if this is
> approved.
>
> Once I have done these things, I intend to improve Cygwin's device
> information detection capabilities and release a further update to make
> this more complete.
>
> If anyone has feedback I'd appreciate it very much.
>
> Hamish McIntyre-Bhatty
>
Forgot link to packages: https://www.hamishmb.com/files/cygwin-temp/


0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

[ITP] python-getdevinfo

[Hamish McIntyre-Bhatty via Cygwin-apps]

Hello,

This email signals my intent to package getdevinfo.

(https://www.hamishmb.com/html/downloads.php?program_name=getdevinfo)
for Cygwin.

getdevinfo is module I wrote for collecting device information, and is a
dependency for DDRescue-GUI, which I intend to package next if this is
approved.

Once I have done these things, I intend to improve Cygwin's device
information detection capabilities and release a further update to make
this more complete.

If anyone has feedback I'd appreciate it very much.

Hamish McIntyre-Bhatty





0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: BIM Modeling Services !!!

[Jeff Johnson via Cygwin]

Hello,

 

Hope you are doing well.  

 

Our company specializes in BIM modeling services (Tender, Permit,
Construction & GFC sets). Please let us know if you are interested in
getting any BIM, Modeling or 2D/3D drafting work done.   

 

Look forward.

 

Thanks,

Jeff

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

RE: Developing for Cygwin from POSIX host

[Hamish McIntyre-Bhatty via Cygwin]

So I reported that it doesn't work on WineHQ, and there was a helpful comment 
that suggests recompiling WINE with a patch can get it working.

Here are the links, hopefully this isn't too late to be useful:

Bug report: https://bugs.winehq.org/show_bug.cgi?id=48891
Patch: https://bugs.winehq.org/attachment.cgi?id=67113=diff

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] Cygwin: pty: Change the timing of set_locale() call again.

[Corinna Vinschen]

On Aug 15 12:23, Takashi Yano via Cygwin-patches wrote:
> - After commit 095972ce5b1d319915501a7e381802914bed790c, charset
>   conversion in mintty is broken if charset is set to other than
>   UTF-8. This seems to be caused because mintty does not set locale
>   yet at fork() call. This patch changes the timing of set_locale()
>   call again to avoid this issue.
> ---
>  winsup/cygwin/fhandler_tty.cc | 10 ++
>  winsup/cygwin/spawn.cc| 12 
>  2 files changed, 18 insertions(+), 4 deletions(-)

Pushed.


Thanks,
Corinna

Re: Requesting a Python 3.8 build of python-bs4

[Hamish McIntyre-Bhatty via Cygwin-apps]

On 15/08/2020 16:35, Marco Atzeri via Cygwin-apps wrote:
> On 15.08.2020 15:32, Achim Gratz wrote:
>> Hamish McIntyre-Bhatty via Cygwin-apps writes:
>>> Who currently maintains python-bs4?
>>
>> Yaakov.  You can find out for yourself by looking at cygwin-pkg-maint on
>> the server.
>>
>>
>> Regards,
>> Achim.
>>
>
>
> Pratically all Yaakov packages are for adoption.
>
> Hamish,
> I will look on python-bs4
>
> Regards
> Marco
>
Thank you Marco :)

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature