On 13/7/2011 12:55, Corinna Vinschen wrote:
Building Cygwin in debug mode and access to the source tree helps
a lot.
The only problem is that this crash only reproduce when compiling with -O2
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/f
On Jul 13 12:47, yoni levi wrote:
> On 13/7/2011 10:32, Corinna Vinschen wrote:
> >I still have
> >to point out, though, that I can not reproduce this problem. Neither
> >with a debug DLL, nor with an optimized DLL
> I managed to catch this inside gdb (run "gdb rxvt" from mintty).
> but the backtr
On 13/7/2011 10:32, Corinna Vinschen wrote:
I still have
to point out, though, that I can not reproduce this problem. Neither
with a debug DLL, nor with an optimized DLL
I managed to catch this inside gdb (run "gdb rxvt" from mintty).
but the backtrace seems useless to me.
Any ideas how to impr
On Jul 13 12:29, yoni levi wrote:
> On 13/7/2011 10:32, Corinna Vinschen wrote:
> >Please call addr2line for all addresses starting with 61. In the
> >above example that would be:
> >
> > $ addr2line -e /bin/cygwin1.dll 6100749B 61004EFC 61004F84 61006499
> >
>
> $ addr2line -e /bin/cygwin1.dll
On 13/7/2011 10:32, Corinna Vinschen wrote:
Please call addr2line for all addresses starting with 61. In the
above example that would be:
$ addr2line -e /bin/cygwin1.dll 6100749B 61004EFC 61004F84 61006499
$ addr2line -e /bin/cygwin1.dll 61116FEF 610C30EB 610C7605 0040524B
0040107B 610
On 13/7/2011 10:32, Corinna Vinschen wrote:
The access violation occurs inside the Cygwin DLL, but the address is
useless without the DLL. Since you built the DLL yourself, you would
have to look where this crash occurs. You should have a
rxvt.exe.stackdump file with function addresses, kind of
On Jul 13 09:32, Corinna Vinschen wrote:
> On Jul 12 15:31, yoni levi wrote:
> > now the 1_7_10 strace log
>
> > --- Process 3776, exception C005 at 61116FEF
> >67 4739866 [main] rxvt 3776 exception::handle: In cygwin_except_handler
> > exc 0xC005 at 0x61116FEF sp 0x22CAAC
> >59 4
On Jul 12 15:31, yoni levi wrote:
> now the 1_7_10 strace log
> --- Process 3776, exception C005 at 61116FEF
>67 4739866 [main] rxvt 3776 exception::handle: In cygwin_except_handler
> exc 0xC005 at 0x61116FEF sp 0x22CAAC
>59 4739925 [main] rxvt 3776 exception::handle: In cygwin_ex
On Jul 12 15:30, yoni levi wrote:
> On 12/7/2011 12:29, Corinna Vinschen wrote:
> >On Jul 12 10:31, yoni levi wrote:
> >>On 12/7/2011 10:23, Corinna Vinschen wrote:
> > I am also attaching strace.txt with the output of:
> > ~$ strace install a /etc/b
> >>>And it worked, didn't it? Your s
On 12/7/2011 16:18, Fergus wrote:
(People recommend mintty for 1.7 and probably with very good reasons,
but I still quite like rxvt.)
my rxvt does not hang, all rxvt windows just disappear.
with mintty it works perfectly.
--
Problem reports: http://cygwin.com/problems.html
FAQ:
>> Right. But rxvt crash.
> I have no such problems with rxvt.
Only incidental to the matters you have raised, but for what it's worth:
Not quite certain what you mean by "rxvt crash" but with 1.7 I have
repeatedly experienced "rxvt hang" - the rxvt session proceeds perfectly
well until Ctrl
On Jul 12 10:31, yoni levi wrote:
> On 12/7/2011 10:23, Corinna Vinschen wrote:
> >>> I am also attaching strace.txt with the output of:
> >>> ~$ strace install a /etc/b
> >And it worked, didn't it? Your strace looks normal, no exception occured.
> >
> >
> Right. But rxvt crash.
I have no such
On 12/7/2011 10:23, Corinna Vinschen wrote:
> I am also attaching strace.txt with the output of:
> ~$ strace install a /etc/b
And it worked, didn't it? Your strace looks normal, no exception occured.
Right. But rxvt crash.
bash.exe is still running though.
--
Problem reports:
On 12/7/2011 10:23, Corinna Vinschen wrote:
> I am also attaching strace.txt with the output of:
> ~$ strace install a /etc/b
And it worked, didn't it? Your strace looks normal, no exception occured.
Right. But rxvt crash.
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Jul 11 16:51, yoni levi wrote:
> On 11/7/2011 15:04, Corinna Vinschen wrote:
> >cygcheck -svr output as perhttp://cygwin.com/problems.html might give
> >some clue as well...
> >
>
> I am also attaching strace.txt with the output of:
> ~$ strace install a /etc/b
And it worked, didn't it? Your
On Jul 11 16:44, yoni levi wrote:
>
>
> >>Actually, I have not the faintest idea. Can you build your own Cygwin
> >>DLL without -O2, see if it still occurs, and run that scenario through
> >>GDB?
> >cygcheck -svr output as per http://cygwin.com/problems.html might give
> >some clue as well...
>
On Mon, Jul 11, 2011 at 12:14:22PM -0700, Marc Girod wrote:
>Christopher Faylor wrote:
>>
>> Actually, I think it is more likely BLODA.
>>
>The other standard reply (I am surprised not to read it in this thread) is
>rebaseall.
Doh. Good point.
Yes. What he said.
cgf
--
Problem reports:
every rebase will raise the base address where to load
injected DLLs.
Is this just fantasy and rain dancing?
[ A fork error with scp may get my system to hang so that I need to reboot ]
Marc
--
View this message in context:
http://old.nabble.com/Random-fork-failures-tp32035530p32040454.html
Sent f
On Mon, Jul 11, 2011 at 01:27:52PM -0400, Chris Sutcliffe wrote:
>On 11 July 2011 09:44, yoni levi wrote:
Actually, I have not the faintest idea. ?Can you build your own Cygwin
DLL without -O2, see if it still occurs, and run that scenario through
GDB?
>>>
>>> cygcheck -svr output as
On 11 July 2011 09:44, yoni levi wrote:
>>> Actually, I have not the faintest idea. Can you build your own Cygwin
>>> DLL without -O2, see if it still occurs, and run that scenario through
>>> GDB?
>>
>> cygcheck -svr output as per http://cygwin.com/problems.html might give
>> some clue as well...
On Jul 11 13:47, Corinna Vinschen wrote:
> On Jul 11 13:24, Yoni Londner wrote:
> > >
> > >WJFFM, both. There's something in your environment which isn't in mine.
> > >Did you set $CYGWIN?
> > >
> >
> > ~$ echo $CYGWIN
> > nodosfilewarning
>
> That's not the problem. It still works for me, with
Actually, I have not the faintest idea. Can you build your own Cygwin
DLL without -O2, see if it still occurs, and run that scenario through
GDB?
I am on it.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http:/
On Jul 11 13:24, Yoni Londner wrote:
> >
> >WJFFM, both. There's something in your environment which isn't in mine.
> >Did you set $CYGWIN?
> >
>
> ~$ echo $CYGWIN
> nodosfilewarning
That's not the problem. It still works for me, with the snapshot
as well as with CVS.
> That's a clean installa
That's a clean installation. what can cause this kind of crashes?
I tried again with cygwin1.dll from latest snapshot
(http://cygwin.org/snapshots/cygwin1-20110711.dll.bz2)
I am not sure if this will be helpful, but these are the md5sum for the
relevant files:
~$ md5sum /usr/bin/install /us
WJFFM, both. There's something in your environment which isn't in mine.
Did you set $CYGWIN?
~$ echo $CYGWIN
nodosfilewarning
That's a clean installation. what can cause this kind of crashes?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/
On Jul 11 12:27, Yoni Londner wrote:
> On 11/7/2011 12:02, Corinna Vinschen wrote:
> >I tested both scripts on W7 32 and 2K8R2 against the latest snapshot,
> >as well as against self-built current Cygwin CVS, built with and without
> >optimization. Both scripts run fine in all scenarios.
> >
> on
I did a little investigation - when the process hangs, I took the
backtrace with process explorer.
Process explorer does not know anything about cygwin debug symbols, so
it just give an arbitrary func + offset.
Then I used gdb to find out the real function: sync_proc_pipe doing
yield in an endle
On 11/7/2011 12:02, Corinna Vinschen wrote:
I tested both scripts on W7 32 and 2K8R2 against the latest snapshot,
as well as against self-built current Cygwin CVS, built with and without
optimization. Both scripts run fine in all scenarios.
on a clean cygwin installation (1.7.9) and new cygwin1
On Jul 11 11:36, Yoni Londner wrote:
> >
> >>I will appreciate any advice, how can I solve this problem.
> >
> >Simple, self-contained testcases, preferredly in plain C, or simple
> >scripts in case the problem only occurs in a script language, which
> >allow to reproduce the problem. Those would
Example 1:
#!/usr/bin/perl
use POSIX qw(getcwd);
getcwd();
1;
Example 2:
#!/usr/bin/perl
use Scalar::Util qw(looks_like_number);
looks_like_number("1");
1;
Both end up with:
Segmentation fault (core dumped)
Well, I tried these two examples on a clean cygwin installation, with
new cygwin1.d
I will appreciate any advice, how can I solve this problem.
Simple, self-contained testcases, preferredly in plain C, or simple
scripts in case the problem only occurs in a script language, which
allow to reproduce the problem. Those would be most helpful.
Corinna
Example 1:
#!/usr/bin/p
On Jul 11 11:07, yoni levi wrote:
> Hi,
>
> We have a problem with fork for a very long time.
> From time to time, fork just hangs (with 2 process doing busy loop).
> The problem occurs when we do allot of spawns (make system).
> It is very easy to recreate the problem, but unfortunately, there is
Hi,
We have a problem with fork for a very long time.
From time to time, fork just hangs (with 2 process doing busy loop).
The problem occurs when we do allot of spawns (make system).
It is very easy to recreate the problem, but unfortunately, there is too
much code involve to send.
I did a li
33 matches
Mail list logo
