headers
Craig Allsop | 7 Dec 2010 02:55
Picon

virus scanner crashes jam

Hi jammers,

I recently got myself a new computer (an Intel i7/Win7 with much the
same software I had previously) and was disappointed to discover that
jam crashes quite often on it when I run my jam scripts. After having
a little trouble attaching to the crashed executable (since it didn't
do so when run within the debugger) I found it crashes in execunix.c
here:

    /* Write command to bat file. */
    f = fopen( cmdtab[ slot ].tempfile, "w" );
>  fputs( string, f );
    fclose( f );
    string = cmdtab[ slot ].tempfile;

The problem is, it never opened the file for write, a bit weird since
it doesn't choose a slot unless pid is zero and that occurs after the
file is unlinked, right? Well after tracing file IO with sysinternals,
it turns out that the friendly virus scanner can get in the way, and
in this case it can hold a file handle to the tempfile which causes
windows to 'hold off' deleting it (reports as delete pending). Quite
annoying really given that I turned if off!

To make it more robust, I've changed my fopen to:

    while ( (f = fopen( cmdtab[ slot ].tempfile, "w" )) == 0)
	Sleep(5);

Now its rock solid again.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Waugh | 13 Dec 2010 22:58
Picon

Re: Is -j broken, or is it just me?

Thanks for the patch and explanation. I added some comments below:

>>> I've made a test case for the problem (see attached). This hopefully
>>> demonstrates the two issues:
>>> 1. jam gets ahead of itself and builds targets that depend on one of
>>> the multiple output targets.
>>> 2. if one 'co-dependent' target is out of date or missing, when jam
>>> updates it the tool may make the others stale resulting in a double
>>> build. If you delete xc, jam will build xc, xc1, xc2 but it doesn't
>>> know that xb will be built and thus it should build xb1 & xb2.
>>>
>>> Chuck's solution solves 1 but not 2 (completely).

Yes, definitely. In fact, the original issue (the one that started
this whole thread) I think could be fixed just by giving asynccnt an
extra increment / decrement to account for each 'co-dependents'.
Solving the second issue is a bit harder though.

>>> Chunk's solution passing 0 only traversing dependents and sibling
>>> dependents not siblings - Is there a reason for this because I don't
>>> follow?

I don't have Chuck's original patch, but your version seems correct.

>>> Personally, I think make0 should be called for xb's dependents at step
>>> 3a as it did previously but also its siblings but not their dependents
>>> because they'll be done anyway. Step 3c only needs to traverse the
>>> current nodes dependents it doesn't need to look at more than this
>>> because as far as I understand this step is only to make later depends
>>> loops easier and we can use Chucks function to traverse dependents and
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Waugh | 24 Dec 2010 08:57
Picon

Re: Is -j broken, or is it just me?

Thanks for the patch Chunk - I got it this time (yay).

I tried coding up the version I described, and here's that patch -
thoughts anyone?
It essentially does this:
   If I depend on X, then I also depend on X's co-dependents.

These dependencies would be hard to specify generically in the Jamfile
itself since you can't really say "who are my children," but in the
source it's easy.

I built some test cases to exercise Craig's issues (1) and (2), and
they both pass after applying this, but I don't really have any large
projects that use multi-output actions.
Feedback welcome.

(note: I attached the patch as a file, too. Gmail likes to force-wrap things)

diff a/make.c b/make.c
--- a/make.c
+++ b/make.c
 <at>  <at>  -169,7 +169,8  <at>  <at> 
 	COUNTS  *counts,        /* for reporting */
 	int     anyhow )        /* forcibly touch all (real) targets */
 {
-	TARGETS *c, *incs;
+	TARGETS *c, *extras, *acttarg;
+	ACTIONS *act;
 	TARGET  *ptime = t;
 	time_t  last, leaf, hlast;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Graeme Gill | 28 Dec 2010 03:40

Re: Is -j broken, or is it just me?

John Waugh wrote:
> I built some test cases to exercise Craig's issues (1) and (2), and
> they both pass after applying this, but I don't really have any large
> projects that use multi-output actions.
> Feedback welcome.

I ended up working around the problem in my Jambase by creating a
dummy file copy rule. One output then has the usual dependency, and
tall the other outputs become dummy copies of the first output.

This won't help if random output files get deleted, but it at least
makes sure that the right actions happen if all the outputs are
out of date or missing.

Graeme Gill.
_______________________________________________
jamming mailing list  -  jamming <at> maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming
Permalink | Reply | 0 comments |

Gmane