rkww@crosfield.co.uk (roger willcocks) (03/04/91)
historical exercise: how long has the following bug been in the Bourne shell ? It exists in both SVR2 (Uniplus) and SVR3 (MIPS risc/os 4.0), and causes 'sh' to (essentially unpredictably) dump core. In the file blok.c, function 'alloc' (#defined to be malloc) actually returns a block of memory BYTESPERWORD too short. The last few bytes contain a live linkword for the storage allocator. Somebody obviously knew this at one time, because a couple of places call 'alloc(xxx + BYTESPERWORD)'. But most places don't. How has it worked for so long ? Or have I missed something obvious ? -- Roger Willcocks "if it all worked we wouldn't have a job" Crosfield Electronics Ltd [ any opinions expressed here are my own; ] Hemel Hempstead, England [ CEL may disagree with any or all of them ] +44 442 230000 rkww@cel.co.uk mcsun!cel!rkww@uunet.uu.net
gwyn@smoke.brl.mil (Doug Gwyn) (03/05/91)
In article <RKWW.91Mar4153858@server3.crosfield.co.uk> rkww@crosfield.co.uk (roger willcocks) writes: >In the file blok.c, function 'alloc' (#defined to be malloc) actually >returns a block of memory BYTESPERWORD too short. The last few bytes >contain a live linkword for the storage allocator. The situation is actually much worse than that. I ended up drastically overhauling the SVR2.0 version of blok.c in order to straighten out the various alignment problems, as well as the unportable assumption that the lowest bit in a pointer representation was available for use as a "busy" flag. (Note that it is a struct blk *, not a word, that needs to be allowed for.) Of course, the fundamentally worst problem with the Bourne shell source is that it insists on replacing the system malloc() with its own version. Practically every time our Cray UNICOS is upgraded, I have to embark on a Bourne shell debugging expedition involving this weird method of storage management.