chitecture and then other docs to "drill down" to the
details on certain areas. I've always been amazed by what Cygwin does.
Daniel
On 12/9/19 4:22 AM, Corinna Vinschen wrote:
> On Dec 9 01:12, Daniel Santos wrote:
>> Hello,
>>
>> I see that when you copy Cygwin executables
Hello,
I see that when you copy Cygwin executables (and dlls) to a random
windows machine and run (for example) bash.exe that Cygwin treats the
parent directory as the root, assigns it an 8-byte serial number and
records it in the user registry. Can somebody point me to where the
code is that
Hello Marco,
On 11/30/19 4:23 AM, Marco Atzeri wrote:
> Am 30.11.2019 um 06:44 schrieb Daniel Santos:
>> Hello all,
>>
>> I'm trying to troubleshoot an issue with an old version of rsync on
>> Cygwin. Is there a git repo somewhere with historical patches? The
>
Hello all,
I'm trying to troubleshoot an issue with an old version of rsync on
Cygwin. Is there a git repo somewhere with historical patches? The
version in question is 3.0.4. This is on a remote machine that I can't
change, so I'm trying to decipher what I can from the logs.
Thanks,
Daniel
On 04/24/2017 10:38 AM, Corinna Vinschen wrote:
I'm going with my patch for now. Mainly because I added some debug
output to see if we need the Sleep loop at all. Right now I don't see
any situation which would qualify for this.
Thanks,
Corinna
Thanks for your help on this Corinna!
I'm
On 04/24/2017 07:19 AM, Corinna Vinschen wrote:
Hi Daniel,
On Apr 24 04:37, Daniel Santos wrote:
The root cause of problem with strace causing long delays when any
process enumerates the process database appears to be calling
myself.thisproc () from child_info_spawn::handle_spawn() when we've
I finally found a solution and submitted a patch, but I don't know if
it's the correct fix or not.
Daniel
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
processes dynamically load cygwin1.dll and, thus,
what other side-effects that this may have. Please verify correctness.
Please see discussion here: https://cygwin.com/ml/cygwin/2017-04/msg00240.html
Daniel
Signed-off-by: Daniel Santos <daniel.san...@pobox.com>
---
winsup/cygwin/dcrt0.cc | 3
On 04/24/2017 02:00 AM, Mark Geisert wrote:
Excellent debugging work! I'm inclined to agree with your last
point. I'm poring over pinfo.cc as well as dcrt0.cc, which is the
Cygwin DLL init code. The latter talks about special cases if the DLL
is runtime loaded (like strace does) vs
Well, waiting for GNU/Linux tests to run, so I had a little more time to
play with this.
On 04/23/2017 02:42 AM, Mark Geisert wrote:
Daniel Santos wrote:
Well thank you, I wish I had read this earlier. I've been trying to
debug (with
gdb) strace (following children) and now I know why
Unfortunately, I don't have much time to spend on this issue as the gcc8
stage1 has started and I have a few more issues to clear up with my
patchset.
On 04/23/2017 02:42 AM, Mark Geisert wrote:
Anyway, I can see that the strace process's shared _pinfo object is
never fully
populated:
On 04/21/2017 05:12 PM, Mark Geisert wrote:
Re debugging strace itself, you may not realize that strace is not a
Cygwin-native program. It's a Windows-native program. So debugging
it with Cygwin gdb is problematic.
I can tell you roughly how strace operates. It launches the target
On 04/21/2017 04:38 AM, Mark Geisert wrote:
I can reproduce your issue on a real Win7.64 machine so that removes
any possible virtual machine root cause. I was running 'top -s1' in
one window while running your testcase in another window. Yes, top
froze for many seconds at a time, then
I've tracked it down to this little Sleep() loop in pinfo::init.
bool created = shloc != SH_JUSTOPEN;
/* Detect situation where a transitional memory block is being
retrieved.
If the block has been allocated with PINFO_REDIR_SIZE but not yet
updated with a PID_EXECED
On 04/20/2017 09:38 PM, Daniel Santos wrote:
I usually disable most services, I can probably disable a few more
Actually, I was wrong as I had re-enabled a lot of services to try some
ms debugging tools, but I've pared it down to these and the problem
still happens:
C:\Users\daniel>
On 04/20/2017 08:43 AM, Gluszczak, Glenn wrote:
I haven't run Cygwin Expect for about 6 moths on Windows but it was behaving
fine last time I did.
One thing I am aware of is you can't interrupt sleep in TCL. The sleep must
complete until the Control C is processed (regardless of whether you
On 04/20/2017 03:45 AM, Corinna Vinschen wrote:
Yes, it's a write-only mail address. Please send stuff only to the
respective mailing list.
Oh, I see. Thanks for the clarification.
Daniel
Well I've solved one problem, but now I have another one. To try to
understand why except is getting broken pipes (child processes are
"going away"), I modified DejaGNU's /usr/bin/runtest so that it would
strace each except process:
-exec "$expectbin" $debug -- "$runpath"/runtest.exp $target
On 04/19/2017 05:10 PM, Daniel Santos wrote:
Thanks. I hope this message goes through. Earlier when I tried to
respond with both you and cygwin-patches in the To: header it bounced.
I emailed cygwin-ow...@cygwin.com about this, is that the right
address for mailing list problems?
Actually
Will this bounce again?
On 04/19/2017 01:48 PM, Corinna Vinschen wrote:
Pushed.
Thanks,
Corinna
Thanks. I hope this message goes through. Earlier when I tried to
respond with both you and cygwin-patches in the To: header it bounced. I
emailed cygwin-ow...@cygwin.com about this, is that the right address
for
Recent versions of gcc are optimizing away the TLS buffer allocated in
main, so we need to tell gcc that it's really used. RtlSecureZeroMemory
accomplishes this while also inlining the memset.
Signed-off-by: Daniel Santos <daniel.san...@pobox.com>
---
winsup/utils/strace.cc | 2 +-
On 04/18/2017 05:04 AM, Corinna Vinschen wrote:
On Apr 17 03:39, Daniel Santos wrote:
I actually did try that, although I had guessed it wouldn't (and shouldn't)
work. I believe that the reason is that rather the accesses are volatile or
not, gcc can see nothing else using it and memset can
On 04/16/2017 05:21 AM, Jon Turney wrote:
On 15/04/2017 23:27, Daniel Santos wrote:
Recent versions of gcc are optimizing away the TLS buffer allocated in
main, so we need to tell gcc that it's really used.
---
winsup/utils/strace.cc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/winsup
Recent versions of gcc are optimizing away the TLS buffer allocated in
main, so we need to tell gcc that it's really used.
---
winsup/utils/strace.cc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/winsup/utils/strace.cc b/winsup/utils/strace.cc
index beab67b90..1e581b4a4 100644
---
Well here's the problem, gcc got too smart and optimized out the stack
buffer.
int
main (int argc, char **argv)
{
4074c0: 56 push %rsi
4074c1: 53 push %rbx
4074c2: 48 83 ec 28 sub$0x28,%rsp
4074c6: 89
On 04/14/2017 10:49 PM, Dan Kegel wrote:
On Fri, Apr 14, 2017 at 8:41 PM, Daniel Santos <daniel.san...@pobox.com> wrote:
oops, I meant -g3 :)
That was suboptimal of you
/me ducks
lol!
/me swings
/me ducks
/me misses, damn!
strace ls doesn't die for me with plain old cygwin ins
I didn't have cygwin1.dll built with -O3,
oops, I meant -g3 :)
--
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
Is anybody else getting this problem? I'm using Windows 7 pro that's
fully updated. At least I'm getting the crash consistently now, even
when debugging. I didn't have cygwin1.dll built with -O3, so I had to
experiment to find the thread local storage. If I've done in correctly,
then it
I'm hacking expect to try to solve its "broken pipe" problem, but I
haven't done any serious windows programming/debugging in over 10
years. I want to be able to set some type of "trap" after a fork (on
the child) and then disable it before it calls execvp to catch any
crashes or normal
I should probably import this onto my github account. There doesn't
appear to be an actual repository for expect at the moment. There are
many terrible coding practices employed, potential use of uninitialized
locals, etc. I'm going to do some basic cleanup before I dig back into
trying to
I got the crash again (when trying to do something else of course). So
here is the complete backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x771fc3bc in KERNEL32!GetVolumePathNamesForVolumeNameW () from
/c/Windows/system32/kernel32.dll
(gdb) bt
#0 0x771fc3bc
This is a silly one because I ran gdb --args strace ls and it doesn't
crash. Then I ran 'gdb --args strace strace ls' and it crashed in gdb
ONCE! However, I don't usually work on Cygwin/Windows so I think gdb
loaded up the wrong debug info and/or source files. I built
cygwin-newlib from git
On 03/17/2017 12:17 AM, Brian Inglis wrote:
On 2017-03-16 14:59, Daniel Santos wrote:
Alright, I think I've got it now, thank you. I'll experiment with it
first and then I'm guessing that this might eventually belong in
libtool or some such, although I'm guessing that that wouldn't work
unless
When I build my own machine, I prefer to set my own default prompt in
/etc/profile.d. This makes it easier on me, but still allows other
users to set whatever prompt they please. This line in bash.bashrc
incorrectly clobbers whatever prompt is set in /etc/profile.d.
Signed-off-by: Daniel Santos
On 03/15/2017 02:36 PM, Brian Inglis wrote:
Do the local rebase on your build targets as detailed in my question
to Achim and his response. Rerun after any system change or build.
Alright, I think I've got it now, thank you. I'll experiment with it
first and then I'm guessing that this might
On 03/13/2017 12:25 PM, Marco Atzeri wrote:
The risk of collision is very low on 64 bit.
It is higher on 32 bit but as gcc don't depend on other libraries,
I don't expect that to happen.
If happens you can rebase in tree before running the tests,
providing the list of new dll to rebase.
I used
On 03/10/2017 12:56 PM, Achim Gratz wrote:
Brian Inglis writes:
Ensure that all Cygwin dlls including anything you build are included
in every rebase, and do an incremental rebase after every build.
Don't do this, it's not what incremental rebase is for. I've
specifically implemented the
Thanks for the help Brian.
On 03/09/2017 05:51 PM, Brian Inglis wrote:
Windows DLLs updated or added could increase in size and overlap
Cygwin's assumed address space allocated by rebase.
Mingw has no problem as native Windows programs, but Cygwin emulates
how Unix uses shared libraries
First off, thanks for your response and I apologize for my late reply.
On 03/09/2017 06:21 PM, Brian Inglis wrote:
On 2017-03-09 15:58, Daniel Santos wrote:
This is just a minor annoyance. When I start a mintty session and
even if I type bash -l or basy -li, I don't get my /etc/profile
sourced
This is just a minor annoyance. When I start a mintty session and even
if I type bash -l or basy -li, I don't get my /etc/profile sourced and I
have to manually do it each time I log in. Any idea what's causing that?
Possibly related, sshd doesn't seem to be reading my
First of all, thank you for your response!
On 03/08/2017 02:21 AM, Brian Inglis wrote:
After any Windows Update, or a lot of package installs, you may want
look at running
rebase-trigger full[rebase]
before rebooting to remove all Cygwin and Windows processes, then
(with no Cygwin
On 03/07/2017 06:36 PM, David Billinghurst wrote:
On 8/03/2017 10:25, Daniel Santos wrote:
My concern is with the dynamic portion of this behavior -- what is
affected by environment variables.
Many years ago I ran a nightly build/test of gcc under cygwin and
reported the results to gcc
On 03/07/2017 07:58 AM, cyg Simple wrote:
On 3/6/2017 9:03 PM, Daniel Santos wrote:
On 03/05/2017 05:08 AM, David Billinghurst wrote:
No.
LD_LIBRARY_PATH is used by dlopen ().
PATH is one of the locations searched by Windows when starting
applications, see https://msdn.microsoft.com/en-us
On 03/05/2017 05:08 AM, David Billinghurst wrote:
No.
LD_LIBRARY_PATH is used by dlopen ().
PATH is one of the locations searched by Windows when starting
applications, see https://msdn.microsoft.com/en-us/library/7d83bc18.aspx
Thank you for this clarification. So load-time dlls are
Is this a documentation error then? (from
https://cygwin.com/cygwin-ug-net/setup-env.html)
The LD_LIBRARY_PATH environment variable is used by the Cygwin function
dlopen () as a list of directories to search for .dll files to
load. This
environment variable is converted from
Seeing how this means that gcc testsuite results are useless for
exposing regressions in gcc libraries, I've opened a gcc bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79867
Daniel
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 03/04/2017 09:46 PM, JonY wrote:
Cygwin does NOT use LD_LIBRARY_PATH, Cygwin uses PATH like all Windows
programs. It is one aspect that does not conform to *nix expectations.
Wonderful, this simplifies it greatly! I was wondering why the dlls
were under /usr/bin. :) Anyway, I'm waiting
HAH! Well I hadn't actually subscribed to the mailing list and decided
to check the archive to see if anybody replied only to the list. (I'm
subscribed now)
> In order to test gfortran 7.1 without installing, you will need to copy
> cyggfortran-4.dll into a folder which is on LD_LIBRARY_PATH.
Hello. I'm trying to validate a gcc patchset that affects msabi
functions, so I need good test results on Cygwin, but my unpatched tests
are getting hundreds of failures for which I cannot determine the cause.
I'm running Cygwin 64 bit on Windows 7 in a qemu vm (with kvm). My
sources are on a
cygwin (as in the base cygwin package) is missing /lib/libdl.a. The
install for the cygwin package should create a symlink with this name
that links to libcygwin.a in the same directory. Otherwise, builds for
a lot of different software packages are broken. Example is bash-3.1.
It will die
51 matches
Mail list logo
