Re: [ITP] GStreamer dependencies
On Dec 6 23:19, Yaakov (Cygwin/X) wrote: On Mon, 2012-11-19 at 04:01 -0600, Yaakov (Cygwin/X) wrote: These are the remaining dependencies for GStreamer core/base/good, which is needed for updating Qt4 and Phonon, among other things. They are already in Fedora. ftp://ftp.cygwinports.org/pub/cygwinports/uploads/libdv/ ftp://ftp.cygwinports.org/pub/cygwinports/release-2/libshout/ ftp://ftp.cygwinports.org/pub/cygwinports/release-2/libvpx/ ftp://ftp.cygwinports.org/pub/cygwinports/release-2/taglib/ Ping? Pong! I thought we talked about that dependencies for other packages thingy... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU][1.3.9-2] pv
On Dec 7 00:10, Aaron Schneider wrote: pv updated from 1.3.9-1 to 1.3.9-2, first one was crashing at startup. Changelog: - Added --disable-ipc to CYGCONF_ARGS in cygport file: Cygwin does not support the msgget function for IPC. You will need to disable IPC support in PV with configure --disable-ipc before recompiling. This means that -R will be unavailable. Again, Cygwin supports SYSV IPC. Please inform the original author that the functionality depends on a running cygserver process. If this process is not running, the SYSV IPC functions return ENOSYS. IMHO there's no reason to exit if the msgget function returns ENOSYS. The code could simply note the fact and proceed, and only return an error if the user tried the -R option. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] unison2.40, unison2.45
On Dec 6 14:52, Andrew Schulman wrote: Please upload new versions of unison2.40 and unison2.45. For unison2.40, please remove version 2.40.63, leaving 2.40.65 as previous. Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU][1.3.9-2] pv
On 07/12/2012 10:58, Corinna Vinschen wrote:
Again, Cygwin supports SYSV IPC. Please inform the original author that
the functionality depends on a running cygserver process. If this
process is not running, the SYSV IPC functions return ENOSYS.
IMHO there's no reason to exit if the msgget function returns ENOSYS.
The code could simply note the fact and proceed, and only return an
error if the user tried the -R option.
The function has not returned ENOSYS, instead the process has received a
signal, according to gdb's output. This is arguably a bug in Cygwin.
If msgget fails, it should return an error rather than raising a signal.
If it returns an error, pv will handle that.
$ gdb pv
GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i686-cygwin.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/pv...Reading symbols from
/usr/lib/debug/usr/bin/pv.exe.dbg...done.
done.
(gdb) break main.c:1
Breakpoint 1 at 0x4014b7: file /usr/src/debug/pv-1.4.0-1/src/main/main.c, line
1.
(gdb) s
The program is not being run.
(gdb) run
Starting program: /usr/bin/pv
[New Thread 165608.0x25670]
[New Thread 165608.0x27604]
Breakpoint 1, main (argc=1, argv=0x28ac60) at
/usr/src/debug/pv-1.4.0-1/src/main/main.c:50
50 return 64;
(gdb) s
36 {
(gdb) s
43 setlocale(LC_ALL, );
(gdb) s
44 bindtextdomain(PACKAGE, LOCALEDIR);
(gdb) s
45 textdomain(PACKAGE);
(gdb) s
48 opts = opts_parse(argc, argv);
(gdb) s
opts_parse (argc=1, argv=0x28ac60) at
/usr/src/debug/pv-1.4.0-1/src/main/options.c:51
51 struct option long_options[] = {
(gdb) s
49 {
(gdb) s
51 struct option long_options[] = {
(gdb) s
49 {
(gdb) s
51 struct option long_options[] = {
(gdb) s
80 int option_index = 0;
(gdb) s
86 opts = calloc(1, sizeof(*opts));
(gdb) s
87 if (!opts) {
(gdb) s
86 opts = calloc(1, sizeof(*opts));
(gdb) s
87 if (!opts) {
(gdb) s
95 opts-program_name = argv[0];
(gdb) s
98 opts-argv = calloc(argc + 1, sizeof(char *));
(gdb) s
97 opts-argc = 0;
(gdb) s
98 opts-argv = calloc(argc + 1, sizeof(char *));
(gdb) s
99 if (!opts-argv) {
(gdb) s
98 opts-argv = calloc(argc + 1, sizeof(char *));
(gdb) s
99 if (!opts-argv) {
(gdb) s
111 opts-interval = 1;
(gdb) s
244 opts-pidfile = optarg;
(gdb) s
109 numopts = 0;
(gdb) s
111 opts-interval = 1;
(gdb) s
244 opts-pidfile = optarg;
(gdb) s
241 opts-remote = pv_getnum_i(optarg);
(gdb) s
232 opts-buffer_size = pv_getnum_ll(optarg);
(gdb) s
229 opts-rate_limit = pv_getnum_ll(optarg);
(gdb) s
115 c = getopt_long(argc, argv, /* RATS: ignore */
(gdb) s
121 if (c 0)
(gdb) s
115 c = getopt_long(argc, argv, /* RATS: ignore */
(gdb) s
121 if (c 0)
(gdb) s
265 } while (c != -1);
(gdb) s
270 if (0 == numopts) {
(gdb) s
271 opts-progress = 1;
(gdb) s
272 opts-timer = 1;
(gdb) s
273 opts-eta = 1;
(gdb) s
274 opts-rate = 1;
(gdb) s
275 opts-bytes = 1;
(gdb) s
281 while (optind argc) {
(gdb) s
286 }
(gdb) s
main (argc=1, argv=0x28ac60) at /usr/src/debug/pv-1.4.0-1/src/main/main.c:49
49 if (NULL == opts)
(gdb) s
48 opts = opts_parse(argc, argv);
(gdb) s
49 if (NULL == opts)
(gdb) s
52 if (opts-do_nothing) {
(gdb) s
60 if (opts-remote 0) {
(gdb) s
69 state = pv_state_alloc(opts-program_name);
(gdb) s
pv_state_alloc (program_name=0x8003b070 /usr/bin/pv) at
/usr/src/debug/pv-1.4.0-1/src/pv/state.c:20
20 state = calloc(1, sizeof(*state));
(gdb) s
21 if (0 == state)
(gdb) s
20 state = calloc(1, sizeof(*state));
(gdb) s
21 if (0 == state)
(gdb) s
24 state-program_name = program_name;
(gdb) s
26 state-pv_crs_shmid = -1;
(gdb) s
27 state-pv_crs_pvcount = 1;
(gdb) s
29 state-pv_crs_lock_fd = -1;
(gdb) s
24 state-program_name = program_name;
(gdb) s
31 state-reparse_display = 1;
(gdb) s
32 state-current_file = _(none);
(gdb) s
35 }
(gdb) s
main (argc=1,
Re: [RFU][1.3.9-2] pv
On Dec 7 16:46, Aaron Schneider wrote: On 07/12/2012 10:58, Corinna Vinschen wrote: Again, Cygwin supports SYSV IPC. Please inform the original author that the functionality depends on a running cygserver process. If this process is not running, the SYSV IPC functions return ENOSYS. IMHO there's no reason to exit if the msgget function returns ENOSYS. The code could simply note the fact and proceed, and only return an error if the user tried the -R option. The function has not returned ENOSYS, instead the process has received a signal, according to gdb's output. This is arguably a bug in Cygwin. No, it isn't. Calling a non-existant function raises a SIGSYS signal. That's ok per POSIX (albeit it's an XSI extension). pv could simply call signal (SIGSYS, SIG_IGN) and then just fetch the error code returned from msgget. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
pv-debuginfo wrong category
setup is pulling the installation of pv-debuginfo I guess is due to the wrong Category @ pv-debuginfo category: Misc requires: cygwin version: 1.3.9-2 install: release/pv/pv-debuginfo/pv-debuginfo-1.3.9-2.tar.bz2 60324 84cf45dc9f17 22b760069314bef4
[ANNOUNCEMENT] Updated: xscope-1.4-1
The following packages have been updated for the Cygwin distribution: *** xscope-1.4-1 Xscope sits in-between an X11 client and an X11 server and prints the contents of each request, reply, error, or event that is communicated between them. Xscope can decode the core X11 protocol and several extensions, including BIG-REQUESTS, GLX, MIT-SHM, RANDR, and RENDER. This information can be useful in debugging and performance tuning of X11 servers and clients. This is an update to the latest upstream release. -- Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xterm-287-1
The following package has been updated for the Cygwin distribution: *** xterm-287-1 The xterm program is a terminal emulator for the X Window System. It provides DEC VT102 and Tektronix 4014 compatible terminals for programs that can't use the window system directly. This is an update to the latest upstream release. -- Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
1.7.17: child window opens without window-manager
Hi, a proprietary medical program (programmed in qt) is working with cygwin in -multiwindow mode on WinXP. Latest cygwin 1.7.17 (installed 3 days ago) seens so work. But child windows of that programm open in fullscreen size (fill the entire screen) and without important window manager functions: the windows can't be rezised with the mouse and the 3 symbols in the top right corner X, _ and D are missing. Xwin.exe is started with parameters: -multiwindow -ac BTW: Xming with same parameters as Xserver works fine! But Xming has not shared memory (shm-MIT) :( So we need cygwin. any help will be appreciated. thx Eckard -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 1.7.17: child window opens without window-manager
further informations: a very old cygwin (0.9. ?? , about 6 years old) has no problems with child windows. The childs apear with 3 symbols in the top right corner X, _ and D and the childs are opened in the correct size. We need now a newer cygwin because of SHM-MIT (shared memory). * egerl...@aiai.de (me!) wrote: Hi, a proprietary medical program (programmed in qt) is working with cygwin in -multiwindow mode on WinXP. Latest cygwin 1.7.17 (installed 3 days ago) seens so work. But child windows of that programm open in fullscreen size (fill the entire screen) and without important window manager functions: the windows can't be rezised with the mouse and the 3 symbols in the top right corner X, _ and D are missing. Xwin.exe is started with parameters: -multiwindow -ac BTW: Xming with same parameters as Xserver works fine! But Xming has no shared memory (shm-MIT) :( So we need cygwin. any help will be appreciated. thx Eckard -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: pcre-8.32-1
The following packages have been updated for the Cygwin distribution: *** pcre-8.32-1 *** libpcre1-8.32-1 *** libpcre16_0-8.32-1 *** libpcre32_0-8.32-1 *** libpcrecpp0-8.32-1 *** libpcreposix0-8.32-1 *** libpcre-devel-8.32-1 The PCRE library implements regular expression pattern matching using the same syntax and semantics as Perl. This is an update to the latest upstream release, adding the libpcre32 library for UTF-32 pcre functionality. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: tdb-1.2.11-1
The following packages have been updated for the Cygwin distribution: *** tdb-1.2.11-1 *** libtdb1-1.2.11-1 *** libtdb-devel-1.2.11-1 *** python-tdb-1.2.11-1 TDB is a Trivial Database. In concept, it is very much like GDBM, and BSD's DB except that it allows multiple simultaneous writers and uses locking internally to keep writers from trampling on each other. This is an update to the latest upstream release. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sigwait() ignores non-thread-specific pending signals
Le 07/12/2012 02:27, Christopher Faylor a écrit : I don't see any difference between Cygwin and Linux when I run the test program. cgf I re-compiled and ran the test program under Cygwin 1.7.17 as well as on several Linux machines (Debian/Fedora/Gentoo/Ubuntu, kernel versions 2.6.29/2.6.32/3.0.6/3.2.0/3.2.12/3.4.9/3.6.6, different kinds of CPUs etc.) and I definitely see a difference. The difference is that after typing in the commands kill -SIGUSR2 [pid] kill -SIGUSR1 [pid] kill -SIGUSR2 [pid] kill -SIGUSR1 [pid] (in this order!) in another console, the program blocks under Cygwin while it exits normally under Linux. The last output under Cygwin is 'thread 2 waiting for SIGUSR2' while under Linux, one more line 'thread 2 received SIGUSR2' is printed out before the program exits. Regards, Andreas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygrunsrv and special Windows virtual accounts NT SERVICE
Hi all, I have a suggestion that cygrunsrv doesn't ask for any password with the option -u (and -w not provided), if the specified user is like NT SERVICE\svcname, where svcname is the service being added. Otherwise, cygrunsrv is not self-sufficient for defining a service, and has to be further supplemented with a patch using the native SC command. Yet having every service to run under the privileged LocalSystem account is not always justified. So, instead of having to do a two-step process: cygrunsrv -I svcname ... sc config svcname obj= NT SERVICE\svcname everything could be done in one command: cygrunsrv -I svcname -u NT SERVICE\svcname ... Thanks, Anton Lavrentiev Contractor NIH/NLM/NCBI See: http://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
FW: A bug in CYGWIN exec() and revision of argument values
Hi, Just checking whether this is going to be fixed, or should be keep working around by passing the lowercased version of the /C switch ? if (ac == 3 argv[1][0] == '/' argv[1][1] == 'c' (iscmd (argv[0], command.com) || iscmd (argv[0], cmd.exe))) Regards, Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: emacs*-24.2.90-1 (TEST)
On 12/7/2012 2:37 AM, Achim Gratz wrote: Thanks. Now, after I set DejaVu Sans Mono for X11 and Consolas for W32, the problem with emacs hanging up on me is gone as well. So it seems that the invocation of the xft(?) stuff was to blame... This shouldn't happen. Daniel, shouldn't *all* the X11 stuff be disabled in the cygw32 build? The GSettings and GConf problems I mentioned earlier in the thread wouldn't have occurred if this were done. I think it's time to take this to the emacs list. I've just filed a bug report (bug#13112) in order to focus the discussion. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SVN and executable permissions
On 2012-12-05 20:24, Burton Samograd wrote: bartels bart...@mailme.ath.cx writes: Is there way to specify to svn on the command line or though a config file that these types of files should automatically have executable permissions? svn propset svn:executable *your file Any idea why this has to be done with the command line version of svn and not with Tortise? TortoiseSVN lets Windows manage the ACLs for the files checked out. Under most circumstances, this means that *all* files have executable permissions. Cygwin's svn only sets executable permissions if the svn-property is set. This is not a bug in either cygwin, svn, or tortoiseSvn. They just work differently. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: FW: A bug in CYGWIN exec() and revision of argument values
On Fri, Dec 07, 2012 at 01:33:52PM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Hi, Just checking whether this is going to be fixed, or should be keep working around by passing the lowercased version of the /C switch ? if (ac == 3 argv[1][0] == '/' argv[1][1] == 'c' (iscmd (argv[0], command.com) || iscmd (argv[0], cmd.exe))) http://cygwin.com/snapshots/winsup-changelog-20121128-20121130 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygrunsrv and special Windows virtual accounts NT SERVICE
On Dec 7 13:30, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Hi all, I have a suggestion that cygrunsrv doesn't ask for any password with the option -u (and -w not provided), if the specified user is like NT SERVICE\svcname, where svcname is the service being added. Otherwise, cygrunsrv is not self-sufficient for defining a service, and has to be further supplemented with a patch using the native SC command. Yet having every service to run under the privileged LocalSystem account is not always justified. So, instead of having to do a two-step process: cygrunsrv -I svcname ... sc config svcname obj= NT SERVICE\svcname everything could be done in one command: cygrunsrv -I svcname -u NT SERVICE\svcname ... What about cygrunsrv -I svcname -u NT SERVICE\svcname -p '' ? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: emacs*-24.2.90-1 (TEST)
Ken Brown writes: I think it's time to take this to the emacs list. I've just filed a bug report (bug#13112) in order to focus the discussion. Thanks, I'll follow up there if necessary. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Cygrunsrv and special Windows virtual accounts NT SERVICE
cygrunsrv -I svcname -u NT SERVICE\svcname -p '' I'm not quite sure I follow your suggestion: -p is for path to the actual executable that implements the background process If you meant -w '' (or as documentation suggests '-w ') then it does not work for some reason -- cygrunsrv cannot install the service (per the bad user/pass combo, presumably). Anton Lavrentiev Contractor NIH/NLM/NCBI
Re: emacs child process goes defunct
On 12/6/2012 10:42 PM, Ken Brown wrote: On 12/6/2012 5:20 PM, Rockefeller, Harry wrote: 'Emacs -Q' failed after a few minutes of doing svn file diffs. Can you give me a detailed step-by-step recipe so that I can try to reproduce the problem? I don't really know what you mean by doing svn file diffs. I ran gdb on the hung process. I am not too familiar with this kind of debugging. Let me know if there is more I can give next time this happens. Here is some output. ps PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 830418304 8304 cons0 11097 15:35:35 /usr/bin/xterm 303283043032 8048 pty211097 15:35:42 /usr/bin/bash 642830323032 7580 pty211097 15:35:48 /usr/bin/xterm 630464286304 9440 pty311097 15:35:48 /usr/bin/bash 612063046120 10052 pty311097 15:42:55 /usr/bin/emacs-X11 712461207124 8524 ? 11097 16:02:29 /usr/bin/diff defunct And $ gdb --pid=6120 GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-cygwin. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Attaching to process 10052 [New Thread 10052.0x2028] [New Thread 10052.0x2434] [New Thread 10052.0x1100] [New Thread 10052.0x78c] [New Thread 10052.0x225c] [New Thread 10052.0xca4] [New Thread 10052.0x2234] Reading symbols from /usr/bin/emacs-X11.exe...Reading symbols from /usr/lib/debug/usr/bin/emacs-X11.exe.dbg...done. done. (gdb) bt #0 0x7c90120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c952119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x0005 in ?? () #3 0x in ?? () This is a backtrace of a thread that gdb has created. You need to switch to thread 1 (the main emacs thread) before you can get a useful backtrace: (gdb) thread 1 (gdb) bt Even better, you can get a backtrace of all threads with the command `thread apply all bt' or, for more detail, `thread apply all bt full'. And please attach cygcheck output when you write again. One other question: Both you and Jonas Linde have said that emacs hangs. Do you see the CPU usage increasing when this happens? If so, that would suggest an infinite loop. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Cygrunsrv and special Windows virtual accounts NT SERVICE
per the bad user/pass combo, presumably). Per MSDN, http://msdn.microsoft.com/en-us/library/windows/desktop/ms682450%28v=vs.85%29.aspx : If the account name specified by the lpServiceStartName parameter is the name of a managed service account or virtual account name, the lpPassword parameter must be NULL. But cygrunsrv passes either or the actual string (when any username is provided). It should pass NULL for the username that look like NT SERVICE\svcname: if (!(sh = CreateService (sm, san.name (), disp, SERVICE_ALL_ACCESS, SERVICE_WIN32_OWN_PROCESS | (interactive ? SERVICE_INTERACTIVE_PROCESS : 0), type == Auto ? SERVICE_AUTO_START : SERVICE_DEMAND_START, SERVICE_ERROR_NORMAL, mypath, NULL, NULL, dependencies, username, username ? pass ?: : NULL))) Anton Lavrentiev Contractor NIH/NLM/NCBI
Re: sigwait() ignores non-thread-specific pending signals
On Fri, Dec 07, 2012 at 10:46:29AM +0100, Andreas Steenpa? wrote: Le 07/12/2012 02:27, Christopher Faylor a ?crit : I don't see any difference between Cygwin and Linux when I run the test program. cgf I re-compiled and ran the test program under Cygwin 1.7.17 as well as on several Linux machines (Debian/Fedora/Gentoo/Ubuntu, kernel versions 2.6.29/2.6.32/3.0.6/3.2.0/3.2.12/3.4.9/3.6.6, different kinds of CPUs etc.) and I definitely see a difference. The difference is that after typing in the commands kill -SIGUSR2 [pid] kill -SIGUSR1 [pid] kill -SIGUSR2 [pid] kill -SIGUSR1 [pid] (in this order!) in another console, the program blocks under Cygwin while it exits normally under Linux. The last output under Cygwin is 'thread 2 waiting for SIGUSR2' while under Linux, one more line 'thread 2 received SIGUSR2' is printed out before the program exits. Sorry, I missed the extra kills in your example. This should be fixed in CVS and in the upcoming snapshot. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gcc -ansi produces unexpected floating point result
try gcc4, gcc3 is obsolete. Hi Marco. Unfortunately gcc-4 gives this error: C:\devel\bwbasicgcc-4 -mno-cygwin -ansi zatest.c gcc-4: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler. I'm also including the results of ldd on the gcc3 compile: C:\devel\bwbasicldd a.exe ntdll.dll = /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77e7) kernel32.dll = /cygdrive/c/Windows/syswow64/kernel32.dll (0x75f5) KERNELBASE.dll = /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x7582) msvcrt.dll = /cygdrive/c/Windows/syswow64/msvcrt.dll (0x75a6) It looks to me like I have done everything correctly, and it would be good if gcc 3 still worked. gcc 3 is important to me for other reasons (ie it is the only thing that supports the i370 target). I don't have any other platform to try gcc 3.4.4 out on. Thanks. Paul. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Intermittent failures retrieving process exit codes
I've witnessed intermittent failures in multiple build systems while working at multiple companies using Cygwin bash and make as part of the build system but using non-Cygwin compilers and other tools. The intermittent failures occur when a process appears to complete successfully, but the process retrieving its exit code receives an unexpected value. This has been seen on many different Cygwin versions across several years. Several reports of similar sounding issues can be found online: - http://cygwin.1069669.n5.nabble.com/Cygwin-1-7-x-on-Windows-7-Exit-statuses-of-Win32-executables-are-sometimes-wrong-td20186.html - http://stackoverflow.com/questions/9769256/intermittent-failures-under-cygwin-possibly-related-to-candle-and-or-make I recently was able to produce a very small test case that reproduces this issue reliably on some machines: $ cat test.sh #!/bin/sh while [ 1 ]; do echo test... if cmd /c false; then echo exiting... exit 1 fi done An invocation of test.sh should run indefinitely, but fails very quickly on one of my machines: $ ./test.sh test... test... exiting... $ ./test.sh test... test... test... test... exiting... $ ./test.sh test... exiting... There are several high-level possibilities for what is going wrong: 1) cmd.exe is failing to retrieve the correct exit code for the invocation of false.exe (A Cygwin process). 2) cmd.exe is failing to return the (correct) exit code it received for the invocation of false.exe. 3) bash.exe (A Cygwin process) is failing to retrieve the correct exit code for the invocation of cmd.exe. It is possible that other software installed on the machines I've witnessed this on are contributing to the problem (ala http://cygwin.com/faq/faq.using.html#faq.using.bloda). If so, such software would be a contributing factor to one of the explanations above, but does not necessarily mean that there is not a defect in Cygwin (or CreateProcess, WaitForSingleObject, or GetExitCodeProcess). I have not yet seen a similar case that does not involve Cygwin, so at present I suspect a defect in Cygwin, but possibly one that produces no negative symptoms in isolation. I've reproduced this issue with both the 32-bit and 64-bit versions of cmd.exe. I've also reproduced it by replacing cmd.exe with a C file that calls CreateProcess for Cygwin's false.exe on its own. The issue reproduces whether that C file is compiled with Cygwin gcc, MinGW gcc (32-bit and 64-bit), and with MSVC (32-bit and 64-bit). So, substitute what you like for 'cmd.exe' in the above. Likewise, I've reproduced this issue by replacing false.exe in the test above with a custom false.exe (A C program that just returns 1). The issue reproduces whether myfalse.exe is compiled with Cygwin gcc, MinGW gcc (32-bit and 64-bit), and with MSVC (32-bit and 64-bit). So, substitute what you like for 'false.exe' in the above. I am not able to reproduce the problem if I elide the invocation of false.exe. (ie, if the cmd.exe invocation is 'cmd /c exit /B 1' or if my replacement for cmd.exe just returns 1). The problem feels like a race condition in retrieving process exit codes. Further, it seems that it may only occur when two related processes exit in quick succession. I've been granted several weeks in the near future to work exclusively on this issue. Before I start working on it though, I'd like to hear from other community members who have experienced this and tried to debug it. What is and is not known about the issue. What workarounds have been tried (especially any that were found to be successful). Are there specific parts of the Cygwin (or bash) code that you recommend starting with? The machine that I've been running the above script on is 64-bit Windows 7 Professional SP1 running under VMware Workstation 8 which is running on Kubuntu 12.04. Relevant parts of 'cygcheck-s' are: Windows 7 Professional N Ver 6.1 Build 7601 Service Pack 1 Running under WOW64 on AMD64 Cygwin DLL version info: DLL version: 1.7.16 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 262 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 Potential app conflicts: ByteMobile laptop optimization client. No Cygwin services found. Cygwin Package Information PackageVersion Status bash 4.1.10-4 OK cygwin 1.7.16-1 OK Tom. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info:
virtualenv 1.8.4 broken on cygwin, plus workaround
If you're used to pip install virtualenv virtualenv foo working, but it recently started failing with ... File /usr/lib/python2.6/site-packages/virtualenv.py, line 1506, in install_python raise e OSError: [Errno 2] No such file or directory you may be suffering from https://github.com/pypa/virtualenv/issues/373 A workaround that worked for me was to roll back virtualenv from 1.8.4 to 1.8.2, e.g. $ pip uninstall virtualenv $ pip install virtualenv==1.8.2 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gcc -ansi produces unexpected floating point result
On 12/7/2012 8:25 PM, Paul Edwards wrote: try gcc4, gcc3 is obsolete. Hi Marco. Unfortunately gcc-4 gives this error: C:\devel\bwbasicgcc-4 -mno-cygwin -ansi zatest.c gcc-4: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler. Hi Paul, gcc4 is for building on cygwin for cygwin. -mno-cygwin was for building on cygwin for NO cygwin, like mingw. It is now a deprecated tweak. For that scope are now available 2 cross-compilers see packages: mingw-gcc-core mingw64-i686-gcc-core both as 4.5.x versions I'm also including the results of ldd on the gcc3 compile: C:\devel\bwbasicldd a.exe ntdll.dll = /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77e7) kernel32.dll = /cygdrive/c/Windows/syswow64/kernel32.dll (0x75f5) KERNELBASE.dll = /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x7582) msvcrt.dll = /cygdrive/c/Windows/syswow64/msvcrt.dll (0x75a6) It looks to me like I have done everything correctly, and it would be good if gcc 3 still worked. gcc 3 is important to me for other reasons (ie it is the only thing that supports the i370 target). I don't have any other platform to try gcc 3.4.4 out on. Thanks. Paul. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Intermittent failures retrieving process exit codes
On 12/07/2012 02:54 PM, Tom Honermann wrote: Likewise, I've reproduced this issue by replacing false.exe in the test above with a custom false.exe (A C program that just returns 1). The issue reproduces whether myfalse.exe is compiled with Cygwin gcc, MinGW gcc (32-bit and 64-bit), and with MSVC (32-bit and 64-bit). So, substitute what you like for 'false.exe' in the above. The above is not correct, I erred in my testing. I am able to reproduce the issue when replacing false.exe in the test case with a custom false.exe compiled with Cygwin gcc. I am *not* able to reproduce the issue when replacing it with one compiled with MinGW gcc (32-bit or 64-bit) or with MSVC (32-bit or 64-bit). Tom. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Intermittent failures retrieving process exit codes
On 12/07/2012 08:54 PM, Tom Honermann wrote: I recently was able to produce a very small test case that reproduces this issue reliably on some machines: Your suspicion about a race condition may very well be correct: I can easily confirm the problem on both iron and virtual smp, but not on a single core virtual. I have two instances of your test case running for half hour on the same core, without any problem: 30k cycles without hickup. Apart from the immediate effect exposed by your script, I have reason to believe that the root cause also affects other running (smp) processes. bartels -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gcc -ansi produces unexpected floating point result
Greetings, Paul Edwards! try gcc4, gcc3 is obsolete. Unfortunately gcc-4 gives this error: C:\devel\bwbasicgcc-4 -mno-cygwin -ansi zatest.c gcc-4: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler. It's not an error, it's a matter of fact. no-cygwin hackery was long since replaced by a proper cross-compiler. I'm also including the results of ldd on the gcc3 compile: C:\devel\bwbasicldd a.exe ntdll.dll = /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x77e7) kernel32.dll = /cygdrive/c/Windows/syswow64/kernel32.dll (0x75f5) KERNELBASE.dll = /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x7582) msvcrt.dll = /cygdrive/c/Windows/syswow64/msvcrt.dll (0x75a6) It looks to me like I have done everything correctly, and it would be good if gcc 3 still worked. gcc 3 is important to me for other reasons (ie it is the only thing that supports the i370 target). I don't have any other platform to try gcc 3.4.4 out on. -- WBR, Andrey Repin (anrdae...@freemail.ru) 08.12.2012, 05:21 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: pcre-8.32-1
The following packages have been updated for the Cygwin distribution: *** pcre-8.32-1 *** libpcre1-8.32-1 *** libpcre16_0-8.32-1 *** libpcre32_0-8.32-1 *** libpcrecpp0-8.32-1 *** libpcreposix0-8.32-1 *** libpcre-devel-8.32-1 The PCRE library implements regular expression pattern matching using the same syntax and semantics as Perl. This is an update to the latest upstream release, adding the libpcre32 library for UTF-32 pcre functionality. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Updated: tdb-1.2.11-1
The following packages have been updated for the Cygwin distribution: *** tdb-1.2.11-1 *** libtdb1-1.2.11-1 *** libtdb-devel-1.2.11-1 *** python-tdb-1.2.11-1 TDB is a Trivial Database. In concept, it is very much like GDBM, and BSD's DB except that it allows multiple simultaneous writers and uses locking internally to keep writers from trampling on each other. This is an update to the latest upstream release. -- Yaakov Cygwin/X CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
