Re: scheduler: unlink... No such file or directory

[Eugene Crosser <crosser@online.ru>]

On 21-Aug-00 at 16:24, Matti Aarnio (mea@nic.funet.fi) wrote:

> > While evaluating new x86 rackmount boxes I installed Zmailer on one
> > (running Solars7 x86) and piped full mail feed there.  There are
> > still things that I reported before but diagniostics is somewhat
> > different:
> > 
> > scheduler: unlink(../queue/F/wV DDST)[sch-unctl-2]: No such file or
> > directory scheduler: unlink(../queue/V/X?DDST)[sch-unctl-2]: No such
> > file or directory 
> 
>   These are - shall we say - absolute nonsense.
> 
>   At  scheduler/update.c: unctlfile() function:
> 
>        if (cfp->dirind > 0)
>          sprintf(path, "../%s/%s/%s",
>               QUEUEDIR, cfpdirname(cfp->dirind), cfp->mid);
>        else
>          sprintf(path, "../%s/%s",
>               QUEUEDIR, cfp->mid);
> 
>        eunlink(path,"sch-unctl-2");
> 
>   With  lib/esyslib.c: eunlink()  reporting the 'tag' value in
>   sensible way (that is, a valid tag) I am inclined to consider
>   that the  esyslib.c  and  update.c  were both compiled before
>   linkage.  Therefore the  eunlink()  was corrent binary and
>   produced correct result, but the 'path' content is there bogus.

What I can tell for sure that in this particular case it was clean
first compile from the source.

>   Bogus 'path' means that  cfp->mid  pointed string is bogus.
> 
>   Also, the  eunlink()  is called only if  'no_unlink' is
>   zero, which means at one place at  scheduler/scheduler.c,
>   and one place at  scheduler/update.c: unctlfile().  Just which...
> 
>   At update.c the  unctlfile() is called twice from  update.c: deletemsg()
>   (highly unlikely), and once from  vtxupdate(), which means updates from
>   any and all message statuses.
> 
>   All paths that I seem to be able to pick do feel to be ok.
>   As if the message file has corrupted  without a valid "MID" value.
> 
>   On the other hand, a NULL pointer referral of  cfp->mid  should cause
>   a crash when printing that 'path' content...

Could just the memory where MID pointer is poiting be overwritten, or,
say, freed and reallocated by mistake?

Eugene