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: http://cygw
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 link-tim
Daniel Santos wrote:
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 no
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 the debu
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:
_pinfo
Daniel Santos wrote:
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 launche
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
progr
Daniel Santos wrote:
Thanks for the help Mark. My current suspicion is that the _pinfo isn't getting
initialized when the process is exec-ed by strace, but I haven't proved that. I
added a dump() member function to _pinfo, but it crashes and I can't seem to
debug that in gdb (it makes a stacktr
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 caug
Daniel Santos wrote:
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
update
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 stat
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>net star
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 red
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 redirected
signals
to your own routines). Otherw
14 matches
Mail list logo
