RE: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Wed, 2004-09-15 at 11:00, Bogdan Vacaliuc wrote: My local tests and all reports from rtems-users so far are successes. Meanwhile, there are failure reports or at least non full success stories from rtems-users, c.f. http://www.rtems.org/ml/rtems-users/2004/september/msg00144.html http://www.rtems.org/ml/rtems-users/2004/september/msg00151.html Ralf -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Christopher Faylor wrote: Grr... This was the newlib problem previously mentioned. I forgot to generate the snapshot in such a way as to work around this problem. The new snapshot should work better. Indeed it does. I have tried a couple of times without any hickups. With 1.5.11 a have not been able to get my testcase to even pass once if straceing. With this snapshot I now have 5 consecutive successes (and no failures). I'm afraid I don't understand the issue and why the temporary change in the snapshot points at bash, so someone else is probably better suited to notify the bash maintainer. (If the evidence in this message qualifies as confirmation.) BTW, thanks for helping out with debugging! Cheers, Peter -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Chris, My local tests and all reports from rtems-users so far are successes. -bogdan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Ekberg Sent: Wednesday, September 15, 2004 3:24 AM To: [EMAIL PROTECTED] Subject: RE: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1) Christopher Faylor wrote: Grr... This was the newlib problem previously mentioned. I forgot to generate the snapshot in such a way as to work around this problem. The new snapshot should work better. Indeed it does. I have tried a couple of times without any hickups. With 1.5.11 a have not been able to get my testcase to even pass once if straceing. With this snapshot I now have 5 consecutive successes (and no failures). I'm afraid I don't understand the issue and why the temporary change in the snapshot points at bash, so someone else is probably better suited to notify the bash maintainer. (If the evidence in this message qualifies as confirmation.) BTW, thanks for helping out with debugging! Cheers, Peter -- 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/ -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Christopher Faylor wrote: On Tue, Sep 14, 2004 at 11:01:23PM -0400, Bogdan Vacaliuc wrote: Ok. Running 09/14/04 snapshot is looking *good* so far. I stopped the test script at 150 passes. I'm starting my configure/build/redo test and will let that run overnight. I'll check in tomorrow AM and report on that. 1 successful configure/build so far. That points to a problem with bash, then, not cygwin. If we can confirm this then we should probably notify the bash maintainer. He might be interested by the attachment below, obtained from the bashstrace in http://cygwin.com/ml/cygwin/2004-09/msg00626.html fgrep ' 1696 ' bashstrace | grep '= fork\|wait4: call' bashstrace_grep.txt Every fork is followed by a wait, except the one that leads to trouble. Somehow bash draws conclusions about its status without doing a wait. Pid reuse shouldn't be the root cause of this behavior. Also according the the following comment in bash code, the Cygwin style of pid reuse should be no problem: #if defined (RECYCLES_PIDS) /* LynxOS, for one, recycles pids very quickly -- so quickly that a new process may have the same pid as the last one created. This has been reported to fix the problem. */ Pierre 117 872308 [main] bash 1696 fork: 2308 = fork() 125 873876 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 137 927912 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 152 1115952 [main] bash 1696 fork: 2036 = fork() 210 1117609 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 137 1223831 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 117 1662780 [main] bash 1696 fork: 1488 = fork() 144 1664261 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 131 1867156 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 116 1914817 [main] bash 1696 fork: 456 = fork() 139 1916356 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 146 2114502 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 120 2161965 [main] bash 1696 fork: 2104 = fork() 143 2163481 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 145 2368793 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 118 2416409 [main] bash 1696 fork: 1432 = fork() 165 2417863 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 145 2616099 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 119 2664589 [main] bash 1696 fork: 2308 = fork() 159 2665939 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 148 2865875 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 129 2914912 [main] bash 1696 fork: 2036 = fork() 676 2916792 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 146 3114780 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 204 3162946 [main] bash 1696 fork: 1488 = fork() 126 3164271 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 203 3461625 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 155 3509295 [main] bash 1696 fork: 456 = fork() 126 3510735 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 206 3712483 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 143 3765025 [main] bash 1696 fork: 2104 = fork() 127 3766418 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 145 3965535 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 117 4125336 [main] bash 1696 fork: 1432 = fork() 126 4126809 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 125 4358150 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 121 4405766 [main] bash 1696 fork: 2308 = fork() 137 4407184 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 147 4611082 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 116 4659500 [main] bash 1696 fork: 2036 = fork() 169 4661074 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 148 4866256 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 115 4913817 [main] bash 1696 fork: 1488 = fork() 157 4915180 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 145 5116382 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 116 5165835 [main] bash 1696 fork: 456 = fork() 163 5167204 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 145 5375291 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 130 5423472 [main] bash 1696 fork: 2104 = fork() 655 5425369 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 342 5625852 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 115 5859774 [main] bash 1696 fork: 1432 = fork() 127 5862344 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 0 145 5940525 [main] bash 1696 wait4: calling proc_subproc, pid -1, options 1 118
Re: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Wed, Sep 15, 2004 at 12:35:14PM -0400, Pierre A. Humblet wrote: Christopher Faylor wrote: On Tue, Sep 14, 2004 at 11:01:23PM -0400, Bogdan Vacaliuc wrote: Ok. Running 09/14/04 snapshot is looking *good* so far. I stopped the test script at 150 passes. I'm starting my configure/build/redo test and will let that run overnight. I'll check in tomorrow AM and report on that. 1 successful configure/build so far. That points to a problem with bash, then, not cygwin. If we can confirm this then we should probably notify the bash maintainer. He might be interested by the attachment below, obtained from the bashstrace in http://cygwin.com/ml/cygwin/2004-09/msg00626.html fgrep ' 1696 ' bashstrace | grep '= fork\|wait4: call' bashstrace_grep.txt Every fork is followed by a wait, except the one that leads to trouble. Somehow bash draws conclusions about its status without doing a wait. Pid reuse shouldn't be the root cause of this behavior. But, the fork previous to the last fork had been seen 5 times previously and the gap between the last occurrence of pid 456 was 7 which is greater than the 4 pids that cygwin holds in check to prevent duplication. Here's a useless table showing the occurrence of pids: PID PREV SEEN PID PREV SEEN PID PREV SEEN PID PREV SEEN 2308 -10 1432 61 2444 -10 2444 62 2036 -10 2308 62 1432 63 500 -10 1488 -10 2036 62 1488 103 456 64 456 -10 1488 62 2308 64 1488 55 2104 -10 456 62 928 51 2104 213 1432 -10 2104 62 2444 51 1432 85 2308 61 1432 62 2292 -10 316 -10 2036 61 652 -10 456 143 2296 -10 1488 61 2308 73 1432 74 888 -10 456 61 1744 -10 1488 74 456 75 2104 61 928 -10 2308 75 2016 -10 PID is the pid produced by fork. PREV is how many forks ago we'd previously seen this same pid (-1 means never). SEEN is how many times we've seen this pid. There doesn't seem to be anything especially unique about pid 456 (the problematic one), at least from this table. But, it sure is fun analyzing the data like bash was a black box... It does seem like the correct number of pids to hold is probably 8, though so, maybe the temporary change to cygwin is a keeper. Also according the the following comment in bash code, the Cygwin style of pid reuse should be no problem: #if defined (RECYCLES_PIDS) /* LynxOS, for one, recycles pids very quickly -- so quickly that a new process may have the same pid as the last one created. This has been reported to fix the problem. */ IIRC, bash keeps some kind of cache of pids which it has recently seen and incorrectly decides not to wait for pids in some cases. The RECYCLES_PIDS define turned out not to be foolproof. I had, at one point, turned off the code in cygwin which works around this problem when it looked like bash had a fix but the problem still manifested. 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Wed, Sep 15, 2004 at 01:01:50PM -0400, Christopher Faylor wrote: On Wed, Sep 15, 2004 at 12:35:14PM -0400, Pierre A. Humblet wrote: Christopher Faylor wrote: On Tue, Sep 14, 2004 at 11:01:23PM -0400, Bogdan Vacaliuc wrote: Ok. Running 09/14/04 snapshot is looking *good* so far. I stopped the test script at 150 passes. I'm starting my configure/build/redo test and will let that run overnight. I'll check in tomorrow AM and report on that. 1 successful configure/build so far. That points to a problem with bash, then, not cygwin. If we can confirm this then we should probably notify the bash maintainer. He might be interested by the attachment below, obtained from the bashstrace in http://cygwin.com/ml/cygwin/2004-09/msg00626.html fgrep ' 1696 ' bashstrace | grep '= fork\|wait4: call' bashstrace_grep.txt Every fork is followed by a wait, except the one that leads to trouble. Somehow bash draws conclusions about its status without doing a wait. Pid reuse shouldn't be the root cause of this behavior. But, the fork previous to the last fork had been seen 5 times previously and the gap between the last occurrence of pid 456 was 7 which is greater than the 4 pids that cygwin holds in check to prevent duplication. Here's a useless table showing the occurrence of pids: PID PREV SEEN PID PREV SEEN PID PREV SEEN PID PREV SEEN 2308 -10 1432 61 2444 -10 2444 62 2036 -10 2308 62 1432 63 500 -10 1488 -10 2036 62 1488 103 456 64 456 -10 1488 62 2308 64 1488 55 2104 -10 456 62 928 51 2104 213 1432 -10 2104 62 2444 51 1432 85 2308 61 1432 62 2292 -10 316 -10 2036 61 652 -10 456 143 2296 -10 1488 61 2308 73 1432 74 888 -10 456 61 1744 -10 1488 74 456 75 2104 61 928 -10 2308 75 2016 -10 PID is the pid produced by fork. PREV is how many forks ago we'd previously seen this same pid (-1 means never). SEEN is how many times we've seen this pid. There doesn't seem to be anything especially unique about pid 456 (the problematic one), at least from this table. But, it sure is fun analyzing the data like bash was a black box... It does seem like the correct number of pids to hold is probably 8, though so, maybe the temporary change to cygwin is a keeper. Also according the the following comment in bash code, the Cygwin style of pid reuse should be no problem: #if defined (RECYCLES_PIDS) /* LynxOS, for one, recycles pids very quickly -- so quickly that a new process may have the same pid as the last one created. This has been reported to fix the problem. */ IIRC, bash keeps some kind of cache of pids which it has recently seen and incorrectly decides not to wait for pids in some cases. The RECYCLES_PIDS define turned out not to be foolproof. I had, at one point, turned off the code in cygwin which works around this problem when it looked like bash had a fix but the problem still manifested. I have been poking at the bash code. It keeps all the pids in the pipelines for each job, so the number can be very large. At any rate, trying to get status without waiting should be considered a bug, and not a feature that Cygwin should work around. Will someone take responsibility to notify the bash maintainer? Pierre -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Wed, Sep 15, 2004 at 01:24:06PM -0400, Pierre A. Humblet wrote: At any rate, trying to get status without waiting should be considered a bug, and not a feature that Cygwin should work around. Will someone take responsibility to notify the bash maintainer? Ronald, I think this one is yours as the bash maintainer. Could you notify the bash maintainer? 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Wed, Sep 15, 2004 at 01:38:35PM -0400, Christopher Faylor wrote: On Wed, Sep 15, 2004 at 01:24:06PM -0400, Pierre A. Humblet wrote: At any rate, trying to get status without waiting should be considered a bug, and not a feature that Cygwin should work around. Will someone take responsibility to notify the bash maintainer? Ronald, I think this one is yours as the bash maintainer. Could you notify the bash maintainer? ^ upstream -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Christopher Faylor wrote: On Mon, Sep 13, 2004 at 09:54:29PM -0400, Pierre A. Humblet wrote: The surprise is that the error message: configure: error: invalid package name: extra-includes is produced at time 29722848 by bash 2624 (the main script pid). This is BEFORE the second expr is exec'ed. This occurs only at time 29725911 by a forked child 2656 of 2624 Following the output of the error message, 2624 proceeds to fork 2384, which apparently does nothing. 2624 then waits for 2656 and 2384 and exits. In other words the control flow seems to be seriously screwed up. It may be linked to the pid reuse problem in bash, but I know very little about it. Looking at the full trace available from Peter may help. I forgot I had that trace and accidentally deleted it. However, creating a new one is not difficult, so one is available at: http://www.lysator.liu.se/~peda/bashstrace.bz2 This one is created with strace -o ... as suggested by Igor. I was thinking the same thing but AFAIK, ash doesn't have the pid recycling problem. Don't know where ash comes into play, the script is executed by bash. I must have missed some other test case... Cheers, Peter -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Chris, Pierre, I was thinking the same thing but AFAIK, ash doesn't have the pid recycling problem. In my failure cases, configure is run under bash. I have also captured (finally?) an strace under the ~current cygwin (attached). The details are largely the same as Peter's last attachment, to which Igor remarked FWIW, expr.exe does seem to exit with the right exit code, but is later zombified, which doesn't sound quite right. Actually, its ok for it to be zombified, because the parent didn't happen to be waiting for the child at the time that the child exited. Pierre's observation that error text is output by the parent shell *before* the expr command even executes was an inspiration. So it seems like the parent shell decides its going to exit after forking but before waiting on the expr process. This is consistent across all my straces as well as Peter's. In my attached trace, this is between lines 582 and 750; I also noticed the following: 84 16461744 [main] bash 1048 close: close (1) 1378 16461829 [main] bash 2028 close: close (1) On line 725 and 726. By the time my trace got to line 750, the parent shell had stated to output the error text (53 characters in my case). I have another trace that exhibits this too. Peter's trace does not have this. In my trace (not Peter's) there are also some lines like: 324 16458452 [main] bash 1048 fhandler_base::set_no_inheritance: DuplicateHandle failed, The parameter is incorrect. 237 16458689 [main] bash 1048 fhandler_base::set_close_on_exec: set close_on_exec for /dev/console to 1 In the time between the fork and the beginning of the error write, but this is not unique to the trace and it was handled apparently ok previously in the script. Wasn't there a registry value that controlled how pids were allocated? I can't find anything appropriate in google. I looked for something about this in M$ knowledge base. I didn't find that, but I found this: BUG: Registry access from multiple threads might fail (WinNT, Win2K) http://support.microsoft.com/default.aspx?scid=kb;en-us;176906 -bogdan -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Bogdan Vacaliuc wrote: In your *new* trace there are the same trace (on line 176632) in the 'zone' between the fork() and the parent-shell exit decision point of your most recent trace. Did you update your cygwin since your last run? Perhaps its just an artifact? The set happens 4 times in your trace: Yes, the new trace is with cygwin1.dll 1.5.11-1, the old one was with 1.5.10-3, sorry if I didn't mention that... Cheers, Peter -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Hi Peter, Yes, the new trace is with cygwin1.dll 1.5.11-1, the old one was with 1.5.10-3, sorry if I didn't mention that... No, that's fine. It would have been significant if you *had not* upgraded and yet produced that failure. -bogdan -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Tue, Sep 14, 2004 at 08:11:39AM +0200, Peter Ekberg wrote: Christopher Faylor wrote: I was thinking the same thing but AFAIK, ash doesn't have the pid recycling problem. Don't know where ash comes into play, the script is executed by bash. I must have missed some other test case... Remember this? On Sat, Sep 11, 2004 at 03:05:01AM -0400, Bogdan Vacaliuc wrote: 4) http://sources.redhat.com/ml/cygwin/2002-08/msg00449.html thru http://sources.redhat.com/ml/cygwin/2002-08/msg00556.html This relates to Manfred Spraul's patch for bash related to RECYCLES_PIDS. I have observed the failure to occur under (a)sh, and bash 2.04.5, 2.05b and 3.00.0 ( I compiled them all, including enabling the RECYCLES_PIDS for bash 2.05b ). 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Mon, Sep 13, 2004 at 10:25:52PM -0400, Christopher Faylor wrote: I will create a snapshot with double the number of pids cached in cygwin. This will cause the last 8 pids to be held from reuse by windows. Hmm. I woke up this morning to see people busily flooding the airwaves with more strace output but not a hint of anyone trying this snapshot. Can someone try the snapshot please? 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Tue, Sep 14, 2004 at 02:45:11AM -0400, Bogdan Vacaliuc wrote: Chris, Pierre, I was thinking the same thing but AFAIK, ash doesn't have the pid recycling problem. In my failure cases, configure is run under bash. I have also captured (finally?) an strace under the ~current cygwin (attached). The details are largely the same as Peter's last attachment, to which Igor remarked FWIW, expr.exe does seem to exit with the right exit code, but is later zombified, which doesn't sound quite right. Actually, its ok for it to be zombified, because the parent didn't happen to be waiting for the child at the time that the child exited. Pierre's observation that error text is output by the parent shell *before* the expr command even executes was an inspiration. So it seems like the parent shell decides its going to exit after forking but before waiting on the expr process. That is consistent with the recycled pid problem. Are you seeing duplicated pids? Wasn't there a registry value that controlled how pids were allocated? I can't find anything appropriate in google. I looked for something about this in M$ knowledge base. I didn't find that, but I found this: BUG: Registry access from multiple threads might fail (WinNT, Win2K) http://support.microsoft.com/default.aspx?scid=kb;en-us;176906 I don't really see how that applies. -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Mon, Sep 13, 2004 at 10:25:52PM -0400, Christopher Faylor wrote: I will create a snapshot with double the number of pids cached in cygwin. This will cause the last 8 pids to be held from reuse by windows. Hmm. I woke up this morning to see people busily flooding the airwaves with more strace output but not a hint of anyone trying this snapshot. Well, I was expecting a note when it was in fact available. Can someone try the snapshot please? Tried it, and I'm not able to open a shell with it. I have rebooted, so it's not some stray old process holding on to the previous dll. What I did: bunzip2 of the snapshot dll, shut down all cygwin processes, swapped in the snapshot dll as /bin/cygwin1.dll, ran the cygwin shortcut. The cmd window appears and disappears. So then I tried to reboot, but no effect. Cheers, Peter -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Sun, Sep 12, 2004 at 09:42:07PM -0400, Bogdan Vacaliuc wrote: Anyway, the attached script (test-configure) will create the above configure.ac, generate configure (via. autoconf), and run the above line over and over until failure. I am also attaching cygcheck.out for my environment as it now exists. FYI, I lauched that script last evening, it's now at iteration 6441. That's on NT4 with a 2 day old cygwin dll built from cvs. I have seen all the latest e-mails in this thread and the plea to use the new snapshot. BTW, checking for reused PIDs is a trace is very easy: fgrep Program the_trace Pierre -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Tue, Sep 14, 2004 at 04:00:41PM +0200, Peter Ekberg wrote: Can someone try the snapshot please? Tried it, and I'm not able to open a shell with it. I have rebooted, so it's not some stray old process holding on to the previous dll. What I did: bunzip2 of the snapshot dll, shut down all cygwin processes, swapped in the snapshot dll as /bin/cygwin1.dll, ran the cygwin shortcut. The cmd window appears and disappears. So then I tried to reboot, but no effect. Grr... This was the newlib problem previously mentioned. I forgot to generate the snapshot in such a way as to work around this problem. The new snapshot should work better. 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Chris, Ok. Running 09/14/04 snapshot is looking *good* so far. I stopped the test script at 150 passes. I'm starting my configure/build/redo test and will let that run overnight. I'll check in tomorrow AM and report on that. 1 successful configure/build so far. Thanks! -bogdan -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Pierre,
FYI, I lauched that script last evening, it's now at
iteration 6441. That's on NT4 with a 2 day old cygwin dll
built from cvs.
I have seen all the latest e-mails in this thread and the plea
to use the new snapshot.
So you are not using the new snapshot, yet do not see the failure, correct?
Chris Johns on the RTEMS list reported that my configure line did not fail on his
MinGW system as readily as his configure line; his
line fails just as well on my system, so we've adopted it as the default now.
Please replace the fail() with the following in test-configure:
fail () {
${configure_test} -n \
--prefix=/opt/rtems \
--with-multisubdir=m68000 \
--with-multisrctop= \
--with-multibuildtop= \
--prefix=/opt/rtems \
--host=m68k-rtems \
--build=i686-pc-mingw32 \
--target=m68k-rtems \
--enable-multilib \
--enable-doc \
--enable-cxx \
--enable-posix \
--enable-networking \
--disable-tests \
--disable-itron \
--with-target-subdir=m68k-rtems \
--exec-prefix=/opt/rtems/m68k-rtems \
--cache-file=/dev/null \
build_alias=i686-pc-mingw32 \
host_alias=m68k-rtems \
target_alias=m68k-rtems \
CC='m68k-rtems-gcc --pipe -m68000' \
--cache-file=/dev/null
}
and make another run, hopefully *before* you install the snapshot.
So far on the rtems-list, reports of the configure problem have implicated Win98/WinME
and Win2K. No failure was reported
MinGW/WinXP. I'm still waiting to hear from others.
By the way, I never got a chance to respond to your request for a simpler test case.
Believe me, I tried. The exhaustive/iterative
method was the best I could do to come close to quickly returning a failure if the
problem existed. On my system, I'd have a better
than 1:2 chance of getting a failure, but other people reported different results.
It would *never* fail, if all you did was a few expr and tests. The whole configure
script machinery appears necessary to setup the
failure mode.
Thanks,
-bogdan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pierre A. Humblet
Sent: Tuesday, September 14, 2004 10:04 AM
To: [EMAIL PROTECTED]
Subject: Re: 1.5.10: expr + configure failure + testcase
(also on 1.5.11-1)
On Sun, Sep 12, 2004 at 09:42:07PM -0400, Bogdan Vacaliuc wrote:
Anyway, the attached script (test-configure) will create the above
configure.ac, generate configure (via. autoconf), and run the above
line over and over until failure. I am also attaching cygcheck.out
for my environment as it now exists.
FYI, I lauched that script last evening, it's now at
iteration 6441. That's on NT4 with a 2 day old cygwin dll
built from cvs.
I have seen all the latest e-mails in this thread and the plea
to use the new snapshot.
BTW, checking for reused PIDs is a trace is very easy:
fgrep Program the_trace
Pierre
--
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/
--
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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Tue, Sep 14, 2004 at 11:01:23PM -0400, Bogdan Vacaliuc wrote: Ok. Running 09/14/04 snapshot is looking *good* so far. I stopped the test script at 150 passes. I'm starting my configure/build/redo test and will let that run overnight. I'll check in tomorrow AM and report on that. 1 successful configure/build so far. That points to a problem with bash, then, not cygwin. If we can confirm this then we should probably notify the bash maintainer. -- 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Sun, Sep 12, 2004 at 09:42:07PM -0400, Bogdan Vacaliuc wrote:
Hello again,
After (finally?!) noticing that a new release of the cygwin.dll was made on Sept. 4
and being encouraged by the line:
- Fix mysterious configure script premature exit. (Pierre Humblet)
I decided to check against the latest public release. The problem continues to
persist, unfortunately.
I created a simplified testcase, by realizing that a simple configure.ac will let
autoconf generate a suitable configure script.
This auto-generated configure script exhibits the argument parsing failure as
readily as any script taken from a build environment.
It is also attached (as text this time, sorry for all the compressed business I
mucked with previously).
Here is the configure.ac file needed for autoconf:
snip
Bogdan,
The reason the mysterious configure script premature exit got fixed is that
we got a SIMPLE test case. Running a long configure script myriad times,
looking for an elusive error, won't lead to fast progress.
So try to isolate the error and produce a small test case.
I looked at the bashstracesnip2 trace provided by Peter Ekberg in
http://cygwin.com/ml/cygwin/2004-08/msg01329.html
I believe he is chasing the same problem as you.
The error occurs in the snippet
-with-* | --with-*)
ac_package=`expr x$ac_option : 'x-*with-\([^=]*\)'`
# Reject names that are not valid shell variable names.
expr x$ac_package : .*[^-_$as_cr_alnum] /dev/null
{ echo $as_me: error: invalid package name: $ac_package 2
{ (exit 1); exit 1; }; }
The surprise is that the error message:
configure: error: invalid package name: extra-includes
is produced at time 29722848 by bash 2624 (the main script pid).
This is BEFORE the second expr is exec'ed. This occurs only at
time 29725911 by a forked child 2656 of 2624
Following the output of the error message, 2624 proceeds to fork
2384, which apparently does nothing. 2624 then waits for
2656 and 2384 and exits.
In other words the control flow seems to be seriously screwed up.
It may be linked to the pid reuse problem in bash, but I know very
little about it. Looking at the full trace available from
Peter may help.
Pierre
--
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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
On Mon, Sep 13, 2004 at 09:54:29PM -0400, Pierre A. Humblet wrote: The surprise is that the error message: configure: error: invalid package name: extra-includes is produced at time 29722848 by bash 2624 (the main script pid). This is BEFORE the second expr is exec'ed. This occurs only at time 29725911 by a forked child 2656 of 2624 Following the output of the error message, 2624 proceeds to fork 2384, which apparently does nothing. 2624 then waits for 2656 and 2384 and exits. In other words the control flow seems to be seriously screwed up. It may be linked to the pid reuse problem in bash, but I know very little about it. Looking at the full trace available from Peter may help. I was thinking the same thing but AFAIK, ash doesn't have the pid recycling problem. IIRC there is a problem with normal bash where it could be confused by repeating pids even when the pids are separated by a large number. It can even happen on linux. I will create a snapshot with double the number of pids cached in cygwin. This will cause the last 8 pids to be held from reuse by windows. Wasn't there a registry value that controlled how pids were allocated? I can't find anything appropriate in google. 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: 1.5.10: expr + configure failure + testcase (also on 1.5.11-1)
Hello again, After (finally?!) noticing that a new release of the cygwin.dll was made on Sept. 4 and being encouraged by the line: - Fix mysterious configure script premature exit. (Pierre Humblet) I decided to check against the latest public release. The problem continues to persist, unfortunately. I created a simplified testcase, by realizing that a simple configure.ac will let autoconf generate a suitable configure script. This auto-generated configure script exhibits the argument parsing failure as readily as any script taken from a build environment. It is also attached (as text this time, sorry for all the compressed business I mucked with previously). Here is the configure.ac file needed for autoconf: [/jail/cygwin-1.5.11.1-std] cat configure.ac AC_PREREQ(2.57) AC_INIT([expr-configure],[1.5.11-1],[cygwin at cygwin dot com]) # for the purpose of this test, getting here is a success exit 0 To generate the configure script, just run 'autoconf'. The command for configure that exhibits the failure is: ./configure -n \ --target=i386-rtems \ --enable-rtemsbsp=386pc \ --host=i686-pc-cygwin \ --build=i686-pc-cygwin \ build_alias=i686-pc-cygwin \ host_alias=i686-pc-cygwin \ target_alias=i386-rtems \ --cache-file=/dev/null It doesn't happen all the time, of course. The *extremely curious* thing is that simply removing the '--enable-rtemsbsp=386pc' appears to make the configure script work all the time. I have experimented with reordering the arguments, putting '--cache-file=/dev/null' at the top, etc. It is easy to make the problem go away. This sequence seems to cause the problem most quickly. While performing the above tests in my chroot jails, I observed a new failure mode: [/jail/cygwin-1.5.11.1-std] ./test-configure *** CREATE configure.ac *** *** GENERATE configure *** Running using function fail()... *** TEST 0 *** *** TEST 1 *** *** TEST 1 FAILS *** configure: error: invalid variable name: build_alias [/jail] chroot /jail/cygwin-1.5.11.1-std /bin/bash -l $ ./test-configure Running using function fail()... *** TEST 0 *** *** TEST 0 FAILS *** configure: error: sources are in /, but `cd /' does not work This does not occur, if I replace /bin/bash in the jail with a locally compiled bash.exe (based on 2.05b, that has the RECYCLES_PIDS defined): [/jail] chroot /jail/cygwin-1.5.11.1-bash205b /bin/bash -l $ ./test-configure Running using function fail()... *** TEST 0 *** *** TEST 1 *** *** TEST 2 *** *** TEST 3 *** *** TEST 4 *** *** TEST 5 *** *** TEST 6 *** *** TEST 7 *** *** TEST 8 *** *** TEST 8 FAILS *** configure: error: invalid variable name: build_alias Rather, the issue we are pursuing occurs. What is interesting, is that in the 'std' case above, if one keeps calling the script, one can get the 'invalid variable name' error *instead* of the 'sources are in...' error. This suggests that the two are possibly related and 'RECYCLES_PIDS' has some bearing on the real issue. Anyway, the attached script (test-configure) will create the above configure.ac, generate configure (via. autoconf), and run the above line over and over until failure. I am also attaching cygcheck.out for my environment as it now exists. Thanks to anyone looking at this; even if simply to say 'yup, it's a problem', or 'no, you are wrong about this...' Best Regards, -bogdan p.s. For a chroot jail, the following programs are required at a minimum: $ ls /bin bash.execygintl-2.dll cygpcreposix.dll ls.exe sleep.exe cat.exe cygintl-3.dll cygwin1.dll mkdir.exe sort.exe chmod.exe cygintl.dll date.exe pwd.exetail.exe clear.exe cygpcre-0.dll echo.exe rm.exe touch.exe cygiconv-2.dll cygpcre.dll expr.exe sed.exewc.exe cygintl-1.dll cygpcreposix-0.dll grep.exe sh.exe $ ls /etc profile $ cat /etc/profile PATH=/bin PS1='$ ' p.p.s. Refer to my original post for any required background: http://www.cygwin.com/ml/cygwin/2004-09/msg00518.html test-configure Description: Binary data cygcheck.out Description: Binary data -- 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/
1.5.10: expr + configure failure + testcase
Greetings, The RTEMS project has also experienced the configure/expr problem over the last few weeks. A number of people have been working on it, and I would like to present our findings as well as offer a test case that exposes the problem fairly readily. As Igor has deduced in (http://sources.redhat.com/ml/cygwin/2004-08/msg01339.html), the failure mode is an incorrect interpretation of the exit status from invocations of 'expr' in configure.test. The actual call to 'expr' produces the correct output and exit status. When the failure occurs, the appropriate exit status of the 'expr' call is non-zero; however, it is incorrectly interpreted as zero, causing the configure script to exit prematurely. This was evidenced by running the test with the 'expr' wrappered in a script to log the arguments, output and exit status of each 'expr' invocation. This failure is not consistent; it takes many iterations for the effect to be realized. The failure also never occurs if the configure.test script is executed under strace. The failure does not necessarily occur in the same place within the configure script. The failure has not been shown to occur on a native GNU/Linux system to this date. It only occurs on PC/Cygwin systems. As a result, trapping the error typically involves running multiple iterations. Attached, I offer a pair of scripts designed to exhibit the failure. The attached archive contains the following files: configure.test This script was extracted from the RTEMS build enviroment and pared down to avoid requiring the entire build context. It is observed that the failure occurs in the OPTION=VALUE processing of the configure script. test-drive This script invokes configure.test under a variety of iterative and environmental controls. The scripts are suitable for execution in a chroot jail with just the /bin (cp -r /bin /jail/bin) and /tmp (mkdir /jail/tmp), as needed for bash. Execute '$ ./test-drive help' to get details on the options as well as some summary on my current thinking on this. NOTE: it is not uncommon for the script to require on the order of 100 iterations to fail. --- Summary of related threads and investigations performed to date: 1) https://sourceforge.net/tracker/?group_id=2435atid=102435func=detailaid=8 07543 Chris Johns filed a bug (with test scripts) in the MingGW project related to the same configure issue. In that filing, the failure presented under Win98, did not appear to occur in WinXP, and was affected by the order of options listed on the configure command line. 2) http://sources.redhat.com/ml/cygwin/2004-08/msg01025.html Peter Ekberg posted some work within the GGI project, and also posted some links to similar issues found in other projects like Ethereal (circa 09/2003), KimDaBa (04/2004) and Cygwin itself (10/2003). [The latter two quickly degenerated OT, unfortunately...] 3) http://www.cygwin.com/ml/cygwin/2002-02/msg01068.html and http://www.rtems.com/ml/rtems-users/2004/september/msg00036.html Andrew DeFaria summarized a problem in Win32 desktop heap resources (circa 2002) that I initially explored (with brief success on my workstation and Scott Newell's in msg00044.html of that same thread). However, after additional tests and more failure reports, I abandoned that track to concentrate on the expr problem. Nevertheless, manipulating these resources appeared to affect the failure mode with all other things being equal. [I should also mention at this point that it seemed to me that the scripting failures increased in frequency after I killed the Explorer task (which windows promptly respawns). I have not restarted my workstation since that time. In anycase, this may simply be circumstantial] 4) http://sources.redhat.com/ml/cygwin/2002-08/msg00449.html thru http://sources.redhat.com/ml/cygwin/2002-08/msg00556.html This relates to Manfred Spraul's patch for bash related to RECYCLES_PIDS. I have observed the failure to occur under (a)sh, and bash 2.04.5, 2.05b and 3.00.0 ( I compiled them all, including enabling the RECYCLES_PIDS for bash 2.05b ). The one thing I was able to observe was that running under bash 3.00.0 had the least likelyhood of producing the error. However, under long running operations, the exact same failure occurred eventually. [the script above allows easy testing of different shells in chroot jails]. Some details related to my investigation of this can be found here (http://www.rtems.com/ml/rtems-users/2004/september/msg00059.html). I had activated the tracing/logging in (a)sh looking at the modification/use of the global exitstatus and oexitstatus. --- I end with hopes that together the good people of Cygwin and the 'net can come to an understanding of what this thing is. Best Regards, -bogdan p.s. If you should be interested in looking at my cygcheck output get it here: http://www.ngit.com/blog/csb350/cygcheck.txt configure-test.tar.bz2 Description: Binary data -- Unsubscribe info:
RE: 1.5.10: expr + configure failure + testcase
Excuse me.
Please perform the following on the script:
$ sed -i '1 s/\/sh/\/bash/' test-drive
I attach an archive with the updated script.
-bogdan
begin 666 configure-test.tar.bz2
M0EIH.3%!62936=4F0T`,A1_I/__0!___\!`0``@ [EMAIL PROTECTED]/X[
MN?3^;--%\/7GN??;E7OICWN/RO4JLJTH%F4:)V!NJEP]QI-SF[CA%J #
MSCGHT:R?=OO?=[M[/[EMAIL PROTECTED];[EMAIL PROTECTED]'T^[[ND*I%0ZUF-37W,YEM6MB.SLY
M9F :6ZSMW)=1=UBH(K8QJVTZW65'=N%:D@4H[G72P[LYFP UFV.:8YVW8
MX5NACNQ6K1)E#:VZX;#32!- 3)B !#1H:2GY3RF)-M-093RFJ/$F@,AD TP
MAH TT$T$T:GJF4RGJ:32CQ0#:(H`T!H`:- ```PT$4T3)[EMAIL PROTECTED]: -
M``TIH (#1H```@ 322$(T*C1-IZ:3)C53\$RIM3U/U3:9('[EMAIL PROTECTED]
M#30``,[EMAIL PROTECTED]:9 %-,5/-33U--,C$T!/)DRGJGA,ILID]-(]1HH\2@_5,:
M@1$(: $ 1D)BGD,BGZ30%,RA-E0;-34\HRIY1D:-J@?8?O_;VS_[;4
MU@\Z,/!A*?LBCW0\!._=[55A!,8DC*,`C409%0-[EMAIL PROTECTED],A(MKBX
M?4+^WOJY^C\?]'S\:[^RT'ADG#^U/)5\7I86;TI8M04D*!$ 2,'#;3+9N
[EMAIL PROTECTED] ?GMLN+]%T$^GI;KUWOQ,8T_=8,RI_A6HK5IH,$26.)%VCZ*^(N
MJ6#[)V)7)\4M59%AFXS$I1#[9H-RVR-@\1=E1JHF4!XK/!F:C /KV20\^+
[EMAIL PROTECTED]'(33-YHO 8RR^(9Z8CU;R^F]QCYJO'KL6V6)[EMAIL PROTECTED])'X
[EMAIL PROTECTED]9GYY_C8*)ZL/'/R_2,-[Y:2C2Z\(+76J2M/[EMAIL PROTECTED](
MQ-5=\JQR(M54N,%X:[EMAIL PROTECTED]@_6ZISX?B1R*-6K6XMC28FA'$$;=%ONBVL
M0HBY?JZF1P!UPX:LV#IYASZ:VW+P7./X_/Q,0[EMAIL PROTECTED];7..8YCY3SI2K@
M\^*PZ01)W)@(ID11Q!JL 65.[%JQA=VO8*A*.R[J][M_II*3N5%;[M#=*(
M*RF+)7DVHSB[UK)(KIIS]/]KF[YE95+FXRE;;@7:]P_==Z0IX%#3;NJJQ
M=-%[Z%555^-P5\?I]QZ)[)Y',1@FUN-W+,JC_-6((?3L`9P0:
ME^?..JN:=^ULL-]+HR:73UY]:F]]ZD2\/9DHC73%LCIKGV,OE;82
MC?MKFHD\.S3,*=9#A1]*9G45.AMFEMUH@7:[TI)-SUKW4[_3L;_P?5F'
MLNVR)EE$\P\]#*5Z2R@6!U\JH2,\!KG[[E4DDD1*):]!D#1)DR),-
M4V9 39H$F19BF)TK6]0+(E.DAG(7%SUO(NS%O,@]RTKV %MT.!WX#G/
MDG%[,Y)O(KL-C/P-E_TU-4CB4!'[EMAIL PROTECTED]0ET.C'?C3EXLVSLR:2#1,S-G
M0.(#3KA;PAUTFMC[!;OH= 07'45R5Z)MU ;L7(LC-AM!#'CHF9SVR0Y;Q
M_!#S=/9NRG%?:+-QLG:YBEA]!$.5'70.:CUD-X\F[79T\V8Z:7'.PTQ
MW1RN*;:SX!?CQK=JV:=/#GHW]2K/ND4A$A'ND%%7JQ04ZY%5$LK04$* =:
M-\$4Y8 A\=]*%$0$ZA[-W3_=1;U(=R`:8J';OR]W[K'X]6,D6*W14T[
M**V%[X7T#QJ5=8LT@;#Q\\=]?[EMAIL PROTECTED]%T)_-ME]FW6;:\EQ-V_[[*[HYQ9
M$3FF)%_JBO)\- *9IAM,^%RF@@Q4B*I%0228DBHJ *!%C$_-:+!WEDR3H
M43A^K[3600T(E-$^+T..K[[\7\#Y9(3Y0$Z-#02P!0R?Q^:ZKAJD (
MX$4K2L2QLX%Q-0-IP _?\F5@)QGQPV;[EMAIL PROTECTED](0,@)O600E
M.(0D!%,A7F1`3]G8?!,G,;:;CCJQ87#QU81WH[=/K'S/B7'C[9'I;RCQ
MB PG3U B!5U8'@%5# (,71X2XI]#:OQ+ZX%0B.\W3\'?BLB4?4=U#\!N\
MU$XXDB:EP*6BU:VFKM?E[@[EMAIL PROTECTED];(LD^GHYZ1$G' :J%F(FU$%V/5FL*#'B
MQ( [EMAIL PROTECTED]/@\;3MST.LVSGQ+D'6SI?\,!78E;=
M,[74^F([EMAIL PROTECTED](/)X7N;35'1N4[)%2U?C(;UF0$;X9:G$G,)$M*:N1TCR
MM-[T2[1%F+8VXZ% (_*Y8)L:J60%A-M-^+\=V'@[[W2 *04BBR ,@,W-
M(7[:$V11M 9!9 9$(H32$J0BR75)/B0AID-=I9,9R$L(M$/9[:OJINKV
M)FH/U+Y'TFDZ^Z.US(F,/$WDT7 ;7NZ#$'!3 N+H8WMO**3F1TCDSJK
M:.AK!\96R8$1$00VW0#%\O5.#Q/2;/1\2/AZ-6IYXHTV%,#^W'JS.(?O
M)B,WS^/* .4_1_3=D'Y\#KG2OQI`)KS;=04(?I(7 HFD:E$?/MS[02
M,'U*C)^4`9BB?E!%BCVSR93JOF='?N8K1T,L*FQ\+2'4L=HB)N2V#*
M,,,2]F;@?MUPEXR0AL3^%8FV?4;(D/.D5CSA00HD?9T[S5UY:[EMAIL PROTECTED],G
MW9;:MQ/T]=*J' V/,UVOP9[/Y8Z8CKDFBO.D'[EMAIL PROTECTED],-)TS19-=T
M]L/S\=?K\WD_5]-G5VV4:SS;$XB'4#5T,YLH]+Y2(E#Z1 /+I= ?!9G
M;!Y,XQLT#%.EO](]R\]56S (,2+U#0A]B*H$C_4RY)4\^?1XGII?IEJ,3\D
M6,9=FV*O;]C=#EZ'\22^F*]U$R0N=(?O1F;NF5-I?9XRGB-!/R;)+:
M]7C+!N#E*-IYG-0#ZY^,#5%R838*'\T!BCJRHSVB:R_FM]Z[!EBG'ZSY(=*
M8X;2;;7W\/#:#KF;[EMAIL PROTECTED]:GV_$*A/,0TY,+-$OC/@516)TG*
M6NQIB;R23,8VK$HTL,2\_*6KA2%%9Z:-V:0D/=P+((#!UHF[QZAF9(OP
M213/X 9LR8XE[3-?[\G3:+;7$3K6\BNR8-LWCXH!?H*]CG#*W, 0PAJD
MD4*/CM5X#D%5 NK7AJ:O!]!KRY4K[J=F:#G+.#Z:?2OV#T),)V34,*BS_-
M=L1X@:G+C69CB)DA5*.,?Y)6P]_$QM[[J;(].1!3JBA$\ZE0UJ8MBS*(
M5WCW_Y5Y^BHJM[H:[ZJ=! MYJX80K-#X,[EMAIL PROTECTED])A\BYY?48`VNJ
M2',!(E]EE:(?XJI@(HG5+Z08:_5(@[EMAIL PROTECTED]*Q)[EMAIL PROTECTED](
MZ#X_I!6%Z?8?C(Z?`SYE([EMAIL PROTECTED])9(MJLZL?)H:MDXGEK*
M)CG%L) _F6)R*J+5IW\!VPUVJ,[EMAIL PROTECTED]YE/2.HU*)HJSN[;ID\S2,WD
M:4K.NA63V +EI.6LYH5U!4::XX1LDMPY(%?Y*Z\OV[ZBVVQV:H/'CKNZZV
M_G;G-5.!R_8$ M7MCFX993W#YB/,V[6$X7A849(LJU(RT:8)N*E-=L.
M$Q6A,.!0ZP(^*X_SP5$7PK6ZM/OZT=+B[#\4J/.=U4W] =;\\:B6[MC[
[EMAIL PROTECTED] R[7!USE?/NHTX4LC%K401RM6-=-OHF[EMAIL PROTECTED]/=ESBBCV-W,?PL]
M-54`CPUZMS)7=KS8\V=Y@I;6)=.YNZUAV44*$ZT8?.8'41-5+K,/WHG'.
M8C18O$HB;6^/;XIS03A-^VB[EMAIL PROTECTED];!)!L`6J86%4V.QESC
MK5BXZ]L8=ECSZ9M(,AV0QYL)%S?UZ,G7\Z[NYR.ZJ)[D.B`H%RVK]
MO3LQ7;C[4*$I15(([EMAIL PROTECTED]@+_'1P[G:A@/#*;U3%).*+$$*%!DEGB(K!61/W
M#3L:_75='67#!NF8N(Z7FJ:'[2$*'';$PU\?3WTUKQ'6MP12 32^_GCT5H
M`-N.N#-!BH(6ZR3%!(JGVL,D3SHG[EMAIL PROTECTED]
M17\_NTT.PI,R-!7/0NL!=23W).!TN,:$L-.$G7%:[GO1A6$CCC4,SJ=V7
M5D:[EMAIL PROTECTED]R_,\.V(V(M\S.6GR;(^-1/$C(C8FBCM5A0E.N:PL]R;
MNAQNJWX\K1GE!'[EMAIL PROTECTED]@F%0Y3,0)][5($1XEM6TN)$;NOAGRV;\
M=0'(;/+6:@T!V.'1J$[LU\HSY1OB426*Z/#IBW97C([EMAIL PROTECTED];R'KINT::N(
M!.FZBJ'1E F^M;-AA42H#BHK3S8G.VU:**1V=]34V (Q%B-S;[EMAIL PROTECTED]/
M,G@:V;185[[AAZ=6S7:FKNB*ZI(A\!'0(MHN,+G%7M,VG9101@)J-
M#QWOMF]=U%U;EZA:AIU5 ET]'HCA=(/;OTQ-4NIZUS=1!$+SH._GK!3;(
M47C*:H[EMAIL PROTECTED]';O\^CB8\U%$Y'#D*$]7)AFZWV7EKH44AGAFIIZ)X;
