Re: [tlug] segfault

["Josh Glover" <jmglov@example.com>]

Quoth Viktor Pavlenko <vvp@example.com>:

> The core file will look alike. The emacs shell buffer I captured has a
> printout of an STL string kept as const reference and which was
> previuosly deleted. I thought it was a good visualization of a
> segfault as you can see contents of the memory the program is reading
> until it goes outside of its boundaries and gets the signal from OS.

Very sweet. Now tell me again *why* your code contained a segfault? ;)

Tangentially, I was using Valgrind [1] the other day to make sure *my* code
contained no memory leaks or malloc() / free() crap that could lead to
segfaults. I had devised a test of my soon-to-be-Open-Sourced queue library
in 32,768 objects, each 100k in size, were malloc()'d, enqueued, and then 
free()'d.

Well, I guess I was smoking something, because I was off by one decimal
place, and expected my test program to use 335544320 bytes (320MB) of memory. 
No problem, since my workstation (at work) has 256MB of RAM and 512MB of
swap. However, that 768MB of total memory was about 2432MB short of the ~3.2 
*GB* of memory that the program actually tried to allocate.

Not a problem, you are saying, since Linux handles a non-root process running
out of memory gracefully. Well, if you are saying this, you must be
unfamiliar with Valgrind, which turns on malloc() and free() debugging in
glibc for one (expensive) and calculates stuff on every malloc() or free()
to make sure you are not leaking memory, freeing memory that you shouldn't
be, etc.

To make a long story short, I ran out of memory and my test program, which
was being a good kid and checking the return value of malloc() (OK, all you
systems coders out there, *always check the return value of malloc() and
handle it!!!* Not doing this will cause your code to fail under a heavy load, 
in strange and unpredictable ways. This is a common mistake that is 
responsible for many odd failures and security holes.), returned an error
code. The reason that this would be a long story is that with Valgrind doing
its thing, it took an hour for my system to run out of memory. :)

Anyway, tales from the trenches and all that rot.

Cheers,
Josh

[1] http://developer.kde.org/~sewardj/
    This is one things that *every* C[++] developer should run on his code
    before releasing it or putting it into production. Another of those things
    is Splint. [2]
[2] http://lclint.cs.virginia.edu/
    Splint is a tool for statically checking C programs for security 
    vulnerabilities and coding mistakes.