Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected
On May 23 13:33, David Rothenberger wrote: > On 5/23/2012 1:10 PM, Corinna Vinschen wrote: > > On May 23 19:54, Corinna Vinschen wrote: > >> On May 23 10:42, David Rothenberger wrote: > >>> On 5/23/2012 10:18 AM, Corinna Vinschen wrote: > Ok, for the time being I checked in my workaround. Please test the > today's developer snapshot. > >>> > >>> I tried installing this snapshot and found most things hung. > >>> Specifically, I ran ash in a Windows cmd window, then tried > >>> > >>> /bin/echo foo > >>> > >>> I tried mintty too but bash hangs before I get a prompt. > >> > >> Big fat sigh. This all worked fine while debugging. Just that the > >> snapshot is built with optimization and my debugging version is not. > >> Ok, back to the drawing board. > > > > I think I found the problem. I've uploaded a new snapshot. Please give > > it a try. > > Works for me now. I also ran the libapr1 tests in case this touched any > of the various mutex stuff and they all passed, too. Thanks! 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
svn --version
Hello, With the new subversion (1.7.5) and the last snapshot (20120523 21:51:34), the command 'svn --version' produces segmentation fault, with no svn.exe.stackdump produced: % /usr/bin/svn --version Segmentation fault % All the other commands that i've tested are ok. Only svn seems impacted. The new subversion (1.7.5) + the snapshot from Tuesday (20120522) produce no error, and e.g. 'svn update' works perfectly. I was not able to test with the previous subversion since it is no longer available in my Setup. I was not able to test with the first snapshot of 20120523, because i've lost it. I don't know if strace could be useful, but my strace seems broken (this is not new) and produces: % /usr/bin/env -i TZ=Europe/Monaco /usr/bin/date Thu May 24 09:01:14 CEST 2012 % /usr/bin/env -i TZ=Europe/Monaco /usr/bin/strace /usr/bin/date >! /dev/null 8773 [main] date 3248 D:\Home\dexcoff1\dexcoff1\cyg12c\bin\date.exe: *** fatal error - internal error reading the windows environment - too many environment variables? 10625 [main] date 3248 open_stackdumpfile: Dumping stack trace to date.exe.stackdump % cat date.exe.stackdump Stack trace: Frame Function Args 002297C8 6102F5AB (002297C8, , , 7C9201DB) 00229AB8 6102F5AB (6119EDC0, 8000, , 611A0C2F) 0022AAE8 610061BC (611CD03C, 0022AB14, 0022AC08, ) 0022AB08 610061F8 (611CD03C, 0022AB14, 61188C28, ) 0022AC88 6102DE28 (, 61186730, 0022ACB8, 61137102) 0022ACB8 610AE404 (, , , ) 0022AD28 6100683C (, 0022CDA8, 610067B0, ) End of stack trace % addr2line -e /usr/bin/cygwin1.dbg 6102F5AB /home/corinna/src/cygwin/cygwin-1.7.15/cygwin-1.7.15-1/src/cygwin-1.7.15/winsup/cygwin/exceptions.cc:383 % addr2line -e /usr/bin/cygwin1.dbg 610061BC /home/corinna/src/cygwin/cygwin-1.7.15/cygwin-1.7.15-1/src/cygwin-1.7.15/winsup/cygwin/dcrt0.cc:599 % Sorry to report two problems in a single message. Regards, Denis Excoffier. -- 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 --version
On May 24 09:06, Denis Excoffier wrote: > > Hello, > > With the new subversion (1.7.5) and the last > snapshot (20120523 21:51:34), the command 'svn --version' produces > segmentation fault, with no svn.exe.stackdump produced: > > % /usr/bin/svn --version > Segmentation fault > % I just installed the latest subversion 1.7.5 and I can not reproduce this crash. svn --version prints the version information just fine with the latest snapshot DLL. I made sure I was really using the snapshot DLL, not my local debug version. > % /usr/bin/env -i TZ=Europe/Monaco /usr/bin/date > Thu May 24 09:01:14 CEST 2012 > % /usr/bin/env -i TZ=Europe/Monaco /usr/bin/strace /usr/bin/date >! /dev/null >8773 [main] date 3248 D:\Home\dexcoff1\dexcoff1\cyg12c\bin\date.exe: *** > fatal error - internal error reading the windows environment - too many > environment variables? > 10625 [main] date 3248 open_stackdumpfile: Dumping stack trace to > date.exe.stackdump That's a crash of some sorts while trying to convert the Windows environment to the Cygwin POSIX environment. Again, I can't reproduce this one with the latest snapshot and the latest 1.7.15 strace. For a start, please send your cygcheck -svr info. Did you try to see if manual rebaseing helps? 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: ACLs restore mismatch, especially with Rsync
Le 21 mai 2012 à 20:56, AZ 9901 a écrit : > 2012/5/21 Karl M : >> >> Take a look at SetACL. >> >> >> >> ...Karl >> > Hello Karl, > > Thank you ! > Is there also an official Microsoft tool ? > > Thank you ! > > Best regards, > > Ben I had a look, Microsoft tool is ICACLS, it has /save and /restore options, but it is available only on last Windows versions. So yes we have SetACL, another interesting tool is FILEACL. Ben -- 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: 1.7.15-1: pthread_cancel and pthread_kill not working as expected
> I think I found the problem. I've uploaded a new snapshot. Please give > it a try. My testcases for asynchronous and deferred cancel work on threads blocked in sem_wait() but still fail mostly on threads blocked in read(STDIN_FILENO, ...), same as before. Sorry about that. $ uname -v 20120523 21:51:34 Fresh output of cygcheck -s -v -r attached, if that helps. Otto Cygwin Configuration Diagnostics Current System Time: Thu May 24 10:47:11 2012 Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1 Running under WOW64 on AMD64 Path: D:\Software\cygwin\usr\local\bin D:\Software\cygwin\bin C:\Program Files (x86)\Atmel\AVR Tools\AVR32 Toolchain\bin C:\WinAVR-20100110\bin C:\WinAVR-20100110\utils\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared C:\Program Files (x86)\Common Files\Roxio Shared\9.0\DLLShared C:\Program Files\MATLAB\R2008a\bin C:\Program Files\MATLAB\R2008a\bin\win64 C:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn C:\Program Files (x86)\IVI Foundation\IVI\bin C:\Program Files\IVI Foundation\IVI\bin C:\Program Files (x86)\IVI Foundation\VISA\winnt\agvisa C:\Program Files (x86)\IVI Foundation\VISA\winnt\bin C:\Program Files (x86)\NASM C:\Program Files (x86)\Atmel\Flip 3.4.1\bin D:\Software\Python3.2 Output from D:\Software\cygwin\bin\id.exe UID: 1000(MBA) GID: 513(None) =513(None) 545(Benutzer) 1005(Debuggerbenutzer) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'MBA' PWD = '/tmp' HOME = '/home/MBA' HOMEPATH = '\Users\MBA' MANPATH = '/usr/local/man:/usr/share/man:/usr/man:' APPDATA = 'C:\Users\MBA\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'TempleOfTheDog' SHELL = '/bin/bash' TERM = 'cygwin' RoxioCentral = 'C:\Program Files (x86)\Common Files\Roxio Shared\9.0\Roxio Central33\' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 23 Stepping 10, GenuineIntel' WINDIR = 'C:\Windows' VXIPNPPATH64 = 'C:\Program Files\IVI Foundation\VISA\' PUBLIC = 'C:\Users\Public' OLDPWD = '/tmp' USERDOMAIN = 'TEMPLEOFTHEDOG' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' !:: = '::\' temp = 'C:\Users\MBA\AppData\Local\Temp' VS90COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' tmp = 'C:\Users\MBA\AppData\Local\Temp' VXIPNPPATH = 'C:\Program Files (x86)\IVI Foundation\VISA\' USERNAME = 'MBA' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' IVIROOTDIR32 = 'C:\Program Files (x86)\IVI Foundation\IVI\' FP_NO_HOST_CHECK = 'NO' CARBON_MEM_DISABLE = '1' SYSTEMDRIVE = 'C:' PROCESSOR_ARCHITEW6432 = 'AMD64' LANG = 'de_DE.UTF-8' USERPROFILE = 'C:\Users\MBA' TZ = 'Europe/Berlin' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\TEMPLEOFTHEDOG' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\MBA\AppData\Local' HISTCONTROL = 'ignoredups' ProgramData = 'C:\ProgramData' SHLVL = '1' IVIROOTDIR64 = 'C:\Program Files\IVI Foundation\IVI\' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' !D: = 'D:\Software\cygwin\bin' PROMPT = '$P$G' COMSPEC = 'C:\Windows\system32\cmd.exe' SYSTEMROOT = 'C:\Windows' PRINTER = 'KONICA MINOLTA Universal PS' PROCESSOR_REVISION = '170a' UGII_3DCONNEXION_LIBRARY = '%UGII_BASE_DIR%\ugalliance\vendor\startup\3DxNX.dll' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files (x86)' NUMBER_OF_PROCESSORS = '2' AVR32_HOME = 'C:\Program Files (x86)\Atmel\AVR Tools\AVR32 Toolchain' SESSIONNAME = 'Console' COMPUTERNAME = 'TEMPLEOFTHEDOG' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Installations (default) = '\??\D:\Software\cygwin' HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\D:\Software\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'D:\Software\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: d1d85fb7bc451065 Path: D:\Software\cygwin User: Key: d1d85fb7bc451065 Path: D:\Software\cygwi
Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected
> My testcases for asynchronous and deferred cancel work on threads > blocked in sem_wait() but still fail mostly on threads blocked in > read(STDIN_FILENO, ...), same as before. Sorry about that. I spoke too soon. There seems to be some kind of runtime decay and a dependency on semaphore.h. Running the same test or the two tests alternating works for about three times just as expected but further runs fail as before. A reboot fixes that and gives me another few chances. This only applies to read(). sem_wait() always works. If the test code includes semaphore.h but doesn’t even use any of its functions it fails right away, just like before. A reboot doesn’t help. It’s getting weirder by the day... Otto -- 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: 1.7.15-1: pthread_cancel and pthread_kill not working as expected
On May 24 12:35, Otto Meta wrote: > > My testcases for asynchronous and deferred cancel work on threads > > blocked in sem_wait() but still fail mostly on threads blocked in > > read(STDIN_FILENO, ...), same as before. Sorry about that. > > I spoke too soon. There seems to be some kind of runtime decay and a > dependency on semaphore.h. > > Running the same test or the two tests alternating works for about three > times just as expected but further runs fail as before. A reboot fixes > that and gives me another few chances. This only applies to read(). You know that Cygwin is just a user space DLL, right? There's no state information kept in the OS beyond the lifetime of any process using the Cygwin DLL. In case of pthreads, there's no state at all shared with other processes. But even if so, if you stop *all* Cygwin processes and then start another one, all info from the old processes is gone and you should be back to normal. If that's not the case, I would suspect a case of BLODA. > sem_wait() always works. > > If the test code includes semaphore.h but doesn’t even use any of its > functions it fails right away, just like before. A reboot doesn’t help. Is that with the same "read" testcases you sent two days ago? If so, I can't reproduce it. I ran both tests in a loop, with and without an additional semaphore.h, but to no avail. They both just work. This is under W7 on a dual-core machine. 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: Has anyone collected a summary of cygwin vs Windows 7 64 bit outstanding issues?
Thank you. We have not, to date, seen any messages about forking problems or dll loading problems. I presume, though, that other behaviors might also indicate this rebase action is needed? On Wed, May 23, 2012 at 3:12 PM, marco atzeri wrote: > /usr/share/doc/rebase/README -- Tcl - The glue of a new generation. http://wiki.tcl.tk/ Larry W. Virden http://www.facebook.com/lvirden/ Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. -- 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: "emacs -nw" hangs in a terminal
On 5/23/2012 12:02 PM, Corinna Vinschen wrote:
On May 23 11:56, Ken Brown wrote:
On 5/23/2012 10:15 AM, Corinna Vinschen wrote:
On May 23 08:00, Ken Brown wrote:
I don't know what this has to do with the longjmp, but the thread
which gets crated right after pressing Ctrl-G is due to a select or
poll call. The descriptor is a pipe, fifo, or pty.
After the longjmp, emacs has finished processing the C-g and goes
back into its idle loop, in which it repeatedly calls select.
gdb doesn't normally show the threads created by select. If it did,
it would always create voluminous output. Can you infer anything
from the fact that it shows this one?
The problem with stackdumps is that the addresses only make sense
for a single version of the Cygwin DLL. If that's a self-built
version, what does `addr2line -e /bin/cygwin1.dll 610CFA77' print?
If it's 1.7.15, please install the cygwin-debug package and call
the same addr2line.
I assume the address corresponds to select.cc, line 625, but I'm
quite busy with the pthread_cancel stuff, so I didn't look deeper
into this problem.
Yes, that's correct. (I'm using the 20120516 snapshot.)
eax=80106D50 ebx=34322D73 ecx=766231E7 edx= esi=0001
edi=0050
ebp=048FACC8 esp=048FACA0
program=C:\cygwin\home\kbrown\src\emacs\test-nox\src\emacs.exe, pid
6492, thread pipesel
^^^
Yes, that's exactly the created thread. Do you happen to know what
kind of descriptor has been given to select at this point? Is that
a pty master side perhaps?
Based on the emacs code, I think that's right. But maybe I need to
download the source for the snapshot I'm using (or build cygwin1.dll
myself) so that I can step through the first call to select after
the longjmp and see exactly where the crash is happening.
That would be most helpful. I don't grok this crash. It's one of
the "this should never possibly happen" kind...
I'm now using an unoptimized build of the 20120523 snapshot. The gdb
session is below. I first started emacs and started the shell process;
this guarantees that when emacs calls select, one of the descriptors is
a pty master. Then I attached gdb and put a breakpoint at the emacs
function unwind_to_catch, which is triggered when I press C-g. It took
two presses of C-g to get the crash. I think the rest is self-explanatory.
(gdb) b unwind_to_catch
Breakpoint 3 at 0x52aca2: file eval.c, line 1234.
(gdb) c
Continuing.
[Switching to Thread 860.0x2390]
Breakpoint 3, unwind_to_catch (catch=0x28a8d0, value=12929854) at
eval.c:1234
1234 catch->val = value;
(gdb) b thread_pipe
Breakpoint 4 at 0x610d871a: file
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc,
line 618.
(gdb) n
1237 set_poll_suppress_count (catch->poll_suppress_count);
[stepping through unwind_to_catch...]
1272 _longjmp (catch->jmp, 1);
(gdb)
[Switching to Thread 860.0x1d8c]
Breakpoint 4, thread_pipe (arg=0x80104d00)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:618
618 select_pipe_info *pi = (select_pipe_info *) arg;
(gdb) n
619 DWORD sleep_time = 0;
(gdb)
620 bool looping = true;
(gdb)
622 while (looping)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
627 if (peek_pipe (s, true))
(gdb)
629 if (pi->stop_thread)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
636 if (!looping)
(gdb)
638 Sleep (sleep_time >> 3);
(gdb)
639 if (sleep_time < 80)
(gdb)
640 ++sleep_time;
(gdb)
641 if (pi->stop_thread)
(gdb)
622 while (looping)
(gdb)
624 for (select_record *s = pi->start; (s = s->next); )
(gdb)
625 if (s->startup == start_thread_pipe)
(gdb)
627 if (peek_pipe (s, true))
(gdb)
629 if (pi->stop_thread)
(gdb)
631 select_printf ("stopping");
(gdb)
632 looping = false;
(gdb)
633 break;
(gdb)
636 if (!looping)
(gdb)
637 break;
(gdb)
644 return 0;
(gdb)
645 }
(gdb)
cygthread::callfunc (this=0x6119e080, issimplestub=false)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/cygthread.cc:53
53 }
(gdb) c
Continuing.
Breakpoint 4, thread_pipe (arg=0x80104cf0)
at
/home/kbrown/src/cygwin/cygwin-20120523-1/src/cygwin-snapshot-20120523-1/winsup/cygwin/select.cc:618
618 select_pipe_info *pi = (select_pipe_info *) arg;
(gdb) disable 4
(gdb) c
Continuing.
[Switching to Thread 860.0x2390]
Breakpoint 3, unwind_to_catch (catch=0x28a8d0, value=12996910) at
eval.c:1234
1234 catch->val = value;
Re: svn --version
On May 24 11:22, Denis Excoffier wrote:
> On Thu, May 24, 2012 at 10:12:02AM +0200, Corinna Vinschen wrote:
> >> On May 24 09:06, Denis Excoffier wrote:
> >> >
> >> > Hello,
> >> >
> >> > With the new subversion (1.7.5) and the last
> >> > snapshot (20120523 21:51:34), the command 'svn --version' produces
> >> > segmentation fault, with no svn.exe.stackdump produced:
> >> >
> >> > % /usr/bin/svn --version
> >> > Segmentation fault
> >> > %
> >>
> >> I just installed the latest subversion 1.7.5 and I can not reproduce
> >> this crash. svn --version prints the version information just fine with
> >> the latest snapshot DLL. I made sure I was really using the snapshot DLL,
> >> not my local debug version.
>
> I've decided to use rebase/rebaseall/autorebase. Until now, i had
> always run "Setup download" and "Setup install" separately, with removal
> of .../release/_autorebase/* between the two (and in addition, i
> had installed "exit 0" in line 2 of /bin/rebaseall).
??? Why? We never had so few reports about fork failures than after
we added the autorebase package.
> So, i made my installation completely standard, and first, i noticed
> that "xz -9e" does not work any more:
> % /usr/bin/xz -9e cygcheck.out
> /usr/bin/xz: cygcheck.out: Cannot allocate memory
Works fine for me with the latest snapshot.
> %
>
> Then i observed that 'svn --version' failed as before. And with
> the previous snapshot, it worked again. So no change with autorebasing.
Still works for me
> >>
> >> > % /usr/bin/env -i TZ=Europe/Monaco /usr/bin/date
> >> > Thu May 24 09:01:14 CEST 2012
> >> > % /usr/bin/env -i TZ=Europe/Monaco /usr/bin/strace /usr/bin/date >!
> >> > /dev/null
> >> >8773 [main] date 3248 D:\Home\dexcoff1\dexcoff1\cyg12c\bin\date.exe:
> >> > *** fatal error - internal error reading the windows environment - too
> >> > many environment variables?
> >> > 10625 [main] date 3248 open_stackdumpfile: Dumping stack trace to
> >> > date.exe.stackdump
Btw., what does the strace look like if you send the output to a file,
like this:
/usr/bin/strace -o date.trace /usr/bin/date
> >> That's a crash of some sorts while trying to convert the Windows
> >> environment to the Cygwin POSIX environment. Again, I can't reproduce
> >> this one with the latest snapshot and the latest 1.7.15 strace.
> I've this problem since many months before, perhaps even years. The
> same occurs now, after the system is autorebased.
This is very strange. I mean, I'm running strace on at least a daily
basis. I never saw such a problem. And your environment looks rather
small. Almost too small...
> >> For a start, please send your cygcheck -svr info. Did you try to see
> >> if manual rebaseing helps?
> % (cygcheck -s -v -r > cygcheck.out) >& cygcheck.err
> %
>
> Included both. What do you mean "manual rebaseing"? 'ldd svn' shows 45
> individual DLL...
I meant, running rebaseall from ash manually.
As for your cygcheck output, I only see a few uncommon things:
> Path: D:\Home\dexcoff1\dexcoff1\cyg12c\bin
> .
That's all? Where are the native Windows paths?
> !:: = '::\'
Where does that come from? I never saw a "=::" environment variable.
On the other hand, you have "!D:" but no "!C:". It is as if something
overwrote the 'C' in these strings for no apparent reason.
> TZ = '/tmp/lcl/uxl/tz/etc/zoneinfo/Europe/Paris'
"Europe/Paris" is sufficient, usually. But in theory it's not necessary
to set it manually, given that TZ is set using the tzset tool at startup
(see /etc/profile.d/tzset.{sh,csh}).
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: svn --version
On May 24 14:18, Corinna Vinschen wrote: > On May 24 11:22, Denis Excoffier wrote: > > On Thu, May 24, 2012 at 10:12:02AM +0200, Corinna Vinschen wrote: > > >> On May 24 09:06, Denis Excoffier wrote: > > >> > > > >> > Hello, > > >> > > > >> > With the new subversion (1.7.5) and the last > > >> > snapshot (20120523 21:51:34), the command 'svn --version' produces > > >> > segmentation fault, with no svn.exe.stackdump produced: > > >> > > > >> > % /usr/bin/svn --version > > >> > Segmentation fault > > >> > % > > >> > > >> I just installed the latest subversion 1.7.5 and I can not reproduce > > >> this crash. svn --version prints the version information just fine with > > >> the latest snapshot DLL. I made sure I was really using the snapshot > > >> DLL, > > >> not my local debug version. Never mind that. I *can* reproduce the problem. For some reason it only occurs on XP, not on W7. The other stuff you reported (xz, strace) still works, though. 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: Reading data from ttyS fails
On May 24 14:25, thunderboy42 wrote:
> I have an embedded system connectet with my PC which sends debug data over the
> rs232. A simple terminal program unter cygwin is used to analyze this data.
> before cygwin 1.7.10 evertything went fine, but now it seems, most transmitted
> characters get lost. even this simple example from wikibooks does not work
> anymore:
>
> ...
> memset(&tio,0,sizeof(tio));
> tio.c_iflag=0;
> tio.c_oflag=0;
> tio.c_cflag=CS8|CREAD|CLOCAL;
> tio.c_lflag=0;
> tio.c_cc[VMIN]=1;
> tio.c_cc[VTIME]=5;
>
> tty_fd=open("/dev/ttyS0", O_RDWR | O_NONBLOCK);
> cfsetospeed(&tio,B115200);// 115200 baud
> cfsetispeed(&tio,B115200);// 115200 baud
>
> tcsetattr(tty_fd,TCSANOW,&tio);
> while (c!='q')
> {
> if (read(tty_fd,&c,1)>0)write(STDOUT_FILENO,&c,1);
> }
> ...
>
> So what can I do?
Can you please create a simple testcase for reading from ttyS0
which can be compiled out of the box?
Thanks,
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: Performance problems with emacs-X11 in current cygwin.
On 5/24/2012 8:32 AM, Berglund Magnus (SE) wrote: After an cygwin-upgrade this morning I'm experiencing performance problems with emacs-X11 (23.4.2). The performance problem seem to be graphics related. Window redraw is really slow, it can take up to a couple of seconds to redraw the emacs window. Scrolling the cursor up or down in emacs is also painfully slow. Some other X programs I've tried does not seem to be affected. xemacs works just fine. I've tried a fresh cygwin install on a clean (vmware) machine running Windows XP. Still the same problem. I also tried downgrading both emacs (23.3-3) and xorg-server(1.12.0-5) without luck. There was a bunch of other packages upgrade at the same time, I've included the part of the setup.log which installed the packages that introduced the performance problem. I've noticed the same thing on my XP system but not on Windows 7. There have been similar reports from two other users, but they didn't say what version of Windows they were using: http://cygwin.com/ml/cygwin/2012-05/msg00287.html I'm afraid I don't have a clue what could be causing this or why it apparently only occurs on XP. Ken Brown Cygwin's emacs maintainer -- 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: bash.exe.stackdump generated using cygwin 1.7.15
Thanks a lot for the quick investigation of the problem. It looks you found some cygwin builds that fixed the problem . Is it possible to release a new version of cygwin package containing the fix ? I'm ready to try a beta version of the cygwin package containing the fix in the same environment where I recreated the problem. Ciao, Alessandro IBM Italia S.p.A. Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI) Cap. Soc. euro 347.256.998,80 C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153 Società con unico azionista Società soggetta all?attività di direzione e coordinamento di International Business Machines Corporation (Salvo che sia diversamente indicato sopra / Unless stated otherwise above) -- 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: Performance problems with emacs-X11 in current cygwin.
I can confirm that same issue is present with GVim on a Windows XP machine. The issue occurred after the last update (Gnome Libraries I believe). On Thu, May 24, 2012 at 8:51 AM, Ken Brown wrote: > On 5/24/2012 8:32 AM, Berglund Magnus (SE) wrote: >> >> After an cygwin-upgrade this morning I'm experiencing performance problems >> with emacs-X11 (23.4.2). The performance problem seem to be graphics >> related. Window redraw is really slow, it can take up to a couple of seconds >> to redraw the emacs window. Scrolling the cursor up or down in emacs is also >> painfully slow. Some other X programs I've tried does not seem to be >> affected. xemacs works just fine. >> >> I've tried a fresh cygwin install on a clean (vmware) machine running >> Windows XP. Still the same problem. >> I also tried downgrading both emacs (23.3-3) and xorg-server(1.12.0-5) >> without luck. There was a bunch of other packages upgrade at the same time, >> I've included the part of the setup.log which installed the packages that >> introduced the performance problem. > > > I've noticed the same thing on my XP system but not on Windows 7. There > have been similar reports from two other users, but they didn't say what > version of Windows they were using: > > http://cygwin.com/ml/cygwin/2012-05/msg00287.html > > I'm afraid I don't have a clue what could be causing this or why it > apparently only occurs on XP. > > Ken Brown > Cygwin's emacs maintainer > > -- > 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 > -- 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 --version
On May 24 14:36, Corinna Vinschen wrote: > On May 24 14:18, Corinna Vinschen wrote: > > On May 24 11:22, Denis Excoffier wrote: > > > On Thu, May 24, 2012 at 10:12:02AM +0200, Corinna Vinschen wrote: > > > >> On May 24 09:06, Denis Excoffier wrote: > > > >> > > > > >> > Hello, > > > >> > > > > >> > With the new subversion (1.7.5) and the last > > > >> > snapshot (20120523 21:51:34), the command 'svn --version' produces > > > >> > segmentation fault, with no svn.exe.stackdump produced: > > > >> > > > > >> > % /usr/bin/svn --version > > > >> > Segmentation fault > > > >> > % > > > >> > > > >> I just installed the latest subversion 1.7.5 and I can not reproduce > > > >> this crash. svn --version prints the version information just fine > > > >> with > > > >> the latest snapshot DLL. I made sure I was really using the snapshot > > > >> DLL, > > > >> not my local debug version. > > Never mind that. I *can* reproduce the problem. For some reason it > only occurs on XP, not on W7. I applied a patch. There was some pointer at process startup which was apparently always 0 on W7 while it could have a random value on XP. I changed the condition to check if we're still in process startup and that seems to work fine on W7 and XP. Boy, what a lot of problems with something which was supposeed to be a *temporary* workaround :( 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: 1.7.15-1: pthread_cancel and pthread_kill not working as expected
On 2012-05-24 13:19, Corinna Vinschen wrote: > You know that Cygwin is just a user space DLL, right? There's no state > information kept in the OS beyond the lifetime of any process using the > Cygwin DLL. In case of pthreads, there's no state at all shared with > other processes. Yes, that’s exactly why I’m confused about it. > But even if so, if you stop *all* Cygwin processes and then start > another one, all info from the old processes is gone and you should be > back to normal. If that's not the case, I would suspect a case of BLODA. Yes, I tried that and it changed nothing. I took the chance to uninstall some unused software and stopped all dodgy-sounding Windows services, including Windows Defender, so that the only thing left from the BLODA was the nVidia driver: No change. Rebasing also didn’t help. >> If the test code includes semaphore.h but doesn’t even use any of its >> functions it fails right away, just like before. A reboot doesn’t help. > Is that with the same "read" testcases you sent two days ago? If so, I > can't reproduce it. I ran both tests in a loop, with and without an > additional semaphore.h, but to no avail. They both just work. Yes, same tests (the ones blocking on read()), but the semaphore.h was probably unrelated after all. I also ran the tests continuously and discovered the following: Running the same test several times manually from a cmd shell works a few times, then fails. Running the async and deferred tests alternating from cmd works, even after they failed previously. Running one of the tests manually from bash fails most of the time. $ while :; do ./testcase_cancel_asynchronous; done First test run usually fails, further runs succeed. Same for the deferred testcase. $ sleep 1; while :; do ./testcase_cancel_asynchronous; done All test runs succeed, including the first one. Same for the deferred testcase. I am now convinced that my system is toying with me. As I actually don’t need to read from stdin with several threads and only discovered this problem while you fixed async cancel (thanks for that), I’m inclined to ignore this “problem” and stop wasting your time, unless you want me to try something else to debug this. > This is under W7 on a dual-core machine. Same here. Otto -- 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: 1.7.15-1: pthread_cancel and pthread_kill not working as expected
On May 24 17:03, Otto Meta wrote: > On 2012-05-24 13:19, Corinna Vinschen wrote: > > You know that Cygwin is just a user space DLL, right? There's no state > > information kept in the OS beyond the lifetime of any process using the > > Cygwin DLL. In case of pthreads, there's no state at all shared with > > other processes. > > Yes, that’s exactly why I’m confused about it. > > > But even if so, if you stop *all* Cygwin processes and then start > > another one, all info from the old processes is gone and you should be > > back to normal. If that's not the case, I would suspect a case of BLODA. > > Yes, I tried that and it changed nothing. I took the chance to uninstall > some unused software and stopped all dodgy-sounding Windows services, > including Windows Defender, so that the only thing left from the BLODA > was the nVidia driver: No change. > > Rebasing also didn’t help. > > >> If the test code includes semaphore.h but doesn’t even use any of its > >> functions it fails right away, just like before. A reboot doesn’t help. > > Is that with the same "read" testcases you sent two days ago? If so, I > > can't reproduce it. I ran both tests in a loop, with and without an > > additional semaphore.h, but to no avail. They both just work. > > Yes, same tests (the ones blocking on read()), but the semaphore.h was > probably unrelated after all. > > I also ran the tests continuously and discovered the following: > > Running the same test several times manually from a cmd shell works a > few times, then fails. Running the async and deferred tests alternating > from cmd works, even after they failed previously. > > Running one of the tests manually from bash fails most of the time. Weird. I tried under CMD now as well, but it still runs and runs and runs, without a failure. Tested on XP, W7, and 2008 R2. Another idea is that your system also fails due to the problem reported in http://cygwin.com/ml/cygwin/2012-05/msg00522.html I'm just about to generate another snapshot. You could see if that helps for some reason. I doubt it, but still... 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: svn --version
On Thu, May 24, 2012 at 04:51:08PM +0200, Corinna Vinschen wrote: >> On May 24 14:36, Corinna Vinschen wrote: >> > On May 24 14:18, Corinna Vinschen wrote: >> > > On May 24 11:22, Denis Excoffier wrote: >> > > > On Thu, May 24, 2012 at 10:12:02AM +0200, Corinna Vinschen wrote: >> > > > >> On May 24 09:06, Denis Excoffier wrote: >> > > > >> > >> > > > >> > Hello, >> > > > >> > >> > > > >> > With the new subversion (1.7.5) and the last >> > > > >> > snapshot (20120523 21:51:34), the command 'svn --version' produces >> > > > >> > segmentation fault, with no svn.exe.stackdump produced: >> > > > >> > >> > > > >> > % /usr/bin/svn --version >> > > > >> > Segmentation fault >> > > > >> > % >> > > > >> >> > > > >> I just installed the latest subversion 1.7.5 and I can not reproduce >> > > > >> this crash. svn --version prints the version information just fine >> > > > >> with >> > > > >> the latest snapshot DLL. I made sure I was really using the >> > > > >> snapshot DLL, >> > > > >> not my local debug version. >> > >> > Never mind that. I *can* reproduce the problem. For some reason it >> > only occurs on XP, not on W7. >> >> I applied a patch. There was some pointer at process startup which was >> apparently always 0 on W7 while it could have a random value on XP. >> I changed the condition to check if we're still in process startup and >> that seems to work fine on W7 and XP. >> >> Boy, what a lot of problems with something which was supposeed to be >> a *temporary* workaround :( The last snapshot (20120524 17:33:50) solves the 'svn --version' problem. Thanks. Regards, Denis Excoffier. -- 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: Reading data from ttyS fails
Hello Corinna,
I used a part from http://en.wikibooks.org/wiki/Serial_Programming/termios for
testting because my 'original' is a little bit complicated. (see the source at
the end)
But I think I found the problem in "fhandler_serial.cc". There was some code
added for leaving the method raw_read when there are no more chars received
and the serial port was opened in non blocking mode (code starting at line
86). But I think it would be a good idea to deliver the chars received until
then, so I build my own cygwin1.dll with the following changes in
fhandler_serial.cc:
88,94c88
- PurgeComm (get_handle (), PURGE_RXABORT);
- if (tot == 0)
- {
- tot = -1;
- set_errno (EAGAIN);
- }
- goto out;
---
+ break;
This works for me now.
Thanks, T.B.
#include
#include
#include
#include
#include
#include
int main(int argc,char** argv)
{
struct termios tio;
int tty_fd;
unsigned char c='D';
memset(&tio,0,sizeof(tio));
tio.c_iflag=0;
tio.c_oflag=0;
tio.c_cflag=CS8|CREAD|CLOCAL;
tio.c_lflag=0;
tio.c_cc[VMIN]=1;
tio.c_cc[VTIME]=5;
tty_fd=open("/dev/ttyS0", O_RDWR | O_NONBLOCK);
cfsetospeed(&tio,B115200);// 115200 baud
cfsetispeed(&tio,B115200);// 115200 baud
tcsetattr(tty_fd,TCSANOW,&tio);
while (c!='q')
{
if (read(tty_fd,&c,1)>0)write(STDOUT_FILENO,&c,1);
}
close(tty_fd);
}
--
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: 1.7.15-1: pthread_cancel and pthread_kill not working as expected
> Weird. I tried under CMD now as well, but it still runs and runs and > runs, without a failure. Tested on XP, W7, and 2008 R2. Maybe It’s Just Me then. > Another idea is that your system also fails due to the problem reported > in http://cygwin.com/ml/cygwin/2012-05/msg00522.html > I'm just about to generate another snapshot. You could see if that > helps for some reason. I doubt it, but still... No change. $ sleep 0.001; ./testcase_cancel_asynchronous Fails. $ sleep 0.1; ./testcase_cancel_asynchronous Succeeds. :-? Otto -- 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
Seteuid "operation not permitted" error when using LSA for sshd
Hi all, I have installed Cygwin and am running sshd successfully. The permission required for the sshd service account "create a token object" is not permitted to be granted to any accounts in my organization. As such I have decided to use LSA based on Method 2 on the following page: http://cygwin.com/cygwin-ug-net/ntsec.html. I had succesfully tested ssh authentication with a public/private certificate pair prior to running /usr/bin/cyglsa-config to install LSA. I ran the script, removed the "create a token object" permission and rebooted the server. Now I cannot authenticate using the public/private keys. I receive the following error in the Windows event log: sshd: PID 2780: fatal: seteuid 1003: Operation not permitted When I add the permission back to the service account and restart sshd the public/private key authentication works again Any help would be great Thanks, Mark -- 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
g++ can't find
I'm trying to build a package that uses Qt4. The build fails at #include with "No such file or directory". But /usr/include/qt4/QtGui/QtGui exists and -I/usr/include/qt4/QtGui is one of the flags for g++. What am I missing here? Bob T. -- 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: g++ can't find
On 2012-05-24 20:56, Bob Tennent wrote: I'm trying to build a package that uses Qt4. The build fails at #include with "No such file or directory". But /usr/include/qt4/QtGui/QtGui exists and -I/usr/include/qt4/QtGui is one of the flags for g++. What am I missing here? Specific information: namely, the package/version you're trying to build, the exact command that failed and the exact error message(s). Yaakov Cygwin/X -- 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: Bashrc distinguish between mintty and x-windows xterm
Buchbinder, Barry (NIH/NIAID) [E] niaid.nih.gov> writes:
>
> # Only set ThisTerm if not set.
> if [ -z "${ThisTerm}" ]
> then
> if [ ${PPID} = 1 ]
> then
> ThisTerm=cmd
> else
> if [ "$(cat /proc/${PPID}/exename)" = '/usr/bin/mintty' ]
> then
> ThisTerm=mintty
> else
> # not minty, not cmd, so xterm
> ThisTerm=xterm
> fi
> fi
> fi
>
> Then set colors by the value of ThisTerm.
Barry, it works flawlessly. Thanks immensely!
--
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: Performance problems with emacs-X11 in current cygwin.
Hi Ken, Ken Brown wrote: I've noticed the same thing on my XP I notice this, yesterday, after the upgrade announcede here: http://cygwin.com/ml/cygwin-xfree/2012-05/msg00040.html My builds of Emacs trunk, do not work any more correctly after the upgrade. Emacs is very very slow... Thi on XP, the only Windows I have... Ciao, Angelo. -- 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
