[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scheduler: unlink... No such file or directory
On 21-Aug-00 at 16:24, Matti Aarnio (firstname.lastname@example.org) 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);
> sprintf(path, "../%s/%s",
> QUEUEDIR, cfp->mid);
> 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?