14 Feb
2018
14 Feb
'18
2:28 p.m.
already 20 years ago I met a guy (masters degree,
university) who never freed dynamically allocated memory. He told me he is
'instantiating a object', but had no idea what an heap is, and what dynamically
allocated memory means.
Years ago, I had an new programmer who I just couldn't teach. He never understood
the difference between an array and pointer, and apparently couldn't be bothered to
learn.
After string him along for three months, I was on my way into his office to fire him when
I found out he had quit, but not before he checked a bunch of drek into our source code
control system.
I thought I backed all his commits out at the time.
Years later I was running "purify" on our product looking for memory leaks. I
found this small utility function that predated the source code control system leaking.
This, I thought was odd, as it had been there FOREVER and was well tested. I brought up
the source code system and checked it anyhow and found the afore mentioned programmer had
checked in one change: he deleted the "free" call in it.
I KNOW what happened. He did something else to corrupt the malloc heap in his code and
often this causes a core dump in a subsequent malloc/free call. Apparently this was the
place it struck him, so he just deleted the free call there.
14 Feb
14 Feb
10:07 p.m.
"worked for him" is an allowed rule under the "I don't know why it
worked but it did" hacking code, for a deadline.
somebody in product land has a sign saying 'the best is the enemy of
the good enough" which people in tech support want to ritually burn
because all he did is shift cost out of his bucket into somebody
elses, but thats also allowed under the "not my problem" rule.
I (and I am self-confessed as the worlds least competent programmer)
frequently found the delay between where corruption in malloc is
applied and where its detected sufficiently confusing that I would
have been tempted to follow this well trodden "remove the free()"
path.
-G
On Thu, Feb 15, 2018 at 12:28 AM, Ron Natalie <ron(a)ronnatalie.com> wrote:
already 20 years ago I met a guy (masters degree,
university) who never freed dynamically allocated memory. He told me he is
'instantiating a object', but had no idea what an heap is, and what dynamically
allocated memory means.
Years ago, I had an new programmer who I just couldn't teach. He never understood
the difference between an array and pointer, and apparently couldn't be bothered to
learn.
After string him along for three months, I was on my way into his office to fire him when
I found out he had quit, but not before he checked a bunch of drek into our source code
control system.
I thought I backed all his commits out at the time.
Years later I was running "purify" on our product looking for memory leaks. I
found this small utility function that predated the source code control system leaking.
This, I thought was odd, as it had been there FOREVER and was well tested. I brought up
the source code system and checked it anyhow and found the afore mentioned programmer had
checked in one change: he deleted the "free" call in it.
I KNOW what happened. He did something else to corrupt the malloc heap in his code and
often this causes a core dump in a subsequent malloc/free call. Apparently this was the
place it struck him, so he just deleted the free call there.
11:50 p.m.
On Thu, 15 Feb 2018, George Michaelson wrote:
I (and I am self-confessed as the worlds least
competent programmer)
frequently found the delay between where corruption in malloc is applied
and where its detected sufficiently confusing that I would have been
tempted to follow this well trodden "remove the free()" path.
MALLOC_CONF and Electric Fence are your friends; I never released any of
my dynamic code without first running it past those (and some of my linked
lists were hideous).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
15 Feb
15 Feb
2:42 a.m.
I've successfully debugged analogous modern code longline with smart
people by judicious use of valgrind. Never underestimate the power of
sending them current source, and running a tool against it with good
diagnostic. Its probable that electric fence would have got there too,
but this method worked for the person in question (event driven code,
C++, linked to the libevent library, lots of malloc/free)
It was quite entertaining for me to do this because back in the 80s
when I worked at Leeds university I had to run student debug clinic,
and the litany was "bring me a fresh listing" which got rid of 3/4 of
the problems up front. So here I am, debugging and the moral
equivalent is "send me a link to the checked in code repository in
github, and valgrind output, and I'll find the problem". I am pretty
sure some of the problems vanished once I got code up to date, before
sending it in.
On Thu, Feb 15, 2018 at 9:50 AM, Dave Horsfall <dave(a)horsfall.org> wrote:
On Thu, 15 Feb 2018, George Michaelson wrote:
I (and I am self-confessed as the worlds least
competent programmer)
frequently found the delay between where corruption in malloc is applied and
where its detected sufficiently confusing that I would have been tempted to
follow this well trodden "remove the free()" path.
MALLOC_CONF and Electric Fence are your friends; I never released any of my
dynamic code without first running it past those (and some of my linked
lists were hideous).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer." 
11:43 a.m.
I've never seen anything this bad, and it gave me a hearty laugh out
loud. I guess in my years people mostly self select toward safer
languages if they are human fuzzers.
On Wed, Feb 14, 2018 at 7:28 AM, Ron Natalie <ron(a)ronnatalie.com> wrote:
already 20 years ago I met a guy (masters degree,
university) who never freed dynamically allocated memory. He told me he is
'instantiating a object', but had no idea what an heap is, and what dynamically
allocated memory means.
Years ago, I had an new programmer who I just couldn't teach. He never understood
the difference between an array and pointer, and apparently couldn't be bothered to
learn.
After string him along for three months, I was on my way into his office to fire him when
I found out he had quit, but not before he checked a bunch of drek into our source code
control system.
I thought I backed all his commits out at the time.
Years later I was running "purify" on our product looking for memory leaks. I
found this small utility function that predated the source code control system leaking.
This, I thought was odd, as it had been there FOREVER and was well tested. I brought up
the source code system and checked it anyhow and found the afore mentioned programmer had
checked in one change: he deleted the "free" call in it.
I KNOW what happened. He did something else to corrupt the malloc heap in his code and
often this causes a core dump in a subsequent malloc/free call. Apparently this was the
place it struck him, so he just deleted the free call there.
2620
days inactive
2621
days old
4 comments
4 participants
participants (4)
-
Dave Horsfall -
George Michaelson -
Kevin Bowling -
Ron Natalie