[TUHS] Clueless programmers

[TUHS] Clueless programmers

[Rudi Blom]

Clueless or careless?

A customer program worked for many years till one of the transaction
messages had a few bytes added.

Looking into it I discovered that the program had only worked because
the receive buffer was followed by another buffer which was used in a
later sequence. Only when also that buffer overflowed some critical
integers got overwritten and used as index in tables that gave a lot
of fun.

Well, as all here know, C is fun :-)

[TUHS] Clueless programmers

[Larry McVoy]

We had the same problem that was uncovered by a naive programmer "removing
unneeded whitespaces".  Moved some stuff around and exposed a buffer overrun.

On Fri, Feb 16, 2018 at 10:54:50PM +0700, Rudi Blom wrote:
> Clueless or careless?
> 
> A customer program worked for many years till one of the transaction
> messages had a few bytes added.
> 
> Looking into it I discovered that the program had only worked because
> the receive buffer was followed by another buffer which was used in a
> later sequence. Only when also that buffer overflowed some critical
> integers got overwritten and used as index in tables that gave a lot
> of fun.
> 
> Well, as all here know, C is fun :-)

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Clueless programmers

[Ron Natalie]

> 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.

[TUHS] Clueless programmers

[George Michaelson]

"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 at 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.
>

[TUHS] Clueless programmers

[Dave Horsfall]

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."

[TUHS] Clueless programmers

[George Michaelson]

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 at 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."

[TUHS] Clueless programmers

[Kevin Bowling]

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 at 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.
>