Re: Snapshot 20040225: make hangs/errors out

[Christopher Faylor]

On Mon, Mar 08, 2004 at 11:37:48AM -0500, Rolf Campbell wrote:
>Christopher Faylor wrote:
I made a fix last night that allowed me to run this for 2500+
iterations.  Of course, I have managed to do that before without error,
so that doesn't mean much, I guess.  Backing the change out resulted in
a 'virtual memory exhausted' error in less than a hundred iterations,
however.  Odd that I can duplicate it so readily now.  I think my
computer was previously trying to shield me from the pain of debugging
this problem.

There is a new snapshot up now with my fix in it.  Please try it.
>>>
>>>Sigh.  Literally two minutes after sending this email, the "make -j"
>>>test that I was running at home errored out with a different error.
>>>
>>>Back to the drawing board...
>>
>>Hmm.  I can't duplicate the failure I saw so maybe it would still be
>>instructive to see how the current snapshot works for others.
>>
>>Please send test results here.
>
>'06 snapshot, froze after 128 iterations (0% cpu, no error output).
>I've attached the end of the strace output.  I will run it a few more
>times to make sure this is consistant.

If you want to analyze the strace yourself and offer comment, then
please do so.  Sending strace snippets is normally useless.  99% of the
time, people send the equivalent of a photo of an accident scene with
the thought that the picture will show why the accident occurred, i.e.,
the strace snippet is worthless.  I gave up trying to inspect
unsolicited strace output a long time ago.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Rolf Campbell]

Christopher Faylor wrote:
I made a fix last night that allowed me to run this for 2500+
iterations.  Of course, I have managed to do that before without error,
so that doesn't mean much, I guess.  Backing the change out resulted in
a 'virtual memory exhausted' error in less than a hundred iterations,
however.  Odd that I can duplicate it so readily now.  I think my
computer was previously trying to shield me from the pain of debugging
this problem.
There is a new snapshot up now with my fix in it.  Please try it.
Sigh.  Literally two minutes after sending this email, the "make -j"
test that I was running at home errored out with a different error.
Back to the drawing board...


Hmm.  I can't duplicate the failure I saw so maybe it would still be
instructive to see how the current snapshot works for others.
Please send test results here.

cgf

'06 snapshot, froze after 128 iterations (0% cpu, no error output).
I've attached the end of the strace output.  I will run it a few more 
times to make sure this is consistant.

-Rolf

**
Program name: C:\cygwin\bin\sh.exe (2884)
  248   43520 [main] uname 2816 writev: writev (1, 0x22EEB0, 1)
App version:  1005.8, api: 0.111
   96   43616 [main] uname 2816 fhandler_base::write: binary write
DLL version:  1005.8, api: 0.111
  118   43734 [main] uname 2816 fhandler_base::write: 14 = write 
(0xA040280, 14)
DLL build:20040306 23:59:38SNP
  107   43841 [main] uname 2816 writev: 14 = write (1, 0x22EEB0, 1), 
errno 0
OS version:   Windows NT-5.1
 9827 1053360 [proc] make 2168 proc_subproc: args: 2, 1
  170   44011 [main] uname 2816 close: close (1)
Heap size:1073741824
  154 1053514 [proc] make 2168 proc_subproc: pid 4080[1] terminated, 
handle 0x674, nchildren 3, nzombies 3
  151   44162 [main] uname 2816 fhandler_base::close: closing 
'/tmp/cygwin/freeze.1' handle 0x6E8
Date/Time:2004-03-08 11:18:11
**
  151 1053665 [proc] make 2168 proc_subproc: zombifying [1], pid 4080, 
handle 0x674, nchildren 3
  131   44293 [main] uname 2816 close: 0 = close (1)
  103 1053768 [proc] make 2168 proc_subproc: returning 1
   77 1053845 [proc] make 2168 sig_send: sendsig 0x70C, pid 2168, 
signal 20, its_me 1
  2891133 [main] sh 2884 events_init: windows_system_directory 
'C:\WINDOWS\System32\', windows_system_directory_length 20
  243   44536 [main] uname 2816 do_exit: do_exit (0), exit_state 0
  132 1053977 [proc] make 2168 sig_send: Not waiting for sigcomplete. 
its_me 1 signal 20
   99   44635 [main] uname 2816 void: 0x0 = signal (20, 0x1)
  1421275 [main] sh 2884 _cygwin_istext_for_stdio: fd 0: opened as 
binary
  108 1054085 [proc] make 2168 sig_send: returning 0x0 from sending 
signal 20
   65   44700 [main] uname 2816 void: 0x0 = signal (1, 0x1)
   90   44790 [main] uname 2816 void: 0x0 = signal (2, 0x1)
  133 1054218 [proc] make 2168 wait_subproc: looping
  1501425 [main] sh 2884 _cygwin_istext_for_stdio: fd 1: opened as 
binary
   51   44841 [main] uname 2816 void: 0x0 = signal (3, 0x1)
  134 1054352 [sig] make 2168 sigpacket::process: signal 20 processing
  129   44970 [main] uname 2816 fhandler_base::close: closing 
'/tmp/cygwin/freeze.1.err' handle 0x738
  1511576 [main] sh 2884 _cygwin_istext_for_stdio: fd 2: opened as 
binary
   70 1054422 [sig] make 2168 _cygtls::find_tls: sig 20
   94 1054516 [sig] make 2168 sigpacket::process: signal 20, about to 
call 0x40C540
  144   45114 [main] uname 2816 sigproc_terminate: entering
   54 1054570 [sig] make 2168 setup_handler: trying to send sig 20 but 
signal 20 already armed
   61 1054631 [sig] make 2168 setup_handler: signal 20 not delivered
  149   45263 [sig] uname 2816 wait_sig: done
   49 1054680 [sig] make 2168 sigpacket::process: returning 0
   62   45325 [sig] uname 2816 _cygtls::remove: wait 0x0
   76 1054756 [sig] make 2168 proc_subproc: args: 3, 0
   60 1054816 [sig] make 2168 proc_subproc: looking for processes to reap
   71 1054887 [sig] make 2168 proc_subproc: finished processing 
