[comp.lang.c] TC 2.0 oddity - me or it ?

djm@castle.ed.ac.uk (D Murphy) (11/13/90)

I have a program running on a PC which does its job perfectly BUT which 
produces a Null pointer assignment message after it has finished. This
is being caused by something after the last instruction (I tested this
by adding puts("Last"); just before the closing brace of main() and got

Last
Null pointer assignment

and I don't know why this is happening. All the memory allocations and
deallocations work fine, and no pointers get moved around without DOS
being told about it, so does anyone know why this might be happening and
what I can do about it  ?

Murff...

rusbara2@sage.cc.purdue.edu (Bob Rusbasan) (11/13/90)

In article <7131@castle.ed.ac.uk> djm@castle.ed.ac.uk (D Murphy) writes:
>produces a Null pointer assignment message after it has finished. This
>is being caused by something after the last instruction (I tested this
>by adding puts("Last"); just before the closing brace of main() and got
>
>Last
>Null pointer assignment

I know this isn't an MS-DOS group, but could this possibly be put in
the faq posting if it isn't already?  Yes, it doesn't fit in with the
purpose of the group, but then it will stop (hopefully) this recurring
post that doesn't fit in with the purpose of the group...

To answer the question, TC (and MSC) have memory that they use in every
executable file (it contains error messages, the programs copyright,
and things like that).  This memory is at the beginning of the module.
If you write to address ds:0, which is what will happen if you write to
a null pointer, this are of the program gets trashed.

When the program is done running, it checks the integrity of this area.
If it has been written to, it gives you the NULL pointer message.  As
someone said, better late than never...

(One thing I find funny is that the NULL pointer error message is in
this memory area, so it often comes out looking rather funny!)

This doesn't really help you find the problem, but at least you know
there is one.  Just look through your code, run the debugger, or
whatever till you find where you're writing to a NULL pointer.  You
might want to start by wrapping all your mallocs, farmallocs, etc.,
in if statements to check the result of the allocation, assuming
you haven't done that already.

----------------------------------------------------------------------
| Bob Rusbasan          |  This space unintentionally left blank.    |
| bob@en.ecn.purdue.edu |                                            |
----------------------------------------------------------------------

s64421@zeus.usq.EDU.AU (house ron) (11/13/90)

djm@castle.ed.ac.uk (D Murphy) writes:

>I have a program running on a PC which does its job perfectly BUT which 
>produces a Null pointer assignment message after it has finished. This
>is being caused by something after the last instruction (I tested this
>by adding puts("Last"); just before the closing brace of main() and got

>Last
>Null pointer assignment

Zero is actually a perfectly legitimate address, but it got snaffued
by C to stand for a NULL pointer.  Thus, if in your program you do:

    int *p = NULL;
    *p=9;

You will happily store 9 in address zero.  The compiler doesn't write logic
to check for this because it would slow you down.  But when the prog.
finishes, it does just a single check on address zero to see if you
changed it.

You should be able to easily write a small test prog. to verify this.
--
Regards,

Ron House.   (s64421@zeus.usq.edu.au)
(By post: Info Tech, U.C.S.Q. Toowoomba. Australia. 4350)

gordon@osiris.cso.uiuc.edu (John Gordon) (11/14/90)

	Just because the "Null pointer" message gets printed the last thing in
your program does NOT mean that that's when it happened.  It just means that
SOMEWHERE in your program, there was a null pointer assignment.

eager@ringworld.Eng.Sun.COM (Michael J. Eager) (11/15/90)

In article <7131@castle.ed.ac.uk> djm@castle.ed.ac.uk (D Murphy) writes:
>I have a program running on a PC which does its job perfectly BUT which 
>produces a Null pointer assignment message after it has finished. This
>is being caused by something after the last instruction (I tested this
>by adding puts("Last"); just before the closing brace of main() and got
>
>Last
>Null pointer assignment


What is happening is that the message is generated after main
returns.  The actual use of the null pointer is not generating the 
message.

The startup routine keeps a copy of several bytes at the beginning of your
data segment.  When main returns, the startup routine checks to see if
this data has been altered.  In your case, it has, and the message is 
written to stderr.  

You are most likely using an uninitialized pointer and writing to this
memory.  That your program works is luck, and the fact that you do not
overwrite a large amount of data.  

-- Mike Eager

TIM@ENH.Prime.COM (11/16/90)

I've gotten this on a few of my programs here and there, too. It was usually
because I wasn't specifying an array index within the range of the array.
i.e.: "char i[12];" declared, and I was saying "i[-1]" or "i[12]" ... I
remember it usually happened with char arrays/pointers.

Hope this helps.

/* Tim Cantin                                         1% of Americans retire
    Prime Computer, Inc., MS 10-13                    independently wealthy;
    500 Old Conn Path                             the other 99% are working,
    Framingham, Mass.  01701  (USA)          financially dependent, or dead.
   Phone: (508) 620-2800, ext. 3101                        What will you be?
   InterNet: TIM@ENH.Prime.COM
   Uucp:     {primerd, cvbnet, uunet}!ENH.Prime.COM!TIM
   Uucp:     {primerd, cvbnet, uunet}!hobbiton!tim                           */

#include "stddisclaimer.h"

kaiser@ananke.stgt.sub.org (Andreas Kaiser) (11/17/90)

In your msg to All, dated <16 Nov 90 19:01>, it said:

 DM> Last
 DM> Null pointer assignment

Turbo C's <exit> code looks for a change within some bytes at the address 0 (NULL). Any change results in the above message. The reason is an assignment via a pointer with a value of NULL.

                Andreas

--  
:::::::::::::::::::: uucp: kaiser@ananke.stgt.sub.org
:: Andreas Kaiser :: fido: 2:509/5.2512 & 2:507/18.7206
::::::::::::::::::::