Bug 432351

This is very strange as the change in the update isn't
related to the code that handles direct maps at all.

Can you post the information described at
http://people.redhat.com/jmoyer so we can check try and
spot what might be happening.

Ian

Created attachment 294581 [details]
Requested information

(In reply to comment #1)
> This is very strange as the change in the update isn't
> related to the code that handles direct maps at all.

Changelog disagrees with this:

* Mon Jan 21 2008 Ian Kent <ikent> - 5.0.1-0.rc2.55.el5.3
- Bug 429163 Processed: Reloading autofs map incorrectly removes all map entries
- add patches to prevent direct map being incorrectly marked stale.
- Resolves: rhbz#429163

It specifically states that patches were added dealing with direct maps.

One additional thing I just found is that if I change auto.master from:

/- auto.direct

to:

/- /etc/auto.direct

then it does what it is supposed to do.

(In reply to comment #3)
> Changelog disagrees with this:
> 
> * Mon Jan 21 2008 Ian Kent <ikent> - 5.0.1-0.rc2.55.el5.3
> - Bug 429163 Processed: Reloading autofs map incorrectly removes all map entries
> - add patches to prevent direct map being incorrectly marked stale.
> - Resolves: rhbz#429163

Ha, sorry, forgot about that one.
My mistake.

Ian

(In reply to comment #4)
> One additional thing I just found is that if I change auto.master from:
> 
> /- auto.direct
> 
> to:
> 
> /- /etc/auto.direct
> 
> then it does what it is supposed to do.

OK, that should be easy enough to reproduce.
I'll need to put something in the regression tests
to check for that as well.

Ian

Yes, I've been able to duplicate this.
The problem doesn't exist with revision 0.rc2.86 which
is the revision from which these patches were taken.

There's a dependency that's not obvious.
I'll get onto it straight away.
Sorry for the inconvenience.

Ian

This really bazaar.

This looks like an variable initialization problem.

As far as I can tell there is no difference in the compile
options between 0.rc2.86 and 0.rc2.55.el5.3 and yet
0.rc2.55.el5.3 always gets a zero in the uninitialized
field in question whereas 0.rc2.86 always gets garbage
(which is the same as 1, as it should be at this point).

So, it's a bug in revision 86 as well.
Ian

Created attachment 294719 [details]
Patch to fix incorrect initialization, causing unpredictable behavior.

Although the issue, and resolution, seems quite
clear to me it would be good if this patch could
be tested.

If you can get a test rpm built I'll be able to test it for you.  I've got a
number of machines that exhibit this error and it will be very obvious if it is
fixed or not.

(In reply to comment #8)
> This looks like an variable initialization problem.
> 
> As far as I can tell there is no difference in the compile
> options between 0.rc2.86 and 0.rc2.55.el5.3 and yet
> 0.rc2.55.el5.3 always gets a zero in the uninitialized
> field in question whereas 0.rc2.86 always gets garbage
> (which is the same as 1, as it should be at this point).
> 
> So, it's a bug in revision 86 as well.

Can you also check the el5.2 as that one functions fine for me.  Interested to
know if that initializes to garbage or 0 too.

(In reply to comment #11)
> (In reply to comment #8)
> > This looks like an variable initialization problem.
> > 
> > As far as I can tell there is no difference in the compile
> > options between 0.rc2.86 and 0.rc2.55.el5.3 and yet
> > 0.rc2.55.el5.3 always gets a zero in the uninitialized
> > field in question whereas 0.rc2.86 always gets garbage
> > (which is the same as 1, as it should be at this point).
> > 
> > So, it's a bug in revision 86 as well.
> 
> Can you also check the el5.2 as that one functions fine for me.  Interested to
> know if that initializes to garbage or 0 too.
> 

I'll check but I'm not sure how useful that will be because
it should be random, although it doesn't appear to be.

Also, the change that caused it alters the way autofs decides
whether to read the map.

Ian

It's interesting to note that, after looking at the test
I wrote for this bug, it will catch the bad initialization
and fail if it happens. But, of course, it doesn't seem to
happen in packages on the main CVS branch.

Odd and odder!

I've just checked out, built and tested rev 0.rc.55.2 and it
gets a zero and not garbage and so works as it should.

I still can't see any difference in the package build.

The field in question belongs to a structure allocated
on the stack (in this case) so it really should be
initialized correctly by me.

Ian

(In reply to comment #10)
> If you can get a test rpm built I'll be able to test it for you.  I've got a
> number of machines that exhibit this error and it will be very obvious if it is
> fixed or not.

Policy is that all changes made available to customers need
to be tracked in CVS. So I'll need get an ack for the rhel-5.1.z
flag before I can commit this and build the rpm.

I'll see what I can do this evening.
Ian

Has there been any progress on this?

(In reply to comment #16)
> Has there been any progress on this?

No ACKS, so I can't do anything.

But I think there is more to this than just the patch I
posted.

If the people with the ability provide the ACKS below, I'll
investigate what else is needed. It is always risky when only
a small part of the changes contained in a later release are
applied to fix a problem in an earlier release.

You could test the RHEL 5.2 beta.

Ian

Closing this with resolution NEXTRELEASE since this is already fixed in 5.2
release and the 5.1.z stream is cancelled.