Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!munnari.oz.au!comp.vuw.ac.nz!asjl From: Andy.Linton@comp.vuw.ac.nz (Andy Linton) Newsgroups: comp.bugs.4bsd Subject: Re: Patch: Sendmail 5.61 core dumps on long lists Message-ID: <1990May30.221516.6077@comp.vuw.ac.nz> Date: 30 May 90 22:15:16 GMT References: <432@ria.ccs.uwo.ca> Sender: news@comp.vuw.ac.nz (News Admin) Reply-To: Andy.Linton@comp.vuw.ac.nz Organization: Computer Science Dept, Victoria University, Wellington, NEW ZEALAND Lines: 40 In article <432@ria.ccs.uwo.ca>, reggers@ria.ccs.uwo.ca (Reg Quinton) writes: |> We were having trouble with sendmail core dumping when dealing with |> long recipient lists (at least with 5.61 on our Mips machine). I |> managed to localize the problem into deliver.c and the deliver() |> procedure where the string array "tobuf" was causing the problem -- to |> much data was being written into the array and this was corrupting |> other structures on the stack. |> |> The following patch fixed that problem. |> |> *** deliver.c Wed May 30 14:45:02 1990 |> --- deliver.c.orig Wed May 30 15:35:32 1990 |> *************** |> *** 221,227 **** |> continue; |> |> /* avoid overflowing tobuf */ |> ! if ((strlen(to->q_paddr) + strlen(tobuf) + 2) > sizeof(tobuf)) |> break; |> |> if (tTd(10, 1)) |> --- 221,227 ---- |> continue; |> |> /* avoid overflowing tobuf */ |> ! if (sizeof tobuf - (strlen(to->q_paddr) + strlen(tobuf) + 2) < 0) |> break; |> |> if (tTd(10, 1)) I ran into this one on a a machine running HPUX 7.0. The problem there (and I suspect on the Mips box) is the type of value (size_t) returned by sizeof and strlen. 'size_t' is defined to be 'long' in BSD 4.3, 'int' in SunOS and 'unsigned int' in HPUX (and ANSI C). I checked through the sendmail code and other uses of 'sizeof' and 'strlen' are written to avoid this problem - good luck rather than judgement? The important point is that this sort of problem will almost certainly surface again as old code is recompiled on newer machines.