terminated/stopped child
  173   45498 [main] uname 2816 proc_terminate: nchildren 0, nzombies 0
   50 1054937 [sig] make 2168 proc_subproc: returning 1
  112   45610 [main] uname 2816 proc_terminate: leaving
  716   46326 [main] uname 2816 __to_clock_t: dwHighDateTime 0, 
dwLowDateTime 156250
   60   46386 [main] uname 2816 __to_clock_t: total  000F
   51   46437 [main] uname 2816 __to_clock_t: dwHighDateTime 0, 
dwLowDateTime 312500
   50   46487 [main] uname 2816 __to_clock_t: total  001F
 17633339 [main] sh 2884 parse_options: error_start (called func)
  1003439 [main] sh 2884 parse_options: returning
   523491 [main] sh 2884 pinfo_init: pid 2884, pgid 2168
  4193910 [main] sh 2884 sigproc_init: process/signal handling 
enabled(C1)
   783988 [main] sh 2884 dll_crt0_1: user_data->main 0x4081F0
   604048 [main] sh 2884 wait_for_sigthread: wait_sig_inited 0x750
  2424290 [sig]

Re: Snapshot 20040225: make hangs/errors out

[Christopher Faylor]

On Fri, Mar 05, 2004 at 02:38:01PM -0500, Christopher Faylor wrote:
>On Fri, Mar 05, 2004 at 02:33:52PM -0500, Christopher Faylor wrote:
>>I think I may have figured this out.
>>
>>It wasn't the eax register being zeroed.  It was actually the test for
>>zero returning improper values due to being interrupted by a signal.
>>
>>I made a fix last night that allowed me to run this for 2500+
>>iterations.  Of course, I have managed to do that before without error,
>>so that doesn't mean much, I guess.  Backing the change out resulted in
>>a 'virtual memory exhausted' error in less than a hundred iterations,
>>however.  Odd that I can duplicate it so readily now.  I think my
>>computer was previously trying to shield me from the pain of debugging
>>this problem.
>>
>>There is a new snapshot up now with my fix in it.  Please try it.
>
>Sigh.  Literally two minutes after sending this email, the "make -j"
>test that I was running at home errored out with a different error.
>
>Back to the drawing board...

Hmm.  I can't duplicate the failure I saw so maybe it would still be
instructive to see how the current snapshot works for others.

Please send test results here.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Christopher Faylor]

On Fri, Mar 05, 2004 at 02:33:52PM -0500, Christopher Faylor wrote:
>I think I may have figured this out.
>
>It wasn't the eax register being zeroed.  It was actually the test for
>zero returning improper values due to being interrupted by a signal.
>
>I made a fix last night that allowed me to run this for 2500+
>iterations.  Of course, I have managed to do that before without error,
>so that doesn't mean much, I guess.  Backing the change out resulted in
>a 'virtual memory exhausted' error in less than a hundred iterations,
>however.  Odd that I can duplicate it so readily now.  I think my
>computer was previously trying to shield me from the pain of debugging
>this problem.
>
>There is a new snapshot up now with my fix in it.  Please try it.

Sigh.  Literally two minutes after sending this email, the "make -j"
test that I was running at home errored out with a different error.

Back to the drawing board...

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Christopher Faylor]

On Thu, Mar 04, 2004 at 10:59:48AM -0500, Christopher Faylor wrote:
>On Wed, Mar 03, 2004 at 09:14:28PM -0500, Christopher Faylor wrote:
>>On Wed, Mar 03, 2004 at 06:16:55PM -0500, Rolf Campbell wrote:
>>>Christopher Faylor wrote:
>>No, but I'll try to catch one.  (I removed the strace from my script.)
>
>Ok, caught two already.  (Produced with attached script + Makefile)

Not much to there, unfortunately.

Out of curiousity, can you duplicate this problem with the snapshot?  I
see that this is your own build, probably built with
--enable-debugging.

I've been diligently testing things with the snapshot rather than my
own build because I was trying to debug what was in the subject.
Snapshots aren't built with --enable-debugging.  If this is just an
artifact from building with --enable-debugging, then I'm not too
worried.
>>>
>>>Ok, I've been running the script with the '25 snapshot all day, with 44
>>>failures.  All the same type of failures I was seeing with the cvs
>>>(with --enable-debugging).  Unfortunitely, the ethernet card on my home
>>>machine broke so for now I'll upload one of the strace files to a
>>>geocites site.  Nothing looks suspicious to me in the strace, maybe
>>>it's a bug in make?  http://www.geocities.com/endlisnis/Temp/freeze.zip
>>
>>Thanks.  Unfortunately, I don't see anything more here than in the other
>>strace output.
>>
>>I did manage to duplicate this after 1437 repetitions or so.  My strace
>>didn't show anything either, unfortunately, but now maybe I can slowly
>>get to the bottom of the problem.
>
>Weird.  Now that I've managed to duplicate it, I can do so at will.  I
>guess that's good news.
>
>I see what is causing the symptom but not what is causing the problem.
>I spent a sleepless night modelling multi-threaded signal interrupts
>in my head but I'm still not any closer to understanding the problem.
>
>The problem is that malloc allocates some memory, puts the address of
>the memory in the eax register, and then returns.  In the meantime, two
>signals have come in, so rather than return immediately, malloc returns
>to the signal handler and then the signal handler is called again.  In
>some cases, this causes the eax register to become zero and so make
>(rightly) complains.  In theory, this shouldn't happen since the eax
>register should have been saved on the stack.
>
>Nope.  Typing an explanation doesn't help me figure this out.  Bummer.

I think I may have figured this out.

