dsims@uceng.UC.EDU (david l sims) (09/29/90)
I haven't been able to figure out how to control Turbo C's run time error messages. One particularly annoying message says at the end of the program, "null pointer assignment." I have no idea where I assigned some value to a null pointer, and even if I did, it doesn't seem to effect my programs. I don't like this statement coming up at the end of my program. Is there any way to turn run time error messages off? Does TC give any assistance in tracking down this error message?
iisakkil@niksula.hut.fi (Mika R Iisakkila) (09/30/90)
dsims@uceng.UC.EDU (david l sims) writes: > of the program, "null pointer assignment." I have no idea where > I assigned some value to a null pointer, and even if I did, it doesn't > seem to effect my programs. Have you modified the copyright message in the executable? Messing with the message :) will cause the "Null pointer assignment" warning (the start-up code calculates a check sum for the copyright message).
canderso@isis.cs.du.edu (Chuck Anderson) (10/01/90)
In article <6243@uceng.UC.EDU> dsims@uceng.UC.EDU (david l sims) writes: >error messages. One particularly annoying message says at the end >of the program, "null pointer assignment." I have no idea where >I assigned some value to a null pointer, and even if I did, it doesn't >seem to effect my programs. I don't like this statement coming up >at the end of my program. Is there any way to turn run time error >messages off? OUCH!! This one's gonna' bite you in the arse eventually. You're program is doing a wild write into memory. Change the environment and you could see some nasty *a*ffects. > Does TC give any assistance in tracking down this error. Well, do you have the debugger? I had this problem... once :^) and when I ran the debugger the environment was changed enough that the affect of this "null pointer" was quite obvious. Don't let this ride. It is something that you need to find! -- ********************************************************************** Chuck Anderson uucp : uunet!isis!nyx!cla Boulder, Co. (303) 494-6278 internet : cla@nyx.cs.du.edu **********************************************************************
hollen@megatek (Dion Hollenbeck) (10/01/90)
> I haven't been able to figure out how to control Turbo C's run time > error messages. One particularly annoying message says at the end > of the program, "null pointer assignment." I have no idea where > I assigned some value to a null pointer, and even if I did, it doesn't > seem to effect my programs. I don't like this statement coming up > at the end of my program. Is there any way to turn run time error > messages off? Does TC give any assistance in tracking down this error > message? Other posters have mentioned that this is because you either 1) changed the copyright message or 2) wrote to the environment. They are both somewhat accurate. The exact cause of this message is beause you changed the value of one of the bytes in the first 32H bytes of the data segment (DS:0 through DS:31). It just so happens that the BORLAND copyright message is there, the checking code does not really care that you changed the copyright message, it is specifically warning you that you screwed up badly somewhere in your program and used a NULL pointer. In the strictest definition, you would have changed the byte, word or longword at DS:0, bur BORLAND checks for the first 32H bytes. Both previous posters are correct, you MUST track this down. You do not know what other side effects you are causing. The way to track it down is to open up a window to watch memory and place it so it sees DS:0. Step through your program in large chunks until you find the chunk after which any byte down there has been changed. Keep dividing and re-checking until you have it down to a few lines of code. Then go back and set a breakpoint just before this section. Now, ask to watch the area of memory at DS:0. Tell TD to continue. Go make a cup of tea and relax, this will take a while. The debugger will stop at the exact line of code which writes to the "NULL POINTER" area. Now all you need to do is figure how the pointer you are using there go messed up. You may want to eliminate the divide and conquer portion I suggest, but I would advise against it. When I tried to to this the first time, a program which displayed its sign on screen in less than 2 seconds took over 2 hours to display it. The reason is that TD stores a copy of the area you wish to watch. After every machine instruction, it stops and compares the stored memory with the actual memory. You really don't want to do this. -- Dion Hollenbeck (619) 455-5590 x2814 Megatek Corporation, 9645 Scranton Road, San Diego, CA 92121 uunet!megatek!hollen or hollen@megatek.uucp
stever@Octopus.COM (Steve Resnick ) (10/02/90)
In article <1990Sep30.210345.1361@isis.cs.du.edu> canderso@isis.UUCP (Chuck Anderson) writes: >In article <6243@uceng.UC.EDU> dsims@uceng.UC.EDU (david l sims) writes: > >>error messages. One particularly annoying message says at the end >>of the program, "null pointer assignment." I have no idea where >>I assigned some value to a null pointer, and even if I did, it doesn't >>seem to effect my programs. I don't like this statement coming up >>at the end of my program. Is there any way to turn run time error >>messages off? > >OUCH!! This one's gonna' bite you in the arse eventually. You're program is >doing a wild write into memory. Change the environment and you could see some >nasty *a*ffects. > >> Does TC give any assistance in tracking down this error. > >Well, do you have the debugger? I had this problem... once :^) and when I ran >the debugger the environment was changed enough that the affect of this "null >pointer" was quite obvious. > >Don't let this ride. It is something that you need to find! > This is something in the FAQ list posted monthly. The "null pointer assignment" message comes from the tiny, small (and probably medium) memory model runtime. What happens, is that NULL points to DS:0. The data there is checksum'd. If the checksum doesn't match, the runtime assumes you have assigned a value to a NULL pointer. Watching DS:0 - DS:10 will most likely show you your error. Note, that if this were compact, large or huge memory model, you would not get this message and end up trashing your interrupt vector table instead since NULL in those models points to 0:0. Hope this helps and sorry (for you other netlanders) for wasting bandwith on a FAQ. Steve -- ---------------------------------------------------------------------------- steve.resnick@f105.n143.z1.FIDONET.ORG - or - apple!camphq!105!steve.resnick Flames, grammar errors, spelling errrors >/dev/nul ----------------------------------------------------------------------------
jpd@pc.usl.edu (Dugal James P.) (10/02/90)
In article <6243@uceng.UC.EDU> dsims@uceng.UC.EDU (david l sims) writes: >error messages. One particularly annoying message says at the end >of the program, "null pointer assignment." I have no idea where ... >messages off? Does TC give any assistance in tracking down this error >message? The Turbo C++ helpme!.doc file says: Q. How can I find out where my "null pointer assignment" is occurring? A. Set a watch on the following expressions: *(char *)0,4m (char *)4 Step through the program. When the values change, the just-executed line is the one that is causing the problem. Q. My program comes up with the message 'Null pointer assignment' after it terminates. What does this mean? A. Before a small-data model Turbo C++ program returns to DOS, it will check to see if the beginning of its data segment has been corrupted. This message is to warn you that you have used uninitialized pointers or that your program has corrupted memory in some other way. -- -- James Dugal, N5KNX Internet: jpd@usl.edu Associate Director Ham packet: n5knx@k5arh Computing Center US Mail: PO Box 42770 Lafayette, LA 70504 University of Southwestern LA. Tel. 318-231-6417 U.S.A.
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (10/02/90)
In article <HOLLEN.90Oct1075122@akbar.megatek> hollen@megatek (Dion Hollenbeck) writes: (about tracking down code which writes to DS:0): >You may want to eliminate the divide and conquer portion I suggest, >but I would advise against it. When I tried to to this the first >time, a program which displayed its sign on screen in less than 2 >seconds took over 2 hours to display it. The reason is that TD >stores a copy of the area you wish to watch. After every machine >instruction, it stops and compares the stored memory with the actual >memory. You really don't want to do this. If you're lucky enough to have a 386 or 486, you can save a lot of time by running TD386 and setting a hardware breakpoint which breaks on a write to that location. Your program runs full speed until it gets there. This works in TD 1.5; the details may have changed in TD 2.0. Duncan Murdoch dmurdoch@watstat.waterloo.edu