Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Sat, 3 Feb 2024 at 19:25, Corinna Vinschen wrote: > > Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we > > want them to do. I just tested this myself with a modified Cygwin DLL > > (code below) and it turns out that the child process error mode is > > the same as the parent's process error mode. Changing the thread > > error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS | > > SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect. > > [...etc.] Oh dear, what a mess! > MSYS2 has introduced the environment variable option CYGWIN=winjitdebug. > I backported this patch now. So default is back to propagating Cygwin's > error mode and if you want to reset the error mode of a non-Cygwin child > process back to OS default, just set the option, for instance, like > this: > > $ CYGWIN=winjitdebug env > > This patch will be in Cygwin 3.5.1. For the time being, it will be > available in the next test release cygwin-3.6.0-0.28.g918c3eda4176 as > well. This completely fixes it for us, thank you very much Thanks, David -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Feb 3 13:39, Corinna Vinschen via Cygwin wrote: > On Feb 2 19:51, Corinna Vinschen via Cygwin wrote: > > On Feb 2 18:22, Corinna Vinschen via Cygwin wrote: > > > On Feb 2 14:56, David Allsopp via Cygwin wrote: > > > > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote: > > > > > Is it actually a safe bet that the error mode set by > > > > > SetThreadErrorMode > > > > > is then propagated as process error mode to the child process? > > > > > > > > > > I have to ask that because Microsoft conveniently forgot to document > > > > > this scenario in the MSDN docs. > > > > > > > > :o) Never knowingly clear, are they! It would seem to be the intent of > > > > SetThreadErrorMode that it would behave that way but who knows. > > > > > > > > Happy to set up a quick experiment to check that it does work (i.e. > > > > [...] > > > Wanna try this? > > [...] > > However, it occured to me that this won't work at all. > > [...] > > Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we > want them to do. I just tested this myself with a modified Cygwin DLL > (code below) and it turns out that the child process error mode is > the same as the parent's process error mode. Changing the thread > error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS | > SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect. > [...etc.] MSYS2 has introduced the environment variable option CYGWIN=winjitdebug. I backported this patch now. So default is back to propagating Cygwin's error mode and if you want to reset the error mode of a non-Cygwin child process back to OS default, just set the option, for instance, like this: $ CYGWIN=winjitdebug env This patch will be in Cygwin 3.5.1. For the time being, it will be available in the next test release cygwin-3.6.0-0.28.g918c3eda4176 as well. HTH, Corinna -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Fri, 2 Feb 2024, Corinna Vinschen wrote: > On Feb 2 09:43, David Allsopp via Cygwin wrote: > > However, this patch came from MSYS2, and subsequently they seem to > > have found it problematic for the same reason as me > > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) > > and have just recently reintroduced the flag > > (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) > > to control it. > > > > The reasoning in > > https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as > > valid now as it did in 2006. > > > > Is it possible to revisit having the flag, or even just reverting the > > behaviour? > > > > I'm sympathetic, and personally I would prefer to revert the patch and > stick to SEM_FAILCRITICALERRORS by default. > > The question is this: Why does, apparently, everybody expect Cygwin to > do the "right thing", with different definitions of "right", when in > fact the executable in question can easily call SetErrorMode by itself? The different definitions of "right" is the reason the flag/option was re-added in MSYS2. I think the most "right" thing Cygwin could do (if it were to only do one thing, rather than having an option) would be to somehow have native processes inherit the error mode as though Cygwin were not in the mix. The issue with that, as you've seen, is that there are any number of Cygwin processes in the hierarchy. As far as the executable being able to call SetErrorMode itself, that would be OK except for when the error is coming from the loader, before anything from the executable is run (such as for missing DLL or missing export from DLL). I do like the idea of a native Windows program like "nohup" that sets the error mode and then runs a subprocess. Why doesn't Windows come with something like that? ;) -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Feb 2 19:51, Corinna Vinschen via Cygwin wrote: > On Feb 2 18:22, Corinna Vinschen via Cygwin wrote: > > On Feb 2 14:56, David Allsopp via Cygwin wrote: > > > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote: > > > > Is it actually a safe bet that the error mode set by SetThreadErrorMode > > > > is then propagated as process error mode to the child process? > > > > > > > > I have to ask that because Microsoft conveniently forgot to document > > > > this scenario in the MSDN docs. > > > > > > :o) Never knowingly clear, are they! It would seem to be the intent of > > > SetThreadErrorMode that it would behave that way but who knows. > > > > > > Happy to set up a quick experiment to check that it does work (i.e. > > > [...] > > Wanna try this? > [...] > However, it occured to me that this won't work at all. > [...] Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we want them to do. I just tested this myself with a modified Cygwin DLL (code below) and it turns out that the child process error mode is the same as the parent's process error mode. Changing the thread error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect. Check the below Cygwin patch and look at output ("gem" is my MingW test app just printing the process error mode retrieved via GetErrorMode): $ ./gem 0 [main] dash 990 child_info_spawn::worker: 1 = SetThreadErrorMode (0, 0) GT:0 GP:3 16158 [main] dash 990 child_info_spawn::worker: 1 = SetThreadErrorMode (3, 0) Error mode 0x3 $ The terrible thing here is the output of the old thread error mode from GetThreadErrorMode as well as from SetThreadErrorMode. MSDN says: Each process has an associated error mode that indicates to the system how the application is going to respond to serious errors. A thread inherits the error mode of the process in which it is running. To retrieve the process error mode, use the GetErrorMode function. To retrieve the error mode of the calling thread, use the GetThreadErrorMode function. What that means is, even though the process error mode is 3 , and even though "A thread inherits the error mode of the process in which it is running", GetThreadErrorMode/SetThreadErrorMode return a thread error code of 0!!! So if GetThreadErrorMode returns 0, you *have* to call GetErrorMode to retrieve the *actual* thread error mode, because the thread error mode just says "yo man, it's default". In extension this probably *also* means, setting the thread error mode to 0 does NOT mean "set it to system default" as MSDN claims, but it means "set it to process default". But in fact, even if I set a non-0 thread error mode, this has no effect on the child process. I forced the thread error mode to 1 before calling CreateProcess, and the resulting child process error mode was still the Cygwin process error mode 3. Isn't that completely screwed up? Ok, my Cygwin DLL test patch follows below. Corinna diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc index a40129c22232..14ba4e3769f1 100644 --- a/winsup/cygwin/dcrt0.cc +++ b/winsup/cygwin/dcrt0.cc @@ -718,7 +718,8 @@ dll_crt0_0 () init_windows_system_directory (); initial_env (); - SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX); + UINT proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS + | SEM_NOGPFAULTERRORBOX); lock_process::init (); user_data->impure_ptr = _impure_ptr; @@ -738,6 +739,13 @@ dll_crt0_0 () if (!child_proc_info) { setup_cygheap (); + /* Memorize the original error mode when this Cygwin process +has been called from a non-Cygwin process. We restore to +this error mode on spawning a non-Cygwin process. This allows +to set a non-default error mode prior to calling the first +Cygwin process and forward it to any subsequent non-Cygwin +child process at spawn time. */ + cygheap->orig_proc_error_mode = proc_error_mode; memory_init (); } else diff --git a/winsup/cygwin/local_includes/cygheap.h b/winsup/cygwin/local_includes/cygheap.h index b6acdf7f18b7..02e3cb4621e3 100644 --- a/winsup/cygwin/local_includes/cygheap.h +++ b/winsup/cygwin/local_includes/cygheap.h @@ -517,6 +517,7 @@ struct init_cygheap: public mini_cygheap mode_t umask; LONG rlim_as_id; unsigned long rlim_core; + UINT orig_proc_error_mode; /* Set when started from non-Cygwin process */ HANDLE console_h; cwdstuff cwd; dtable fdtab; diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc index 8a2db5cf72e2..85dbec431b28 100644 --- a/winsup/cygwin/spawn.cc +++ b/winsup/cygwin/spawn.cc @@ -401,13 +401,6 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv, c_flags |= CREATE_SEPARATE_WOW_VDM | CREATE_UNICODE_ENVIRONMENT; - /* Add CREATE_DEFAULT_ERROR_MODE flag for non-Cygwin processes so they -
Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Feb 2 18:22, Corinna Vinschen via Cygwin wrote: > On Feb 2 14:56, David Allsopp via Cygwin wrote: > > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote: > > > On Feb 2 13:35, David Allsopp via Cygwin wrote: > > > > Not really suggesting it be done this way (it feels more complicated > > > > than just reverting the change), but in some ways perhaps Cygwin > > > > should be using GetErrorMode on startup and instead of not inheriting > > > > it, ensuring that it sets whatever it received? i.e. just before the > > > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the > > > > error mode (for that thread only) to the value read at startup, calls > > > > CreateProcess and then sets the error mode back. > > > > > > This sounds like a good ide, but... > > > > > > Is it actually a safe bet that the error mode set by SetThreadErrorMode > > > is then propagated as process error mode to the child process? > > > > > > I have to ask that because Microsoft conveniently forgot to document > > > this scenario in the MSDN docs. > > > > :o) Never knowingly clear, are they! It would seem to be the intent of > > SetThreadErrorMode that it would behave that way but who knows. > > > > Happy to set up a quick experiment to check that it does work (i.e. > > the invoked process has GetErrorMode set as expected) and that there's > > no possible race between two threads in the calling process with > > differing values (i.e. that having SEM_FAILCRITICALERRORS in one > > thread and not in another behaves as expected. If it does appear to > > work consistently, would you be willing to go down this route? Happy > > to do the patch, although it'd be very helpful to have a couple of > > pointers: I'm guessing the value would want to be captured just before > > the one place where SetErrorMode is already called, but in which > > structure should it then be stashed away to be reused in spawn? > > Wanna try this? It ignores the case of starting a process > under another user account for now, but that can be added easily > if this proves to work as expected. During dinner it occured to me that I forgot to remove setting the default error mode via CreateProcess. So this patch would have to be applied as well: diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc index 8a2db5cf72e2..2e0f0fcf2146 100644 --- a/winsup/cygwin/spawn.cc +++ b/winsup/cygwin/spawn.cc @@ -401,13 +401,6 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv, c_flags |= CREATE_SEPARATE_WOW_VDM | CREATE_UNICODE_ENVIRONMENT; - /* Add CREATE_DEFAULT_ERROR_MODE flag for non-Cygwin processes so they -get the default error mode instead of inheriting the mode Cygwin -uses. This allows things like Windows Error Reporting/JIT debugging -to work with processes launched from a Cygwin shell. */ - if (!real_path.iscygexec ()) - c_flags |= CREATE_DEFAULT_ERROR_MODE; - /* We're adding the CREATE_BREAKAWAY_FROM_JOB flag here to workaround issues with the "Program Compatibility Assistant (PCA) Service". For some reason, when starting long running sessions from mintty(*), However, it occured to me that this won't work at all. Consider fork/exec. In Windows terms, the forked process is a child process started with CreateProcess. The forked child is a Cygwin process, so at DLL init time, it sets orig_proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX); However, given the parent is always a Cygwin parent, orig_proc_error_mode will always be SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX. The following exec starting a non-Cygwin process will set the thread error mode to the above value. So any non-Cygwin process started from your typical Cygwin process like bash, will always have the error mode set to the same mode as any Cygwin application. Ultimately this means, the effect is the same as if we had just reverted commit 21ec498d7f912 ("cygwin: use CREATE_DEFAULT_ERROR_MODE in spawn"). Corinna -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Feb 2 14:56, David Allsopp via Cygwin wrote: > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote: > > On Feb 2 13:35, David Allsopp via Cygwin wrote: > > > Not really suggesting it be done this way (it feels more complicated > > > than just reverting the change), but in some ways perhaps Cygwin > > > should be using GetErrorMode on startup and instead of not inheriting > > > it, ensuring that it sets whatever it received? i.e. just before the > > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the > > > error mode (for that thread only) to the value read at startup, calls > > > CreateProcess and then sets the error mode back. > > > > This sounds like a good ide, but... > > > > Is it actually a safe bet that the error mode set by SetThreadErrorMode > > is then propagated as process error mode to the child process? > > > > I have to ask that because Microsoft conveniently forgot to document > > this scenario in the MSDN docs. > > :o) Never knowingly clear, are they! It would seem to be the intent of > SetThreadErrorMode that it would behave that way but who knows. > > Happy to set up a quick experiment to check that it does work (i.e. > the invoked process has GetErrorMode set as expected) and that there's > no possible race between two threads in the calling process with > differing values (i.e. that having SEM_FAILCRITICALERRORS in one > thread and not in another behaves as expected. If it does appear to > work consistently, would you be willing to go down this route? Happy > to do the patch, although it'd be very helpful to have a couple of > pointers: I'm guessing the value would want to be captured just before > the one place where SetErrorMode is already called, but in which > structure should it then be stashed away to be reused in spawn? Wanna try this? It ignores the case of starting a process under another user account for now, but that can be added easily if this proves to work as expected. diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc index a40129c22232..f1017e69b6b2 100644 --- a/winsup/cygwin/dcrt0.cc +++ b/winsup/cygwin/dcrt0.cc @@ -718,7 +718,8 @@ dll_crt0_0 () init_windows_system_directory (); initial_env (); - SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX); + orig_proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS + | SEM_NOGPFAULTERRORBOX); lock_process::init (); user_data->impure_ptr = _impure_ptr; diff --git a/winsup/cygwin/globals.cc b/winsup/cygwin/globals.cc index 885ada85e7b8..d2861ba98b42 100644 --- a/winsup/cygwin/globals.cc +++ b/winsup/cygwin/globals.cc @@ -28,6 +28,7 @@ PWCHAR windows_directory = windows_directory_buf + 4; UINT windows_directory_length; UNICODE_STRING windows_directory_path; WCHAR global_progname[NT_MAX_PATH]; +UINT orig_proc_error_mode; /* program exit the program */ diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc index 8a2db5cf72e2..df83f25d13c6 100644 --- a/winsup/cygwin/spawn.cc +++ b/winsup/cygwin/spawn.cc @@ -648,6 +648,10 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv, && !::cygheap->user.groups.issetgroups () && !::cygheap->user.setuid_to_restricted)) { + UINT orig_thread_error_mode = SEM_FAILCRITICALERRORS + | SEM_NOGPFAULTERRORBOX; + if (!iscygwin ()) + SetThreadErrorMode (orig_proc_error_mode, _thread_error_mode); rc = CreateProcessW (runpath, /* image name w/ full path */ cmd.wcs (wcmd), /* what was passed to exec */ sa, /* process security attrs */ @@ -658,6 +662,8 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv, NULL, , ); + if (!iscygwin ()) + SetThreadErrorMode (orig_thread_error_mode, NULL); } else { -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote: > > On Feb 2 13:35, David Allsopp via Cygwin wrote: > > Jon Turney via Cygwin wrote: > > > > > > I'm sympathetic, and personally I would prefer to revert the patch and > > > > stick to SEM_FAILCRITICALERRORS by default. > > > > > > > > The question is this: Why does, apparently, everybody expect Cygwin to > > > > do the "right thing", with different definitions of "right", when in > > > > fact the executable in question can easily call SetErrorMode by itself? > > > > > > Yeah, if cygwin wasn't involved in the process ancestry, how would you > > > get the behaviour you want? > > > > Ah, but that's how I hit this (and started digging further) - > > precisely because the non-Cygwin program I'm using _has_ called > > SetErrorMode and its direct calls to the faulty program _are_ doing > > what's wanted (no popup dialog) but the calls which happen via Cygwin > > are then torching that preference. > > > > Not really suggesting it be done this way (it feels more complicated > > than just reverting the change), but in some ways perhaps Cygwin > > should be using GetErrorMode on startup and instead of not inheriting > > it, ensuring that it sets whatever it received? i.e. just before the > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the > > error mode (for that thread only) to the value read at startup, calls > > CreateProcess and then sets the error mode back. > > This sounds like a good ide, but... > > Is it actually a safe bet that the error mode set by SetThreadErrorMode > is then propagated as process error mode to the child process? > > I have to ask that because Microsoft conveniently forgot to document > this scenario in the MSDN docs. :o) Never knowingly clear, are they! It would seem to be the intent of SetThreadErrorMode that it would behave that way but who knows. Happy to set up a quick experiment to check that it does work (i.e. the invoked process has GetErrorMode set as expected) and that there's no possible race between two threads in the calling process with differing values (i.e. that having SEM_FAILCRITICALERRORS in one thread and not in another behaves as expected. If it does appear to work consistently, would you be willing to go down this route? Happy to do the patch, although it'd be very helpful to have a couple of pointers: I'm guessing the value would want to be captured just before the one place where SetErrorMode is already called, but in which structure should it then be stashed away to be reused in spawn? David -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Feb 2 13:35, David Allsopp via Cygwin wrote: > Jon Turney via Cygwin wrote: > > > > I'm sympathetic, and personally I would prefer to revert the patch and > > > stick to SEM_FAILCRITICALERRORS by default. > > > > > > The question is this: Why does, apparently, everybody expect Cygwin to > > > do the "right thing", with different definitions of "right", when in > > > fact the executable in question can easily call SetErrorMode by itself? > > > > Yeah, if cygwin wasn't involved in the process ancestry, how would you > > get the behaviour you want? > > Ah, but that's how I hit this (and started digging further) - > precisely because the non-Cygwin program I'm using _has_ called > SetErrorMode and its direct calls to the faulty program _are_ doing > what's wanted (no popup dialog) but the calls which happen via Cygwin > are then torching that preference. > > Not really suggesting it be done this way (it feels more complicated > than just reverting the change), but in some ways perhaps Cygwin > should be using GetErrorMode on startup and instead of not inheriting > it, ensuring that it sets whatever it received? i.e. just before the > call to CreateProcess for a non-Cygwin binary, Cygwin restores the > error mode (for that thread only) to the value read at startup, calls > CreateProcess and then sets the error mode back. This sounds like a good ide, but... Is it actually a safe bet that the error mode set by SetThreadErrorMode is then propagated as process error mode to the child process? I have to ask that because Microsoft conveniently forgot to document this scenario in the MSDN docs. Corinna -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
Jon Turney via Cygwin wrote: > > I'm sympathetic, and personally I would prefer to revert the patch and > > stick to SEM_FAILCRITICALERRORS by default. > > > > The question is this: Why does, apparently, everybody expect Cygwin to > > do the "right thing", with different definitions of "right", when in > > fact the executable in question can easily call SetErrorMode by itself? > > Yeah, if cygwin wasn't involved in the process ancestry, how would you > get the behaviour you want? Ah, but that's how I hit this (and started digging further) - precisely because the non-Cygwin program I'm using _has_ called SetErrorMode and its direct calls to the faulty program _are_ doing what's wanted (no popup dialog) but the calls which happen via Cygwin are then torching that preference. Not really suggesting it be done this way (it feels more complicated than just reverting the change), but in some ways perhaps Cygwin should be using GetErrorMode on startup and instead of not inheriting it, ensuring that it sets whatever it received? i.e. just before the call to CreateProcess for a non-Cygwin binary, Cygwin restores the error mode (for that thread only) to the value read at startup, calls CreateProcess and then sets the error mode back. To explain in the context of the actual call chain: - I have opam.exe (compiled with mingw-w64), which is calling SetErrorMode in main - It's calling ocamlc.exe (in PATH) which requires the zstd DLL, but that has not been put in PATH - A direct call - not via Cygwin - to ocamlc -vnum therefore returns an exit code - Another call, already there from the Unix side, instead does sh -c "ocamlc -config | sed ..." but Cygwin has then _removed_ the calling applications preference Thanks, David -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Fri, 2 Feb 2024 at 12:55, Corinna Vinschen via Cygwin wrote: > On Feb 2 09:43, David Allsopp via Cygwin wrote: > > On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin > > wrote: > > > > > > The behaviour changed in 2020 > > > > > > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912 > > > > > > not without a discussion > > > > > > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html > > > > Aha, thank you! (congrats on the 3.5 release, in passing, btw). > > Definitely not a regression, then (subject edited). > > > > However, this patch came from MSYS2, and subsequently they seem to > > have found it problematic for the same reason as me > > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) > > and have just recently reintroduced the flag > > (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) > > to control it. > > > > The reasoning in > > https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as > > valid now as it did in 2006. > > > > Is it possible to revisit having the flag, or even just reverting the > > behaviour? > > > > FWIW, it's been "hurting" us over in OCaml-land since zstd support was > > added roughly a year ago - configure can tell us that mingw-w64's zstd > > is available, but woe betide us if we run the test program to see if > > it actually works, but the user forgot to add the sys-root into PATH, > > because at that point the CI system is down... > > I'm sympathetic, and personally I would prefer to revert the patch and > stick to SEM_FAILCRITICALERRORS by default. > > The question is this: Why does, apparently, everybody expect Cygwin to > do the "right thing", with different definitions of "right", when in > fact the executable in question can easily call SetErrorMode by itself? The executable can't, though (at least, I'm not aware that it can)? The DLL not found case is being triggered by the loader, before the entrypoint code is running? I did have a look to see if there are manifest flags or some such which can be set to indicate this, but it does seem to be the responsibility of the caller, coupled with a "best practice" recommendation on MSDN to call SetErrorMode (as Cygwin is of course doing). The whole system with it feels like unfortunate Windows legacy, but I guess the behaviour vastly predates Event Viewer, etc., and slightly better (and non-blocking) ways of reporting loader errors. Perils of a nearly 40 year old API, if not OS Thanks, David -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On 02/02/2024 12:55, Corinna Vinschen via Cygwin wrote: On Feb 2 09:43, David Allsopp via Cygwin wrote: On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin wrote: The behaviour changed in 2020 https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912 not without a discussion https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html Aha, thank you! (congrats on the 3.5 release, in passing, btw). Definitely not a regression, then (subject edited). However, this patch came from MSYS2, and subsequently they seem to have found it problematic for the same reason as me (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) and have just recently reintroduced the flag (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) to control it. The reasoning in https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as valid now as it did in 2006. Is it possible to revisit having the flag, or even just reverting the behaviour? FWIW, it's been "hurting" us over in OCaml-land since zstd support was added roughly a year ago - configure can tell us that mingw-w64's zstd is available, but woe betide us if we run the test program to see if it actually works, but the user forgot to add the sys-root into PATH, because at that point the CI system is down... I'm sympathetic, and personally I would prefer to revert the patch and stick to SEM_FAILCRITICALERRORS by default. The question is this: Why does, apparently, everybody expect Cygwin to do the "right thing", with different definitions of "right", when in fact the executable in question can easily call SetErrorMode by itself? Yeah, if cygwin wasn't involved in the process ancestry, how would you get the behaviour you want? I guess perhaps what's needed here is a command-wrapper tool like 'nice' or 'env' which lets you run a command with the error-handling mode you want. But that must already exist for Windows, right? :) -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Feb 2 09:43, David Allsopp via Cygwin wrote: > On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin > wrote: > > > > The behaviour changed in 2020 > > > > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912 > > > > not without a discussion > > > > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html > > Aha, thank you! (congrats on the 3.5 release, in passing, btw). > Definitely not a regression, then (subject edited). > > However, this patch came from MSYS2, and subsequently they seem to > have found it problematic for the same reason as me > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) > and have just recently reintroduced the flag > (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) > to control it. > > The reasoning in > https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as > valid now as it did in 2006. > > Is it possible to revisit having the flag, or even just reverting the > behaviour? > > FWIW, it's been "hurting" us over in OCaml-land since zstd support was > added roughly a year ago - configure can tell us that mingw-w64's zstd > is available, but woe betide us if we run the test program to see if > it actually works, but the user forgot to add the sys-root into PATH, > because at that point the CI system is down... I'm sympathetic, and personally I would prefer to revert the patch and stick to SEM_FAILCRITICALERRORS by default. The question is this: Why does, apparently, everybody expect Cygwin to do the "right thing", with different definitions of "right", when in fact the executable in question can easily call SetErrorMode by itself? Corinna -- 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: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]
On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin wrote: > > The behaviour changed in 2020 > > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912 > > not without a discussion > > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html Aha, thank you! (congrats on the 3.5 release, in passing, btw). Definitely not a regression, then (subject edited). However, this patch came from MSYS2, and subsequently they seem to have found it problematic for the same reason as me (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) and have just recently reintroduced the flag (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) to control it. The reasoning in https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as valid now as it did in 2006. Is it possible to revisit having the flag, or even just reverting the behaviour? FWIW, it's been "hurting" us over in OCaml-land since zstd support was added roughly a year ago - configure can tell us that mingw-w64's zstd is available, but woe betide us if we run the test program to see if it actually works, but the user forgot to add the sys-root into PATH, because at that point the CI system is down... Thanks, David -- 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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On 2024-02-01 01:18, David Allsopp via Cygwin wrote: On Wed, 31 Jan 2024 at 22:27, Brian Inglis via Cygwin wrote: On 2024-01-31 06:40, David Allsopp via Cygwin wrote: Starting with this very trivial C program: #include #include int main(void) { printf("Zstandard v%d\n", ZSTD_versionNumber()); } and compiling with x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd when I then run ./test.exe, I get the Windows critical-error-handler dialog stating "The code execution cannot proceed because libzstd-1.dll was not found. Reinstalling the program may fix this problem." My question is not how to fix the problem (I'm well aware of that), but rather why that message is being displayed at all, and is it a bug in Cygwin somewhere? All I could find Googling was previous suggestions that Cygwin routinely calls SetErrorMode with, amongst other things, SEM_FAILCRITICALERRORS with the intention of suppressing this dialog. Is that correct, and if so is this just me? :o) Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty. I also get the same popup if I run C:\cygwin64\bin\sh -c "/cygdrive/c/path/to/test" either from a Command Prompt or even from "Start -> Run". Running this via "sh" called from a non-Cygwin process (itself invoked from a Command Prompt) which has also called SetErrorMode is how I hit this. Better to let you know that there is a problem, and what the problem is, so you can fix it! Thank you, but no - as I made clear by: My question is not how to fix the problem (I'm well aware of that) I'm fully aware what has caused the issue to arise, and how to fix it - that's not the issue. The problem is that according to previous messages, and the Cygwin code, my impression was that mintty / bash / sh (*Cygwin* programs) calling this executable should be returning an exit code here, not freezing on a message dialog. The problem appears to be a bug in the Cygwin DLL, and from previous messages on the list, my question is whether it's a regression, and can be fixed. The reason it's a problem is, say, a script _in Cygwin_ which is handed a command to run, runs it, and is then completely blocked by that popup dialog. It's the responsibility of the _caller_ (a Cygwin program) to indicate the mode in which a program is executed - the message box may be owned by the program called, but it's caused by it being loaded, before it has a chance to run any code. My understanding, based on this line: https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/dcrt0.cc#L721 in dll_crt0_0 is that Cygwin executables (in this case mintty / bash / sh, etc.) should be running with SEM_FAILCRITICALERRORS enabled, following the best practice recommendations in https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode and that that setting should be correctly inherited by processes they call (including non-Cygwin ones). Some ancient history, reporting my same issue in 2004: https://cygwin.com/pipermail/cygwin/2004-March/115553.html and this thread from 2006 https://cygwin.com/pipermail/cygwin/2006-August/150038.html strongly indicating that that line dcrt0.cc is there precisely to stop this popup. I do not see the problem if a native MS Windows program is not properly installed with native MS Windows library dependencies and MS Windows displays a popup to inform the user of the missing dependency. Developer/maintainer/packager/distributor defects are never a downstream issue, they need to be addressed by the party who caused the failure! There seems to be a conflict here with some native MS Windows program users wanting those native MS Windows programs to be able start a debugger and others wanting a CLI failure message. ISTM if native MS Windows programs want specific native MS Windows behaviour, they should set that up before, at, or shortly after startup, as Cygwin does for its own programs, not rely on a foreign invoker doing so for them. Could those native MS Windows programs not be run from a native MS Windows shell or wrapper script to ensure the desired behaviour? Or just do not run native MS Windows programs, and find or build a Cygwin script or program to perform the desired function: that's the Cygwin way to avoid native MS Windows issues! ;^> -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On Feb 1 08:22, David Allsopp via Cygwin wrote: > > x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should > > be involved in the execution ? > > I perhaps should have made that crystal clear - in running "./test", > I'm invoking that excecutable _from_ a Cygwin program (in this case > mintty / bash / sh), so Cygwin is very much involved - it's the > caller. > > In the actual problem which hit this, I have a non-Cygwin executable > which has called SetErrorMode(SEM_FAILCRITICALERRORS). If that program > calls test, there is no popup displayed. However, it also calls > Cygwin's sh and _that_ executes that program too, so something like > "C:\cygwin64\bin\sh -c "./test.exe | sed ..." but then the popup error > message appears. So somewhere along the line, Cygwin appears to be > resetting the system error mode, and that appears contrary to previous > (old) messages on the subject. The behaviour changed in 2020 https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912 not without a discussion https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html Corinna -- 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: Aren't Windows System Error popups meant to be disabled in Cygwin?
> x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should > be involved in the execution ? I perhaps should have made that crystal clear - in running "./test", I'm invoking that excecutable _from_ a Cygwin program (in this case mintty / bash / sh), so Cygwin is very much involved - it's the caller. In the actual problem which hit this, I have a non-Cygwin executable which has called SetErrorMode(SEM_FAILCRITICALERRORS). If that program calls test, there is no popup displayed. However, it also calls Cygwin's sh and _that_ executes that program too, so something like "C:\cygwin64\bin\sh -c "./test.exe | sed ..." but then the popup error message appears. So somewhere along the line, Cygwin appears to be resetting the system error mode, and that appears contrary to previous (old) messages on the subject. Thanks, David -- 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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On Wed, 31 Jan 2024 at 22:27, Brian Inglis via Cygwin wrote: > > On 2024-01-31 06:40, David Allsopp via Cygwin wrote: > > Starting with this very trivial C program: > > > > #include > > #include > > > > int main(void) { > >printf("Zstandard v%d\n", ZSTD_versionNumber()); > > } > > > > and compiling with > > > > x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd > > > > when I then run ./test.exe, I get the Windows critical-error-handler > > dialog stating "The code execution cannot proceed because > > libzstd-1.dll was not found. Reinstalling the program may fix this > > problem." > > > > My question is not how to fix the problem (I'm well aware of that), > > but rather why that message is being displayed at all, and is it a bug > > in Cygwin somewhere? All I could find Googling was previous > > suggestions that Cygwin routinely calls SetErrorMode with, amongst > > other things, SEM_FAILCRITICALERRORS with the intention of suppressing > > this dialog. > > > > Is that correct, and if so is this just me? :o) > > > > Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty. > > I also get the same popup if I run C:\cygwin64\bin\sh -c > > "/cygdrive/c/path/to/test" either from a Command Prompt or even from > > "Start -> Run". Running this via "sh" called from a non-Cygwin process > > (itself invoked from a Command Prompt) which has also called > > SetErrorMode is how I hit this. > > Better to let you know that there is a problem, and what the problem is, so > you > can fix it! Thank you, but no - as I made clear by: > My question is not how to fix the problem (I'm well aware of that) I'm fully aware what has caused the issue to arise, and how to fix it - that's not the issue. The problem is that according to previous messages, and the Cygwin code, my impression was that mintty / bash / sh (*Cygwin* programs) calling this executable should be returning an exit code here, not freezing on a message dialog. The problem appears to be a bug in the Cygwin DLL, and from previous messages on the list, my question is whether it's a regression, and can be fixed. The reason it's a problem is, say, a script _in Cygwin_ which is handed a command to run, runs it, and is then completely blocked by that popup dialog. It's the responsibility of the _caller_ (a Cygwin program) to indicate the mode in which a program is executed - the message box may be owned by the program called, but it's caused by it being loaded, before it has a chance to run any code. My understanding, based on this line: https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/dcrt0.cc#L721 in dll_crt0_0 is that Cygwin executables (in this case mintty / bash / sh, etc.) should be running with SEM_FAILCRITICALERRORS enabled, following the best practice recommendations in https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode and that that setting should be correctly inherited by processes they call (including non-Cygwin ones). Some ancient history, reporting my same issue in 2004: https://cygwin.com/pipermail/cygwin/2004-March/115553.html and this thread from 2006 https://cygwin.com/pipermail/cygwin/2006-August/150038.html strongly indicating that that line dcrt0.cc is there precisely to stop this popup. Thanks, David -- 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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On 2024-01-31 06:40, David Allsopp via Cygwin wrote: Starting with this very trivial C program: #include #include int main(void) { printf("Zstandard v%d\n", ZSTD_versionNumber()); } and compiling with x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd when I then run ./test.exe, I get the Windows critical-error-handler dialog stating "The code execution cannot proceed because libzstd-1.dll was not found. Reinstalling the program may fix this problem." My question is not how to fix the problem (I'm well aware of that), but rather why that message is being displayed at all, and is it a bug in Cygwin somewhere? All I could find Googling was previous suggestions that Cygwin routinely calls SetErrorMode with, amongst other things, SEM_FAILCRITICALERRORS with the intention of suppressing this dialog. Is that correct, and if so is this just me? :o) Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty. I also get the same popup if I run C:\cygwin64\bin\sh -c "/cygdrive/c/path/to/test" either from a Command Prompt or even from "Start -> Run". Running this via "sh" called from a non-Cygwin process (itself invoked from a Command Prompt) which has also called SetErrorMode is how I hit this. Better to let you know that there is a problem, and what the problem is, so you can fix it! I have spent hours trying to track down initialization failures, when daemons just ignored that a library they needed was not found or loaded! Install the following package: $ cygcheck -f /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libzstd-1.dll mingw64-x86_64-zstd-1.5.5-1 -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- 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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On Wed, Jan 31, 2024 at 2:41 PM David Allsopp via Cygwin wrote: > > Starting with this very trivial C program: > > #include > #include > > int main(void) { > printf("Zstandard v%d\n", ZSTD_versionNumber()); > } > > and compiling with > > x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd > > when I then run ./test.exe, I get the Windows critical-error-handler > dialog stating "The code execution cannot proceed because > libzstd-1.dll was not found. Reinstalling the program may fix this > problem." > > My question is not how to fix the problem (I'm well aware of that), > but rather why that message is being displayed at all, and is it a bug > in Cygwin somewhere? All I could find Googling was previous > suggestions that Cygwin routinely calls SetErrorMode with, amongst > other things, SEM_FAILCRITICALERRORS with the intention of suppressing > this dialog. > > Is that correct, and if so is this just me? :o) > > Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty. > I also get the same popup if I run C:\cygwin64\bin\sh -c > "/cygdrive/c/path/to/test" either from a Command Prompt or even from > "Start -> Run". Running this via "sh" called from a non-Cygwin process > (itself invoked from a Command Prompt) which has also called > SetErrorMode is how I hit this. > > Thanks! > > > David > x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should be involved in the execution ? -- 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: Aren't Windows System Error popups meant to be disabled in Cygwin?
On 1/31/2024 7:40 AM, David Allsopp via Cygwin wrote: Starting with this very trivial C program: #include #include int main(void) { printf("Zstandard v%d\n", ZSTD_versionNumber()); } and compiling with x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd when I then run ./test.exe, I get the Windows critical-error-handler dialog stating "The code execution cannot proceed because libzstd-1.dll was not found. Reinstalling the program may fix this problem." [snip] x86_64-w64-mingw32-gcc is a cross compiler, a.k.a. the Mingw compiler, not Cygwin's gcc. It is quite correct for a cross compiler meant to produce Windows executables to do what you are seeing. The executable is independent of Cygwin, i.e. doesn't use the Cygwin dll. -- RB -- 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
Aren't Windows System Error popups meant to be disabled in Cygwin?
Starting with this very trivial C program: #include #include int main(void) { printf("Zstandard v%d\n", ZSTD_versionNumber()); } and compiling with x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd when I then run ./test.exe, I get the Windows critical-error-handler dialog stating "The code execution cannot proceed because libzstd-1.dll was not found. Reinstalling the program may fix this problem." My question is not how to fix the problem (I'm well aware of that), but rather why that message is being displayed at all, and is it a bug in Cygwin somewhere? All I could find Googling was previous suggestions that Cygwin routinely calls SetErrorMode with, amongst other things, SEM_FAILCRITICALERRORS with the intention of suppressing this dialog. Is that correct, and if so is this just me? :o) Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty. I also get the same popup if I run C:\cygwin64\bin\sh -c "/cygdrive/c/path/to/test" either from a Command Prompt or even from "Start -> Run". Running this via "sh" called from a non-Cygwin process (itself invoked from a Command Prompt) which has also called SetErrorMode is how I hit this. Thanks! David -- 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