It wasn't the eax register being zeroed.  It was actually the test for
zero returning improper values due to being interrupted by a signal.

I made a fix last night that allowed me to run this for 2500+
iterations.  Of course, I have managed to do that before without error,
so that doesn't mean much, I guess.  Backing the change out resulted in
a 'virtual memory exhausted' error in less than a hundred iterations,
however.  Odd that I can duplicate it so readily now.  I think my
computer was previously trying to shield me from the pain of debugging
this problem.

There is a new snapshot up now with my fix in it.  Please try it.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Brian Ford]

On Thu, 4 Mar 2004, Brian Ford wrote:

> Um..., stupid question.  As usual, I haven't thought about this much, or
> traced it too far yet, but...
>
> __sigbe begins by pushing ebx, edx, and eax.  It ends by poping just eax
> and edx.  Why don't you need to pop ebx?
>
Never mind, I see the restore.  I'm still not sure the stack pointer is
right, but I haven't done x86 assembly is many years, and I don't know
what you are doing.

BTW, the stab for sigfe has a typo, I think (__sigbe, instead of __sigfe).

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Brian Ford]

Um..., stupid question.  As usual, I haven't thought about this much, or
traced it too far yet, but...

__sigbe begins by pushing ebx, edx, and eax.  It ends by poping just eax
and edx.  Why don't you need to pop ebx?

On Thu, 4 Mar 2004, Christopher Faylor wrote:

> I see what is causing the symptom but not what is causing the problem.
> I spent a sleepless night modelling multi-threaded signal interrupts
> in my head but I'm still not any closer to understanding the problem.
>
> The problem is that malloc allocates some memory, puts the address of
> the memory in the eax register, and then returns.  In the meantime, two
> signals have come in, so rather than return immediately, malloc returns
> to the signal handler and then the signal handler is called again.  In
> some cases, this causes the eax register to become zero and so make
> (rightly) complains.  In theory, this shouldn't happen since the eax
> register should have been saved on the stack.
>
> Nope.  Typing an explanation doesn't help me figure this out.  Bummer.
>

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Christopher Faylor]

On Wed, Mar 03, 2004 at 09:14:28PM -0500, Christopher Faylor wrote:
>On Wed, Mar 03, 2004 at 06:16:55PM -0500, Rolf Campbell wrote:
>>Christopher Faylor wrote:
>No, but I'll try to catch one.  (I removed the strace from my script.)

Ok, caught two already.  (Produced with attached script + Makefile)
>>>
>>>Not much to there, unfortunately.
>>>
>>>Out of curiousity, can you duplicate this problem with the snapshot?  I
>>>see that this is your own build, probably built with
>>>--enable-debugging.
>>>
>>>I've been diligently testing things with the snapshot rather than my
>>>own build because I was trying to debug what was in the subject.
>>>Snapshots aren't built with --enable-debugging.  If this is just an
>>>artifact from building with --enable-debugging, then I'm not too
>>>worried.
>>
>>Ok, I've been running the script with the '25 snapshot all day, with 44
>>failures.  All the same type of failures I was seeing with the cvs
>>(with --enable-debugging).  Unfortunitely, the ethernet card on my home
>>machine broke so for now I'll upload one of the strace files to a
>>geocites site.  Nothing looks suspicious to me in the strace, maybe
>>it's a bug in make?  http://www.geocities.com/endlisnis/Temp/freeze.zip
>
>Thanks.  Unfortunately, I don't see anything more here than in the other
>strace output.
>
>I did manage to duplicate this after 1437 repetitions or so.  My strace
>didn't show anything either, unfortunately, but now maybe I can slowly
>get to the bottom of the problem.

Weird.  Now that I've managed to duplicate it, I can do so at will.  I
guess that's good news.

I see what is causing the symptom but not what is causing the problem.
I spent a sleepless night modelling multi-threaded signal interrupts
in my head but I'm still not any closer to understanding the problem.

The problem is that malloc allocates some memory, puts the address of
the memory in the eax register, and then returns.  In the meantime, two
signals have come in, so rather than return immediately, malloc returns
to the signal handler and then the signal handler is called again.  In
some cases, this causes the eax register to become zero and so make
(rightly) complains.  In theory, this shouldn't happen since the eax
register should have been saved on the stack.

Nope.  Typing an explanation doesn't help me figure this out.  Bummer.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Christopher Faylor]

On Wed, Mar 03, 2004 at 06:16:55PM -0500, Rolf Campbell wrote:
>Christopher Faylor wrote:
No, but I'll try to catch one.  (I removed the strace from my script.)
>>>
>>>Ok, caught two already.  (Produced with attached script + Makefile)
>>
>>Not much to there, unfortunately.
>>
>>Out of curiousity, can you duplicate this problem with the snapshot?  I
>>see that this is your own build, probably built with
>>--enable-debugging.
>>
>>I've been diligently testing things with the snapshot rather than my
>>own build because I was trying to debug what was in the subject.
>>Snapshots aren't built with --enable-debugging.  If this is just an
>>artifact from building with --enable-debugging, then I'm not too
>>worried.
>
>Ok, I've been running the script with the '25 snapshot all day, with 44
>failures.  All the same type of failures I was seeing with the cvs
>(with --enable-debugging).  Unfortunitely, the ethernet card on my home
>machine broke so for now I'll upload one of the strace files to a
>geocites site.  Nothing looks suspicious to me in the strace, maybe
>it's a bug in make?  http://www.geocities.com/endlisnis/Temp/freeze.zip

Thanks.  Unfortunately, I don't see anything more here than in the other
strace output.

I did manage to duplicate this after 1437 repetitions or so.  My strace
didn't show anything either, unfortunately, but now maybe I can slowly
get to the bottom of the problem.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Rolf Campbell]

Christopher Faylor wrote:

No, but I'll try to catch one. (I removed the strace from my script.)
Ok, caught two already. (Produced with attached script + Makefile)


