Subject: CCL:malloc etc. on DEC Alpha

From: "Simon Kilvington" <[email-masked]>
Date: Thu, 16 Mar 1995 18:13:49 +0000 (GMT)

Konrad Hinsen wrote:
> 
> However, in all cases of malloc()-related crashes I have experienced
> so far (and that is a large number), the code calling malloc() was at
> fault. The most typical bug is memory access beyond the allocated space.
> Some versions of malloc() are quite forgiving if only a few more
> bytes are used, which is often the case, and this explains why such
> programs work on some machines but not on others. Another common 
> way to ruin malloc's data space is to work with undefined addresses
> (bad pointers in C, or wrong number of subroutine parameters in Fortran).
> 

	a (fairly) easy way to check for writing passed the end of malloc
blocks is to replace calls to malloc with calls to a routine which claims
slightly more space than is needed, puts some id characters at the start
and end of the block eg "MALLOC_BLOCK" or something, and returns a ptr to
the first byte after the id. Then replace calls to "free" with a routine
that first checks whether the id characters are still intact. If they have
changed something has writen before/after the start/end of the block.

	hope this helps,

	Si.

---
Simon Kilvington, [email-masked]

PS: make sure your id is a multiple of 4 (8?) bytes or you may get some
alignment problems.

---

From: [email-masked] (Hinsen Konrad)
Date: Thu, 16 Mar 95 14:28:49 -0500

> My recommendation is not to use programs that crash in malloc().
   > Even if they work on some machines, they are essentially buggy
   > and not to be trusted - even if they don't crash they might
   > produce wrong results. I know that often nothing else is
   > available, but in my opinion an unreliable program is no better
   > than no program at all.
	   Your point is well taken, but...  Don't most programs have some
   bugs here and there?  I've seen very few programs that didn't have some
   kind of bug including OS's.    

It is true that most non-trivial programs have bugs somewhere, but
there are enormous differences in their number and severity.

As has been pointed out by Simon Kilvington, it is quite easy to check
for writing past the end of malloc blocks (unless this occurs
extremely rarely, of course). So if a program shows crashes of this
kind, you may assume that its author has *not* done this simple
test. For me that is reason enough not to use such programs.

Unfortunately, many programmers (especially among scientists) still
think that it is sufficient to run a few test cases to validate their
programs. What one should do, and what many people in other fields are
already doing, is to think about debugging from the beginning of the
design process. Whenever your start to write a piece of code, your
first thought should be "How can I check whether I have made a
mistake?" Every program unit should be able to test the validity of
its input arguments; if this is expensive, use conditional compilation
to remove the tests from production code. Choose variable and function
names that are sufficiently different from one another that typos can
be caught by the compiler. Use all available tools for checking your
code (ftncheck for Fortran, lint for C), and make use of all compiler
options that help in debugging (i.e. -C with f77). I could extend this
list, but all this has been published before. Whoever really wants
to write reliable code can do so with little effort.

For some reasons that I cannot follow, scientists seem to ignore the
considerable progress that has been made in software engineering
during the last decades. Even big and much-used packages are in such a
bad shape that they seem to have been written by first-year students
as a programming exercise. I have heard excuses such as "I don't have
time to learn about programming techniques", but the people saying
that seem to have enough time to waste it on endless debugging and
on running programs whose results cannot be trusted.
I have been working in commercial software development (non-
scientific) for more than a decade, and I am sure my
company would have been out of business long out if it had
this "scientific" attitude towards software development.

Now I will sit back and wait for the well-deserved flames...

-------------------------------------------------------------------------------
Konrad Hinsen                     | E-Mail: [email-masked]
Departement de chimie             | Tel.: +1-514-343-6111 ext. 3953
Universite de Montreal            | Fax:  +1-514-343-7586
C.P. 6128, succ. A                | Deutsch/Esperanto/English/Nederlands/
Montreal (QC) H3C 3J7             | Francais (phase experimentale)
-------------------------------------------------------------------------------

---

From: [email-masked] (Garrett M. Morris)
Date: Thu, 16 Mar 1995 16:00:19 +0800

-> Date: Tue, 14 Mar 95 10:36:19 +0530
-> From: Mrigank <[email-masked]>
-> Subject: CCL:malloc etc. on DEC Alpha
-> 
-> HI
-> 
-> I am finding in using 'malloc' family or routines[malloc, free etc.] on our DEC
-> alpha machines running OSF/1. whenever they are called the program gives
-> segmentaion fault or memory fault and aborts. The code works very fine on other
-> machines. These are veru eesential in many huge comp. chem programs where
-> memory need to allocated as needed rather than fixed arrays and i can not
-> change the developed code for it is pain as well as not usefull.
->    not have food, they call me communist - Archbishop Camaran
-> 

Apparently, Mrigank,

On DEC machines, you *must* supply a 64-bit (i.e. "long" or "size_t")
argument to malloc.  If you do not, you can expect spectacular core
dumps.  I checked the "typedef" for size_t on a variety of architectures,
in the file "/usr/include/stdlib.h", and found this:

Architecture/OS		"typedef ... size_t;"
---------------		---------------------------------------
sun4/SunOS4		int
sun4/sunOS5.3		unsigned int
sgi4D/IRIX4.0.5		unsigned
sgi4D/IRIX5.2		unsigned int 	} if _MIPS_SZLONG == 32
hppa/HP-UXA.09.01	unsigned int
convex/ConvexOS10.1.184	unsigned int

		BUT...

sgi4D/IRIX5.2		unsigned long	} if _MIPS_SZLONG == 64
alpha/OSF1V3.0		unsigned long

I would recommend explicitly casting your malloc-argument correspondingly.
I hope this helps!

Garrett

 ----------------------------------------- ------------------------------------
| Garrett M. Morris, D.Phil.,               Research Associate,     _________  |
|                                         |                        |  _____    |
| Department of Molecular Biology, MB-5,  | [email-masked]    | |  _      |
| The Scripps Research Institute,         |                        | | |       |
| 10666 North Torrey Pines Road,          | Tel: + (619) 554-4392  | |         |
| La Jolla, CA 92037, U.S.A.              | Fax: + (619) 554-6860  |           |
|                                         |                                    |
 ----------------------------------------- ------------------------------------