tcsh core dump

Christos Zoulas christos at zoulas.com
Wed Sep 19 23:25:11 EEST 2007


On Sep 19,  1:20pm, Mike.Sullivan at Sun.COM (Mike.Sullivan at Sun.COM) wrote:
-- Subject: Re: tcsh core dump

| 
| >From mike_s Tue Sep 18 12:02:38 2007
| >To: tcsh-bugs at mx.gw.com
| >Subject: tcsh core dump
| >
| >
| >I just saw this bug go by (in solaris):
| >
| >	6606055 tcsh aborts "repeat N cmd &" when it finishes
| >
| >and it's quite reproducible both on the 6.14.07 we ship
| >and one built normally:
| 
| Well now I've looked at it and it may be simple. It looks
| like dorepeat() protects the first calls to the cleanup*() functions
| under 'if (setintr)' and 'if (setintr && pintr_disabled == 1)', 
| but the last call is not protected. In the foreground (working)
| case pintr_disabled is 2 and setintr is 1, but in the background
| case pintr_disabled is 1 but setintr is 0. So I protected that
| call and no core dump:
| 
| {mike_s:yavin:80} diff -c tcsh-6.15.00/sh.func.c*
| *** tcsh-6.15.00/sh.func.c      Thu Aug 24 13:56:31 2006
| --- tcsh-6.15.00/sh.func.c.new  Wed Sep 19 13:12:50 2007
| ***************
| *** 688,694 ****
|         reexecute(kp);
|         --i;
|       }
| !     cleanup_until(&pintr_disabled);
|       donefds();
|   }
|   
| --- 688,695 ----
|         reexecute(kp);
|         --i;
|       }
| !     if (setintr && pintr_disabled == 1)
| !         cleanup_until(&pintr_disabled);
|       donefds();
|   }
|   

Thanks, that looks right to me.

| Though I know little about the new signal mechanism here
| (but I have to figure that out sometime since I do see
| it hanging reading my .cshrc at times), and I don't know
| if we should only look at setintr to match the first
| call to cleanup_push() really.


There was a patch to handle a

    set foo=`builtin`;

issue; pethaps this is what is causing your problem?

christos



More information about the Tcsh-Bugs mailing list