Not much to there, unfortunately.

Out of curiousity, can you duplicate this problem with the snapshot?  I see
that this is your own build, probably built with --enable-debugging.
I've been diligently testing things with the snapshot rather than my own
build because I was trying to debug what was in the subject.  Snapshots
aren't built with --enable-debugging.  If this is just an artifact from
building with --enable-debugging, then I'm not too worried.
cgf
Ok, I've been running the script with the '25 snapshot all day, with 44 
failures.  All the same type of failures I was seeing with the cvs (with 
--enable-debugging).  Unfortunitely, the ethernet card on my home 
machine broke so for now I'll upload one of the strace files to a 
geocites site.  Nothing looks suspicious to me in the strace, maybe it's 
a bug in make?
http://www.geocities.com/endlisnis/Temp/freeze.zip

What I did notice is that I'm getting a tonne of failures "make: *** 
virtual memory exhausted.  Stop."  grep'ing through the make source 
(which I was unable to compile) I see that this can happen when malloc 
returns NULL (makes sense from the message), and I can say that my 
machine has plenty of memory left.  1Gig of ram, and my commit charge 
never exheaded 500Megs during the whole test.  I have my 
'heap_chunk_in_mb' set to 1024.

-Rolf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Volker Quetschke]

I just stopped the scrip and replaced my selfbuild cygwin1.dll ( with
debugging ) with the 20040225 snapshot.
OK, I already got four make errors with the 20040225 snapshot. Shall
I post the strace files?
Volker

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D


signature.asc
Description: OpenPGP digital signature

Re: Snapshot 20040225: make hangs/errors out

[Volker Quetschke]

Do you actually have an strace which demonstrates the problem?  I
don't any indication that you've duplicated this problem running
strace with a "modern" snapshot.
No, but I'll try to catch one. (I removed the strace from my script.)
Ok, caught two already. (Produced with attached script + Makefile)
Not much to there, unfortunately.

Out of curiousity, can you duplicate this problem with the snapshot?  I see
that this is your own build, probably built with --enable-debugging.
I just stopped the scrip and replaced my selfbuild cygwin1.dll ( with
debugging ) with the 20040225 snapshot.
I've been diligently testing things with the snapshot rather than my own
build because I was trying to debug what was in the subject.  Snapshots
aren't built with --enable-debugging.  If this is just an artifact from
building with --enable-debugging, then I'm not too worried.
We'll see. Actually I got a lot of make errors in my run since
yesterday. The use of strace seemed to increase the "error rate".
I got 18 make errors + strace file since yesterday, but that
was the selfbuild dll with debugging.
Volker

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D


signature.asc
Description: OpenPGP digital signature

Re: Snapshot 20040225: make hangs/errors out

[Christopher Faylor]

On Tue, Mar 02, 2004 at 11:37:25AM -0500, Volker Quetschke wrote:
Are you still using this script:

export C=1 while strace -o strace.$C.txt make -j ; do C=$(($C+1)) ;
done echo Failed after $C runs

If yes: The strace catches the errors.  I use a script without strace
and the while catches the error of the make command.
>>>
>>>
>>>Do you actually have an strace which demonstrates the problem?  I
>>>don't any indication that you've duplicated this problem running
>>>strace with a "modern" snapshot.
>>
>>No, but I'll try to catch one. (I removed the strace from my script.)
>Ok, caught two already. (Produced with attached script + Makefile)

Not much to there, unfortunately.

Out of curiousity, can you duplicate this problem with the snapshot?  I see
that this is your own build, probably built with --enable-debugging.

I've been diligently testing things with the snapshot rather than my own
build because I was trying to debug what was in the subject.  Snapshots
aren't built with --enable-debugging.  If this is just an artifact from
building with --enable-debugging, then I'm not too worried.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Volker Quetschke]

Are you still using this script:

export C=1 while strace -o strace.$C.txt make -j ; do C=$(($C+1)) ;
done echo Failed after $C runs
If yes: The strace catches the errors.  I use a script without strace
and the while catches the error of the make command.


Do you actually have an strace which demonstrates the problem?  I
don't any indication that you've duplicated this problem running
strace with a "modern" snapshot.
No, but I'll try to catch one. (I removed the strace from my script.)
Ok, caught two already. (Produced with attached script + Makefile)

make: *** virtual memory exhausted.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
Failed after 18 runs
corresponds to:

and

make: *** virtual memory exhausted.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
Failed after 6 runs
corresponds to:

I used cygwin1.dll with debugging build 20040225 and the make.exe
you (cgf) send me.
cygcheck output is somewhere in this thread.

Volker

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D
SHELL   = /bin/sh

testuname: 0.pp 1.pp 2.pp 3.pp 4.pp 5.pp 6.pp 7.pp 8.pp 9.pp 10.pp 11.pp 12.pp 13.pp 
14.pp 15.pp 16.pp 17.pp 18.pp 19.pp 20.pp 21.pp 22.pp 23.pp 24.pp 25.pp 26.pp 27.pp 
28.pp 29.pp 30.pp

%.pp::
: Begin $@ ${C}
@uname
: End $@ ${C}
#!/bin/bash
#export CYGWIN=error_start:gdb

export D=1

while [ $D -le 100 ] ; do
echo Loop $D

export C=1

logname=freeze.$D
logerr=${logname}.err

q=""
while [ "$q" != "stop" ] ; do
 strace -o strace.out make -j -f MakefileV > $logname 2>> $logerr
 C=$(($C+1))
 if [ -s $logerr ]; then q="stop" ; fi
done

echo Failed after $C runs >> $logerr
mv strace.out strace.out.$D
if [ -f make.exe.stackdump ]; then mv make.exe.stackdump make.exe.stackdump.$D ; fi
D=$(($D+1))

done

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Brian Ford]

On Tue, 2 Mar 2004, Igor Pechtchanski wrote:

