parker@waters.mpr.ca (Ross Parker) (05/03/89)
We have seen a bizarre problem with dbx when trying to debug a very large (tens of thousands of lines) application. This is Ultrix 2.2 on a Microvax II. The problem is that when a breakpoint is set in a particular function (i.e. 'stop in functionname'), the source displayed with 'list' is not always the first executable line of code. In the particular case that I just witnessed, the line that was displayed when the breakpoint was reached was about the fourth executable line. In addition, setting a function with 'func', then listing with 'list' does not always start listing at the first line within the function. It is exactly as if the source being read is different from the one used to compile with, but I know that's not true (yes, I have checked). Any ideas? Thanks! Ross Parker uunet!ubc-cs!mpre!parker | Microtel Pacific Research Ltd. | You can't erase the dream, Burnaby, B.C., | you can only wake me up... Canada, eh? |
apte@helios.cs.duke.edu (Jitendra Apte) (05/12/89)
In article <1666@eric.mpr.ca> parker@waters.mpr.ca (Ross Parker) writes: > >We have seen a bizarre problem with dbx when trying to debug a very large >(tens of thousands of lines) application. This is Ultrix 2.2 on a >Microvax II. The problem is that when a breakpoint is set in a particular >function (i.e. 'stop in functionname'), the source displayed with 'list' >is not always the first executable line of code. I have experienced similar problems, and was wondering what the world thinks of it. While stepping through a program, dbx says that it is at line number "XYZ" whereas control is actually a few lines ahead of "XYZ". It seems to be occuring because I have some character strings in my source code with escaped newlines in them. However, I may be wrong. eg : { char * p; p = "This is an example of the kind of string \ I was talking about"; } Any ideas as to whether this problem has been noticed before and if the reason stated above is correct? I am using dbx on a Sun4 running SunOS-3.2. Fangs a lot. Jitendra. (Internet) apte@cs.duke.edu; (UUCP) {decvax|ihnp4|allegra}!duke!apte "Let us save the kid from abortion, so that he can grow up to steal bread, rob banks and murder people. Then we can kill him in the electric chair".
peter@thirdi.UUCP (Peter Rowell) (05/16/89)
In article <14490@duke.cs.duke.edu> apte@helios.UUCP (Jitendra Apte) writes: >In article <1666@eric.mpr.ca> parker@waters.mpr.ca (Ross Parker) writes: >> >>We have seen a bizarre problem with dbx ... >>the source displayed with 'list' is not always the first executable line ... > >I have experienced similar problems, and was wondering ... > >While stepping through a program, dbx says that it is at line number >"XYZ" whereas control is actually a few lines ahead of "XYZ". It > ... More than likely it you have one (or more) invocations of a macro that takes 2 or more args. If you have a newline inside of the argument list, the cpp on many BSD systems (SysV, also?) will lose count of which source file line it is on. It normally happens that a #line directive is generated by cpp with the wrong line number. Since this is the info dbx (and any other source level debugger) is using for mapping address <=> line number, you can see why things look strange. As always, your macroage may vary. E.g. #define TakesTwo(a,b) a=b TakesTwo(foo, bar) /* this is fine */ TakesTwo(foo, /* <<== this causes the problem */ bar) ---------------------------------------------------------------------- Peter Rowell peter@thirdi.UUCP Third Eye Software, Inc. (415) 321-0967 Menlo Park, CA 94025 "No! Not the cat!"
meissner@tiktok.dg.com (Michael Meissner) (05/17/89)
In article <14490@duke.cs.duke.edu> apte@helios.UUCP (Jitendra Apte) writes: | In article <1666@eric.mpr.ca> parker@waters.mpr.ca (Ross Parker) writes: | > | >We have seen a bizarre problem with dbx when trying to debug a very large | >(tens of thousands of lines) application. This is Ultrix 2.2 on a | >Microvax II. The problem is that when a breakpoint is set in a particular | >function (i.e. 'stop in functionname'), the source displayed with 'list' | >is not always the first executable line of code. | | I have experienced similar problems, and was wondering what the world thinks of | it. | | While stepping through a program, dbx says that it is at line number | "XYZ" whereas control is actually a few lines ahead of "XYZ". It | seems to be occuring because I have some character strings in my source | code with escaped newlines in them. However, I may be wrong. Some problems may be tracable to the compiler that produced the debug information in the first place. I discovered that GNU CC was consistantly using the last line for a multiline statement instead of the first. The ultimate cause was GNU was using the contents the current line number and filename when it was processing the reductions. So I rolled up my sleeves, went in and modified the grammer to save the line number and filename at the beginning of a statement, and using the cached information when putting out the debug information. Perhaps the Sun compiler is doing the same thing? Another place to look is the preprocessor. See if the preprocessor is spitting out the correct line numbers for the compiler. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner If compiles were much Internet: meissner@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?