schikore@mentor.cc.purdue.edu (Dan Schikore) (10/11/90)
What exactly does the run-time error "Null Pointer Assignment" mean? I get
this error after a series of recursive calls to a function, but the error does
not come up until the end of the program. In fact, I put in the line
printf("done\n");
exit(0);
at the end of my main, and when executed, it says
done
Null Pointer Assignment
Does this make sense? Thanks for any suggestions.
-Dan Schikore
schikore@mentor.cc.purdue.edubleys@tronsbox.xei.com (Bill Cavanaugh) (10/12/90)
>not come up until the end of the program. In fact, I put in the line > >printf("done\n"); >exit(0); > >at the end of my main, and when executed, it says > >done >Null Pointer Assignment > >Does this make sense? Thanks for any suggestions. > >-Dan Schikore >schikore@mentor.cc.purdue.edu I'm not sure about the message, so I won't comment on that, but the reason the message is coming up after the printf() is that the printf() sends it's output to stdout, and the message is going to stderr.... /**************************************************************** * All of the above copyright by the below. * * Bill Cavanaugh uunet!tronsbox!bleys * * "Freedom of the press does not mean you get * * a press given to you for free." * ****************************************************************/
kdq@demott.COM (Kevin D. Quitt) (10/12/90)
In article <15004@mentor.cc.purdue.edu> schikore@mentor.cc.purdue.edu (Dan Schikore) writes: >What exactly does the run-time error "Null Pointer Assignment" mean? > >printf("done\n"); >exit(0); > >at the end of my main, and when executed, it says > >done >Null Pointer Assignment I would guess that you're using Microsoft C, which reserves a small portion at the beginning of the data as to try to detect the use of null pointers, and to help you avoid other side effects. This area has a known value (the Microsoft copyright info), and it is checked upon exit. If the data are not correct, you've written thru a null pointer, and you get the above error message. I assume further that if you're not using Mirosoft C, your C compiler does something similar. -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
roger@everexn.com (Roger House) (10/13/90)
In <15004@mentor.cc.purdue.edu> schikore@mentor.cc.purdue.edu (Dan Schikore) writes: >What exactly does the run-time error "Null Pointer Assignment" mean? I get >this error after a series of recursive calls to a function, but the error does >not come up until the end of the program. In fact, I put in the line Sounds like you are using Microsoft's C compiler. At runtime MSC places some special string of characters at "address" 0, i.e., the place in memory that a pointer with value 0 accesses. At the end of execution of your program, some runtime code looks at "address" 0 to see if the special string is still there. If not, it means that your code has overwritten this string, which most likely means that your code accessed data via a pointer which contained NULL. Thus, the error message. Look at your code carefully to see if you are dereferencing a null pointer. Roger House
darcy@druid.uucp (D'Arcy J.M. Cain) (10/13/90)
In <27154927-274.1comp.lang.c-1@tronsbox.xei.com> Bill Cavanaugh writes: >>not come up until the end of the program. In fact, I put in the line >> >>printf("done\n"); >>exit(0); >> >>at the end of my main, and when executed, it says >> >>done >>Null Pointer Assignment >> >>Does this make sense? Thanks for any suggestions. >> >I'm not sure about the message, so I won't comment on that, but the reason >the message is coming up after the printf() is that the printf() sends it's >output to stdout, and the message is going to stderr.... > Wrong. The Null Pointer Assignment message is generated *AFTER* main returns. The C startup code looks at the copyright message at address 0 to see if it was modified anytime during the run. This is necessary on DOS systems as there is no memory protection to generate an exception. This check at the end of the program is designed to give some indication that a NULL pointer was dereferenced. The error however could have happened anywhere in the program. To find it you have to use your debugger to follow the values at DS:0 or set a watch up for that memory location. Check your debugger documentation for details. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | I support gun control. West Hill, Ontario, Canada | Let's start with the government! + 416 281 6094 |
draper@inmet.inmet.com (10/16/90)
/* Written 9:53 am Oct 13, 1990 by darcy@druid.uucp in inmet:comp.lang.c */ In <27154927-274.1comp.lang.c-1@tronsbox.xei.com> Bill Cavanaugh writes: >>>not come up until the end of the program. In fact, I put in the line >>> >>>printf("done\n"); >>>exit(0); >>> >>>at the end of my main, and when executed, it says >>> >>>done >>>Null Pointer Assignment >>> >>>Does this make sense? Thanks for any suggestions. >>> >>I'm not sure about the message, so I won't comment on that, but the reason >>the message is coming up after the printf() is that the printf() sends it's >>output to stdout, and the message is going to stderr.... >> >Wrong. The Null Pointer Assignment message is generated *AFTER* main returns. >The C startup code looks at the copyright message at address 0 to see if it >was modified anytime during the run. This is necessary on DOS systems as >there is no memory protection to generate an exception. This check at the >end of the program is designed to give some indication that a NULL pointer >was dereferenced. The error however could have happened anywhere in the >program. To find it you have to use your debugger to follow the values >at DS:0 or set a watch up for that memory location. Check your debugger >documentation for details. /* End of text from inmet:comp.lang.c */ When I first started programming in C using MSC 4.0 I ran into this message on several occasions. I traced it down to some sloppy code and coding techniques used to parse command line arguments. If you are using argc,argv in your code that is where I would start looking. - Dave Draper It's not a bug ... it's a feature. Internet: draper@inmet.inmet.com UUNET: uunet!inmet!draper ----- Intermetrics Microsystems Software, Incorporated 733 Concord Avenue Cambridge, MA 02138 (617) 661-0072 x4573
rusbara2@sage.cc.purdue.edu (Bob Rusbasan) (10/19/90)
In article <1990Oct16.010142.14499@inel.gov> cdm@gem-hy.Berkeley.EDU (Dale Cook) writes: >In article <615@quad.sialis.mn.org>, dts@quad.sialis.mn.org (David T. >Sandberg) writes: >|> In article <15004@mentor.cc.purdue.edu> schikore@mentor.cc.purdue.edu >(Dan Schikore) writes: >|> >What exactly does the run-time error "Null Pointer Assignment" mean? I get >|> >this error after a series of recursive calls to a function, but the >|> >error does not come up until the end of the program. >|> I seem to recall that executables produced by some unnamed DOS compiler >|> do a check of memory location 0 at the conclusion of their run, and >|> kicks out this message if the value therein has been changed since the >|> program was started. In other words, the assignment to a null pointer >|> could be occurring anywhere within the program... it is by virtue of >|> the cleanup checking that you hear about it after the fact. (Better >|> then than never, I suppose.) >|> >|> It might help if you mention which compiler you are using. >I get this error faithfully every time I leave PeachTree accounting >software. Hasn't done any apparent harm, but I don't exactly have >a warm fuzzy about it, either... Not even after reading the above? I replied to the original post thru email, but since it keeps coming up... This happens with some (all?) of the DOS compilers, including TC/TC++ and MicroSoft. As stated above, the compiler has some data at memory location DS:0000. If you write to the location pointed to by a NULL pointer, you corrupt that data. When the executable is done running, it checks the data and spits out the message if it has been changed. One funny thing is that the actual "NULL pointer assignment" message is also in the general area, so it often comes out looking rather strange, at least with TC/TC++. As far as "better late than never," I wouldn't exactly call it "late." DOS is slow enough, and I wouldn't want it to be constantly checking for this throughout the execution of the program. The compiler would also have a hard time finding it. The message usually will come out every time you run the program, so you know the first time you run it. At that point you should immediately find the problem and fix it. I've redirected followups to comp.os.msdos.programmer in case this thread still refuses to die. --- Bob Rusbasan bob@en.ecn.purdue.edu