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