Re: will the memory allocated by malloc get released when program exits?

Walter Roberson wrote:
> In article <1120508826.155669.16670@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
> Mark F. Haigh <mfhaigh@xxxxxxxxxxxxx> wrote:
> >Malcolm wrote:
>
> >> You should free all memory in normal operation, to make it easier to detect
> >> leaks. However if the program encounters an error, don't hesitate to just
> >> exit(EXIT_FAILURE) if program logic makes this the natural thing to do.
>
> >Please don't. Always free all memory you allocate.
>
> Ah? Even if you caught a SIGSEGV?


Let's examine for a moment how one can come across a SIGSEGV:

1. Through undefined behavior leading to "an invalid access
to storage" (C99 7.14#3), although such conditions are not
required to be detected (C99 7.14#4).

2. As a result of calling raise (or other POSIX or system-
specific functions, e.g. kill).

If your program goes the way of #1, then internal C library memory
allocation structures may be corrupted or inconsistent. This is often
seen when overflowing a malloc-ed buffer or freeing a non-allocated or
invalid buffer location (including double frees). It should be obvious
why one should not allocate or free memory within a SIGSEGV handler.

The C standard is clear enough regarding what is allowed from a SIGSEGV
handler:

7.14 [...]
[#5] If the signal occurs other than as the result of
calling the abort or raise function, the behavior is
undefined if the signal handler refers to any object with
static storage duration other than by assigning a value to
an object declared as volatile sig_atomic_t, or the signal
handler calls any function in the standard library other
than the abort function or the signal function with the
first argument equal to the signal number corresponding to
the signal that caused the invocation of the handler.
[...]

But it's the undefined behavior that's the underlying problem. Some
implementations may be able to report certain undefined behavior via
SIGSEGV, and some may not. The best way to avoid having to worry about
it is to write correct, robust programs that do not invoke undefined
behavior.

Users of POSIX-compliant systems may be able to differentiate #1 from
#2 via the si_code member of siginfo_t.


Mark F. Haigh
mfhaigh@xxxxxxxxxxxxx

.

Relevant Pages

  • Interrupt handler seems not to be called in GNAT 3.15p
    ... When accessing memory, I might not have access to some memory location. ... I can see SIGSEGV being raised. ... it is not passed to my interrupt handler, ...
    (comp.lang.ada)
  • Re: I want my segmentation fault!
    ... no occurrences of free and a lot of routines returning pointers to ... int length_of_list; ... This invokes undefined behavior because ml1 has been freed. ... memory is really available for reuse, I'd be glad to know about it. ...
    (comp.lang.c.moderated)
  • Re: How to know the memory pointed by a ptr is freed?
    ... > contents of ptr and the memory pointed to by ptr after a call to ... It's undefined behavior, ... An address is an address, memory is memory, ... a reference to just the pointer value is ...
    (comp.lang.c)
  • Re: Win32: Using SEH to search memory
    ... //push the address of our exception handler ... //Now we have to adjust our thread information block to reflect we may be anywhere in memory ... //As of Windows XP SP1, you cannot have your exception handler itself on the stack - but most versions of windows check to make sure your exception blcck is on the stack. ...
    (Vuln-Dev)
  • Re: pass by Reference/value ???
    ... the code is totally bogus and exhibits undefined behavior. ... And the local copy of `s' has gone out of scope, causing a memory leak. ... uninitialized pointer, undefined behavior is invoked. ... It's an urban legend. ...
    (comp.lang.cpp)