[OpenAFS] Re: "unable to authenticate to AFS" error- linux distribution, specific?

[Jason McCormick]

This seems to be working for me on Fedora 3 (GCC 3.4.2) whereas the
previous patch by Christof did not.  Thanks!

-- Jason

--On Monday, November 22, 2004 01:15:47 PM -0600 "Douglas E. Engert"
<deengert@anl.gov> wrote:

> It may still be a problem with the stack, just moved to a different
> location.
> That ptch did not fix the problem that ubik_CallIter is being called with
> the wrong number of parameters. So can you try this instead? I believe
> it changes all the calls to use the correct number of parameters i.e. 19.
> 
> 
> 
> Joseph Kiniry wrote:
> 
>> Hi all,
>> 
>> After applying Christof's suggested patches OpenAFS 1.3.74 builds for 
>> me, and klog works, but all attempts at examining my cell's root volume 
>> (e.g., fs examine /afs/) result in hangs, segmentation faults, or other 
>> bizarre behavior.
>> 
>> Joe
>> 
>> On 19 Nov, 2004, at 11:08, Christof Hanke wrote:
>> 
>>> Douglas E. Engert wrote:
>>> 
>>>> It could also mean that the stack was being overlayed, and moving this
>>>> variabe to static means something else on the stack is being overlayed.
>>>> 
>>>> Two other things to try:
>>>> 
>>>>  Compile without optimizatrion.
>>>> 
>>>>  Use the debugger s to set a watch point on the ans_label before
>>>>  calling the ka_Authenticate. Hopefully the debugger will catch the
>>>>  location  where
>>>>  it ws being modified.
>>>> 
>>> You were right.
>>> The gdb found it was modified in ubik/ubikclient.c: ubik_CallIter()
>>> This function takes 20 parameters :
>>> afs_int32
>>> ubik_CallIter(aproc, aclient, aflags, apos, p1, p2, p3, p4, p5, p6, 
>>> p7, p8,
>>>              p9, p10, p11, p12, p13, p14, p15, p16)
>>> In kauth/authclient.c:kawrap_ubik_Call() it is called with only 12 
>>> parameters :
>>> 477 : code = ubik_CallIter(aproc, aclient, aflags, &count, p1, p2, p3, 
>>> p4,
>>> 478 :                             p5, p6, p7, p8);
>>> 
>>> Which is not uncommon, a wee grep showed up all sorts of numbers of 
>>> paramters with wich ubik_CallIter() is called.
>>> 
>>> The real trick is now in ubik_CallIter() itself :
>>> changing
>>> 777: code = CallIter(aproc, aclient, aflags, apos, p1, p2, p3, p4, p5, 
>>> p6, p7,
>>>                    p8, p9, p10, p11, p12, p13, p14, p15, p16,NEED_LOCK);
>>> to
>>> 777 :code = CallIter(aproc, aclient, aflags, apos, NEED_LOCK, p1, p2, 
>>> p3, p4, p5, p6, p7,
>>> 778:                     p8, p9, p10, p11, p12, p13, p14, p15, p16);
>>> 
>>> and all following seems to fix the problem.
>>> Here the patch :
>>> # diff ubikclient.c ubikclient_new.c
>>> 584,585c584,585
>>> < CallIter(aproc, aclient, aflags, apos, p1, p2, p3, p4, p5, p6, p7, 
>>> p8, p9,
>>> <        p10, p11, p12, p13, p14, p15, p16, needlock)
>>> ---
>>> > CallIter(aproc, aclient, aflags, apos, needlock,p1, p2, p3, p4, p5, 
>>> p6, p7, p8, p9,
>>> >        p10, p11, p12, p13, p14, p15, p16)
>>> 718,720c718,720
>>> <               CallIter(aproc, aclient, aflags, &count, p1, p2, p3, 
>>> p4, p5,
>>> <                        p6, p7, p8, p9, p10, p11, p12, p13, p14, p15, 
>>> p16,
>>> <                        NO_LOCK);
>>> ---
>>> >               CallIter(aproc, aclient, aflags, &count, NO_LOCK,p1, 
>>> p2, p3, p4, p5,
>>> >                        p6, p7, p8, p9, p10, p11, p12, p13, p14, p15, 
>>> p16
>>> >                        );
>>> 776,777c776,777
>>> <     return CallIter(aproc, aclient, aflags, apos, p1, p2, p3, p4, 
>>> p5, p6, p7,
>>> <                   p8, p9, p10, p11, p12, p13, p14, p15, p16, 
>>> NEED_LOCK);
>>> ---
>>> >     return CallIter(aproc, aclient, aflags, apos, NEED_LOCK, p1, p2, 
>>> p3, p4, p5,
>>> >                    p6,p7,p8, p9, p10, p11, p12, p13, p14, p15, p16);
>>> 
>>> Apparently, you cannot use a variable after the "optional ones", 
>>> otherwise you corrupt the stack (?).
>>> 
>>> Then there is the question :
>>> Wouldn't it be cleaner to call the function with the exact (real) 
>>> number of parameters ?
>>> I guess it would imply some performance penalties, but would they
>>> matter?
>>> 
>>> -Christof  Hanke
>> 
>> 
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-info
>> 
>> 
>> 
> 
> -- 
> 
>   Douglas E. Engert  <DEEngert@anl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444



-- 
Jason McCormick
CERT Infrastructure Team
jasonmc@cert.org ** 412-268-7961