> Brian,
>
> It must be late in the day -- $((a+b)) is bash syntax, not ash...  You
> need to change your script to have '#!/bin/bash' or use `expr a + b`.
>   Igor
>
Thanks Igor.  I knew it had to be something stupid.

FWIW, I first tried the script verbatum from the original bug report.  It
had no #! line, and I thought that might be a problem.  I went through
several iterations of no #!, #!/bin/sh, #!/bin/bash, and even `expr $C +
1`, so I knew about that issue.  It must be too late in the day for me, as
this stuff always happens to me around quiting time :).

I'm still seeing "weirdness", but I'll have to poke around a lot more to
accurately define it.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Igor Pechtchanski]

On Tue, 2 Mar 2004, Brian Ford wrote:

> Ok, I haven't been following this thread, but I thought I'd try to help
> debug.  Somebody tell me if I found a clue, or I'm just being stupid.
>
> Under a current, debugging enabled, cvs compiled cygwin1.dll:
>
> $ uname -a
> CYGWIN_NT-5.1 fordpc 1.5.8(0.111/4/2) 2004-03-02 12:22 i686 unknown
> unknown Cygwin
>
> using the attached b.sh script and Makefile, I see the following output:
>
> [snip]
> : End 30.pp 1
> : Begin 0.pp † 1+1‡
> [snip]
> : End 30.pp † 1+1‡
> : Begin 0.pp † † 1+1‡+1‡
> [etc]
>
> hence, the env dump in the script.  Is it just too late in the day for me,
> or is there environment corruption at play here?
>
> This is very easy to reproduce, and it changes with minor changes to the
> script.

Brian,

It must be late in the day -- $((a+b)) is bash syntax, not ash...  You
need to change your script to have '#!/bin/bash' or use `expr a + b`.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Volker Quetschke]

Are you still using this script:

export C=1 while strace -o strace.$C.txt make -j ; do C=$(($C+1)) ;
done echo Failed after $C runs
If yes: The strace catches the errors.  I use a script without strace
and the while catches the error of the make command.
Do you actually have an strace which demonstrates the problem?  I
don't any indication that you've duplicated this problem running
strace with a "modern" snapshot.
No, but I'll try to catch one. (I removed the strace from my script.)

Volker

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D


signature.asc
Description: OpenPGP digital signature

Re: Snapshot 20040225: make hangs/errors out

[Brian Ford]

Ok, I haven't been following this thread, but I thought I'd try to help
debug.  Somebody tell me if I found a clue, or I'm just being stupid.

Under a current, debugging enabled, cvs compiled cygwin1.dll:

$ uname -a
CYGWIN_NT-5.1 fordpc 1.5.8(0.111/4/2) 2004-03-02 12:22 i686 unknown
unknown Cygwin

using the attached b.sh script and Makefile, I see the following output:

[snip]
: End 30.pp 1
: Begin 0.pp † 1+1‡
[snip]
: End 30.pp † 1+1‡
: Begin 0.pp † † 1+1‡+1‡
[etc]

hence, the env dump in the script.  Is it just too late in the day for me,
or is there environment corruption at play here?

This is very easy to reproduce, and it changes with minor changes to the
script.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444SHELL   = /bin/sh

testuname: 0.pp 1.pp 2.pp 3.pp 4.pp 5.pp 6.pp 7.pp 8.pp 9.pp 10.pp 11.pp 12.pp 13.pp 
14.pp 15.pp 16.pp 17.pp 18.pp 19.pp 20.pp 21.pp 22.pp 23.pp 24.pp 25.pp 26.pp 27.pp 
28.pp 29.pp 30.pp

%.pp::
: Begin $@ ${C}
@sleep 1
: End $@ ${C}
#!/bin/sh

export C=1
while make -j; do C=$(($C+1)) ; env > env.txt; done
echo Failed after $C runs
!C:=C:\cygwin\bin
ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\ford\Application Data
C=† † 1+1‡+1‡
COLORFGBG=15;default;0
COLORTERM=rxvt-xpm
COMMONPROGRAMFILES=C:\Program Files\Common Files
COMPUTERNAME=FORDPC
COMSPEC=C:\WINDOWS\system32\cmd.exe
CUST=/vss/ems/env8/common
CVSROOT=:pserver:[EMAIL PROTECTED]:/home/vsslib/CVS
CVS_RSH=/bin/ssh
DISPLAY=:0
EMS=/vss/ems
ENV_PATH=/home/ford/env://thing1/db_release9/commercial/demo://thing1/db_release9/commercial/europe_env://thing1/db_release9/commercial/japan_env://thing1/db_release9/commercial/asia_env://thing1/db_release9/commercial/north_amer_env://thing1/db_release9/commercial/south_amer_env://thing1/db_release9/commercial/models://thing1/db_release9/commercial/test_align://thing1/db_release9/commercial/helicopter://thing1/db_release9/commercial/common
HOME=/home/ford
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\ford
HOSTNAME=fordpc
INFOPATH=/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:
LOGONSERVER=\\FORDPC
MAKE_MODE=unix
MANPATH=/usr/X11R6/man:/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man
NUMBER_OF_PROCESSORS=2
OLDPWD=/home/ford
ORIG_CDPATH=.:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program
 Files/ATI Technologies/ATI Control Panel:/usr/bin
ORIG_PATH=.:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program
 Files/ATI Technologies/ATI Control Panel:/usr/bin
OS=Windows_NT
PATH=.:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program
 Files/ATI Technologies/ATI Control 
Panel:/usr/bin:/home/ford/v9win2/tap:/vss/ems/bin:/home/ford/vsslib
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PKG_CONFIG_PATH=:/usr/X11R6/lib/pkgconfig
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 9, GenuineIntel
PROCESSOR_LEVEL=15
PROCESSOR_REVISION=0209
PROGRAMFILES=C:\Program Files
PROMPT=$P$G
PS1=\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ 
PWD=/home/ford/bug_testing/ht
RTCVSBIN=/home/ford/vsslib
SESSIONNAME=Console
SHELL=/bin/bash
SHLVL=1
SYSTEMDRIVE=C:
SYSTEMROOT=C:\WINDOWS
TAP=/home/ford/v9win2/tap
TEMP=/cygdrive/c/DOCUME~1/ford/LOCALS~1/Temp
TERM=xterm
TEXMF={/usr/share/lilypond/2.0.1,/usr/share/texmf}
TMP=/cygdrive/c/DOCUME~1/ford/LOCALS~1/Temp
USER=ford
USERDOMAIN=FORDPC
USERNAME=ford
USERPROFILE=C:\Documents and Settings\ford
WINDIR=C:\WINDOWS
WINDOWID=168034472
XAPPLRESDIR=/home/ford/v9win2/tap/app-defaults
_=./b.sh
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Rolf Campbell]

Christopher Faylor wrote:
On Tue, Mar 02, 2004 at 02:27:33PM -0500, Volker Quetschke wrote:

I can reproduce with that snapshot, but I get slightly different
results.  Here is the stderr output from 1052 runs, but the strange
thing is that even when I get errors, the task continues to run.  It
seems somehow that the return code of the errored run gets lost or
something.
Are you still using this script:

export C=1 while strace -o strace.$C.txt make -j ; do C=$(($C+1)) ;
done echo Failed after $C runs
If yes: The strace catches the errors.  I use a script without strace
and the while catches the error of the make command.


Do you actually have an strace which demonstrates the problem?  I
don't any indication that you've duplicated this problem running
strace with a "modern" snapshot.
I have reproduced the problem with a recent snapshot ('25), and strace, 
but I am only using a single strace output file, so it keeps going and 
over-writes the errored strace with the next run.  I will run it tonight 
while preserving all strace logs, but I can only run for about 1500 
iterations before I fill my disk.  I hope it happens before that.

Is there any way to tell strace to mimic the return code of it's 
inferior process?

-Rolf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Christopher Faylor]

On Tue, Mar 02, 2004 at 02:27:33PM -0500, Volker Quetschke wrote:
>>I can reproduce with that snapshot, but I get slightly different
>>results.  Here is the stderr output from 1052 runs, but the strange
>>thing is that even when I get errors, the task continues to run.  It
>>seems somehow that the return code of the errored run gets lost or
>>something.
>
>Are you still using this script:
>
>export C=1 while strace -o strace.$C.txt make -j ; do C=$(($C+1)) ;
>done echo Failed after $C runs
>
>If yes: The strace catches the errors.  I use a script without strace
>and the while catches the error of the make command.

Do you actually have an strace which demonstrates the problem?  I
don't any indication that you've duplicated this problem running
strace with a "modern" snapshot.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Volker Quetschke]

Hi!

I can reproduce with that snapshot, but I get slightly different 
results.  Here is the stderr output from 1052 runs, but the strange 
thing is that even when I get errors, the task continues to run.  It 
seems somehow that the return code of the errored run gets lost or 
something.
Are you still using this script:

export C=1
while strace -o strace.$C.txt make -j ; do C=$(($C+1)) ; done
echo Failed after $C runs
If yes: The strace catches the errors. I use a script without
strace and the while catches the error of the make command.
Volker

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D


signature.asc
Description: OpenPGP digital signature

Re: Snapshot 20040225: make hangs/errors out

[Christopher Faylor]

On Mon, Mar 01, 2004 at 03:12:18PM -0500, Rolf Campbell wrote:
>I can reproduce with that snapshot, but I get slightly different 
>results.

As long as we're comparing results, I might as well mention that I've
been running this on a Windows 2000 SP4 system since Friday without
interruption.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Rolf Campbell]

I can reproduce with that snapshot, but I get slightly different 
results.  Here is the stderr output from 1052 runs, but the strange 
thing is that even when I get errors, the task continues to run.  It 
seems somehow that the return code of the errored run gets lost or 
something.  This is different than how the '21 snapshot worked on my 
machine.

make: *** virtual memory exhausted.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** virtual memory exhausted.  Stop.
make: *** Waiting for unfinished jobs
make: *** virtual memory exhausted.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** virtual memory exhausted.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
@: not found
make: *** virtual memory exhausted.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
2840238 [main] make 1392 handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
2850856 [main] make 1392 open_stackdumpfile: Dumping stack trace to 
make.exe.sta ckdump
make: *** virtual memory exhausted.  Stop.
make: *** Waiting for unfinished jobs
make: *** virtual memory exhausted.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** virtual memory exhausted.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs

Volker Quetschke wrote:
Trapping this errors is a bit tedious, at the moment I'm using
the attached script to catch the errors, but instead of a new
stackdump/gdb prompt I got a new record, 2559 iterations until
reaching an error.


OK, enough! The script run since yesterday, with the debugging
enabled make.exe and cygwin1.dll.
I got:

Thu Feb 26 17:11:34 EST 2004
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 2048 runs
MakefileV:6: *** unterminated variable reference.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
Failed after 294 runs
make: -c: Command not found
make: *** [28.pp] Error 127
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
Failed after 256 runs
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 1857 runs
make: -c: Command not found
make: *** [14.pp] Error 127
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
Failed after 5356 runs
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 1387 runs
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
Failed after 211 runs
make: *** wait: No children.  Stop.
make: *** Waiting for unfinished jobs
make: *** wait: No children.  Stop.
Failed after 887 runs
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 690 runs
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 1459 runs
c: c: No such file or directory
make: *** [9.pp] Error 127
make: *** Waiting for unfinished jobs
Failed after 6226 runs
Stopped the the script at iteration 563.

No stackdump.

Any ideas? This takes way to long to reproduce.

I never run this script with cygwin 1.5.5 maybe it fails there too.
Maybe the freezes I got building OOo are long fixed and this was
always broken?
Or sh (ash) or even make has a problem and not cygwin. This
gets us nowhere.
Volker


Exception: STATUS_ACCESS_VIOLATION at eip=0040DC0B
eax=0002 ebx=0A067DA0 ecx=6574783D edx=0001 esi=0A05CA88 edi=0A069A28
ebp=0022E478 esp=0022E470 program=C:\cygwin\bin\make.exe
cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function  Args
0022E478  0040DC0B  (0A067DA0, 0022E4AC, 0001, )
0022E4C8  0040C91E  (, , 0A05C860, 610C8A9F)
0022E508  0040D77B  (0A05D3A8, 0003, , )
0022E578  00419E15  (0A05D3A8, 0002, , 0002)
0022E598  00418FCA  (0A05D3A8, 0002, 0022E5C8, 004010DF)
0022E5E8  0041AADF  (0A05D3A8, 0001, 0001, )
0022E658  0041A2F7  (0A05CA10, 0001, , 0A05CA10)
0022E678  00418FCA  (0A05CA10, , 0022E6B8, 61055BB7)
0022E6C8  00418C8F  (0A0602F0, , 0022EF58, )
0022F080  0041146E  (0002, 0A040B48, 0A0400A8, 61005A20)
0022F0D0  61005EB4  (0022F0E8, 0024, 002448E8,

Re: Snapshot 20040225: make hangs/errors out

[Volker Quetschke]

Trapping this errors is a bit tedious, at the moment I'm using
the attached script to catch the errors, but instead of a new
stackdump/gdb prompt I got a new record, 2559 iterations until
reaching an error.
OK, enough! The script run since yesterday, with the debugging
enabled make.exe and cygwin1.dll.
I got:

Thu Feb 26 17:11:34 EST 2004
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 2048 runs
MakefileV:6: *** unterminated variable reference.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
Failed after 294 runs
make: -c: Command not found
make: *** [28.pp] Error 127
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
Failed after 256 runs
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 1857 runs
make: -c: Command not found
make: *** [14.pp] Error 127
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
Failed after 5356 runs
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 1387 runs
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
make: *** Waiting for unfinished jobs
Failed after 211 runs
make: *** wait: No children.  Stop.
make: *** Waiting for unfinished jobs
make: *** wait: No children.  Stop.
Failed after 887 runs
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 690 runs
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 1459 runs
c: c: No such file or directory
make: *** [9.pp] Error 127
make: *** Waiting for unfinished jobs
Failed after 6226 runs
Stopped the the script at iteration 563.

No stackdump.

Any ideas? This takes way to long to reproduce.

I never run this script with cygwin 1.5.5 maybe it fails there too.
Maybe the freezes I got building OOo are long fixed and this was
always broken?
Or sh (ash) or even make has a problem and not cygwin. This
gets us nowhere.
Volker

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Volker Quetschke]

And, just for completeness, I built and ran a CVS version from about 
an hour ago, and it has not failed yet (350 iterations).  So, maybe 
someone already fixed this problem after Feb21.
No, not for me. I'm using the same version, see my other mail, but it
seems very hard to trigger the problem.
I tried to use "uname" instead of sleep 1. This doesn't seem to
fail either (752 iterations).
Boom. Error after 832 runs.

$ ./u.sh > freezeU.out
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 832 runs
Volker

Oh, come to think of it, I did get that error once with the Feb14th 
snapshot, after about 1500 runs.  But my latter attempt ran for over 
10,000 so I didn't mention it.  And I've never seen it since.

And I'm still running the CVS with sleep 1, and it's > 1000 iterations 
without any problems.  I will run it overnight tonight just for kicks.
I changed the 30 *.pp to 100 *.pp, but that makes it even harder to
trigger the problem:
$ ./u.sh > freezeU.out
./u.sh: line 6:  2796 Segmentation fault  (core dumped) make -j -f
MakefileU
Failed after 415 runs
*20040225 snapshot*

The 20040225 makes it easier again, with 30 *.pp and uname in
the Makefile I got:
$ time ./v.sh > freezeV.out
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 216 runs
real18m14.455s
user12m55.730s
sys 10m30.990s
Volker

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Christopher Faylor]

On Thu, Feb 26, 2004 at 09:50:12AM -0500, Volker Quetschke wrote:
>And, just for completeness, I built and ran a CVS version from about 
>an hour ago, and it has not failed yet (350 iterations).  So, maybe 
>someone already fixed this problem after Feb21.

No, not for me. I'm using the same version, see my other mail, but it
seems very hard to trigger the problem.

I tried to use "uname" instead of sleep 1. This doesn't seem to
fail either (752 iterations).
>>>
>>>Boom. Error after 832 runs.
>>>
>>>$ ./u.sh > freezeU.out
>>>make: *** wait: Interrupted system call.  Stop.
>>>make: *** Waiting for unfinished jobs
>>>Failed after 832 runs
>>>
>>>Volker
>>>
>>Oh, come to think of it, I did get that error once with the Feb14th 
>>snapshot, after about 1500 runs.  But my latter attempt ran for over 
>>10,000 so I didn't mention it.  And I've never seen it since.
>>
>>And I'm still running the CVS with sleep 1, and it's > 1000 iterations 
>>without any problems.  I will run it overnight tonight just for kicks.
>
>I changed the 30 *.pp to 100 *.pp, but that makes it even harder to
>trigger the problem:
>
>$ ./u.sh > freezeU.out
>./u.sh: line 6:  2796 Segmentation fault  (core dumped) make -j -f
>MakefileU
>Failed after 415 runs
>
>*20040225 snapshot*
>
>The 20040225 makes it easier again, with 30 *.pp and uname in
>the Makefile I got:
>
>$ time ./v.sh > freezeV.out
>make: *** wait: Interrupted system call.  Stop.
>make: *** Waiting for unfinished jobs
>Failed after 216 runs
>
>real18m14.455s
>user12m55.730s
>sys 10m30.990s

You're imagining things.  There were not changes in the last snapshot
which would affect this in any way.

You can't draw conclusions from one run.

And, btw, when you get a SEGV, please send the resulting stackdump file.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Volker Quetschke]

(cvs from 20040225)
I changed the 30 *.pp to 100 *.pp, but that makes it even harder to
trigger the problem:
$ ./u.sh > freezeU.out
./u.sh: line 6:  2796 Segmentation fault  (core dumped) make -j -f
MakefileU
Failed after 415 runs
*20040225 snapshot*

The 20040225 makes it easier again, with 30 *.pp and uname in
the Makefile I got:
$ time ./v.sh > freezeV.out
make: *** wait: Interrupted system call.  Stop.
make: *** Waiting for unfinished jobs
Failed after 216 runs
You're imagining things.  There were not changes in the last snapshot
which would affect this in any way.
You can't draw conclusions from one run.
Yes, I should know better than to draw conclusions from one run.
(The second run is still running (>600 iterations now))
And, btw, when you get a SEGV, please send the resulting stackdump file.
I still had the one from yesterday, it is attached.

Volker

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D
Exception: STATUS_ACCESS_VIOLATION at eip=0040528F
eax= ebx=00424990 ecx= edx= esi=0040E7D5 edi=10028520
ebp=0022E398 esp=0022E300 program=C:\cygwin\bin\make.exe
cs=001B ds=0023 es=0023 fs=0038 gs= ss=0023
Stack trace:
Frame Function  Args
0022E398  0040528F  (, 0040E7D5, , )
0022E3B8  00405831  (0040E7D5, 100182B0, 0022E3E8, 00405AE1)
0022E3C8  004058FB  (0040E7D5, 1001B4C8, 0002, 0022E410)
0022E3E8  00405AE1  (0040E7D5, 1001B4C8, , )
0022E428  0040E82C  (10032FE9, 0022E474, 1001B4C8, 10031AFC)
0022E488  0040D03A  (10031AE0, 0022E4BC, 0001, )
0022E4D8  0040C957  (, , 10019340, 610CEEBF)
0022E518  0040D77B  (1001B6D8, 0003, , )
0022E588  00419E15  (1001B6D8, 0002, , 0002)
0022E5A8  00418FCA  (1001B6D8, 0002, 0022E5D8, 004010DF)
0022E5F8  0041AADF  (1001B6D8, 0001, 0001, )
0022E668  0041A2F7  (100195E8, 0001, , 100195E8)
0022E688  00418FCA  (100195E8, , 0022E6C8, 61059252)
0022E6D8  00418C8F  (1001EE08, , 0022EF68, )
0022F090  0041146E  (0004, 616A6334, 100100A8, 0022F0E8)
0022F0D0  610066BD  (0022F0E8, , 0038, 77FA3694)
End of stack trace (more stack frames may be present)
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Christopher Faylor]

On Thu, Feb 26, 2004 at 10:42:56AM -0500, Volker Quetschke wrote:
>(cvs from 20040225)
>>>I changed the 30 *.pp to 100 *.pp, but that makes it even harder to
>>>trigger the problem:
>>>
>>>$ ./u.sh > freezeU.out
>>>./u.sh: line 6:  2796 Segmentation fault  (core dumped) make -j -f
>>>MakefileU
>>>Failed after 415 runs
>>>
>>>*20040225 snapshot*
>>>
>>>The 20040225 makes it easier again, with 30 *.pp and uname in
>>>the Makefile I got:
>>>
>>>$ time ./v.sh > freezeV.out
>>>make: *** wait: Interrupted system call.  Stop.
>>>make: *** Waiting for unfinished jobs
>>>Failed after 216 runs
>>
>>You're imagining things.  There were not changes in the last snapshot
>>which would affect this in any way.
>>
>>You can't draw conclusions from one run.
>Yes, I should know better than to draw conclusions from one run.
>(The second run is still running (>600 iterations now))
>
>>And, btw, when you get a SEGV, please send the resulting stackdump file.
>I still had the one from yesterday, it is attached.

Oh well.  It's a make stackdump but it makes no sense.

Thanks for sending it, anyway.

Can I send you a new version of make with debugging symbols?

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Snapshot 20040225: make hangs/errors out

[Volker Quetschke]

And, btw, when you get a SEGV, please send the resulting stackdump file.
I still had the one from yesterday, it is attached.
Oh well.  It's a make stackdump but it makes no sense.

Thanks for sending it, anyway.

Can I send you a new version of make with debugging symbols?
Sure. Does it make sense to use a cygwin dll with debugging
enabled? I bet so, I'll use your debugging make and cygwin1.dll
with debugging enabled for future tests.
Volker

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D


signature.asc
Description: OpenPGP digital signature

Re: Snapshot 20040225: make hangs/errors out

[Volker Quetschke]

Can I send you a new version of make with debugging symbols?
Sure. Does it make sense to use a cygwin dll with debugging
enabled? I bet so, I'll use your debugging make and cygwin1.dll
with debugging enabled for future tests.
Trapping this errors is a bit tedious, at the moment I'm using
the attached script to catch the errors, but instead of a new
stackdump/gdb prompt I got a new record, 2559 iterations until
reaching an error.
Volker

--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D
#!/bin/bash
export CYGWIN=error_start:gdb

export D=1

while [ $D -le 100 ] ; do
echo Loop $D

export C=1

logname=freeze.$D
logerr=${logname}.err
date > $logerr

while make -j -f MakefileV > $logname 2>> $logerr ; do C=$(($C+1)) ; done
echo Failed after $C runs >> $logerr
if [ -f make.exe.stackdump ]; then mv make.exe.stackdump make.exe.stackdump.$D ; fi
D=$(($D+1))

done

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/