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" <[EMAIL PROTECTED]> 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 >> [EMAIL PROTECTED] >> https://lists.openafs.org/mailman/listinfo/openafs-info >> >> >> > > -- > > Douglas E. Engert <[EMAIL PROTECTED]> > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 -- Jason McCormick CERT Infrastructure Team [EMAIL PROTECTED] ** 412-268-7961 _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info