lvw@rama.UUCP (Lyndon VanWagner) (09/11/90)
We have recently started using assertions in our C code. On the VAX, we have been able to redefine the assert macro to place us into the VMS debugger at the point of error, rather than just exiting the program. My question is this. Is it possible to do a similiar thing to Unix C and dbx? Any help in this area would be appreciated as we still have the VMS die-hards telling us how terrible Unix is and how great VMS is instead. Also, it would just help in general code development. Thanks. -- ----------------------------------------------------------------------------- Lyndon C. VanWagner UUCP: lvw@sc.harris.com Software Engineer -or- ...!rochester!tropix!rama!lvw Technical Support Group PHONE: (716) 924-9303 ext. 226 Harris Corporation, Scientific Calculations Division, Fishers, NY ----------------------------------------------------------------------------- Cornfield's Law (paraphrased): Before anything can change, everyone must agree. By the time that happens its a different problem. -----------------------------------------------------------------------------
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/21/90)
In article <10835@rama.UUCP> lvw@rama.UUCP (Lyndon VanWagner) writes: > On the VAX, we have been able to redefine the assert macro to place > us into the VMS debugger at the point of error, rather than just > exiting the program. [ and in UNIX? ] Why not just change the exit() to an abort()? Or, if you really want to hard-code dumping the user into the debugger: switch(fork()) { case -1: send some intelligent error message and die; case 0: abort(); default: wait((int *) 0); execlp("dbx","dbx",argv[0],(char *) 0); die horribly; } You should put this into a function so that the code isn't replicated at each assert(). (Side note: I typed that in without having to think about it. How long did your VMS solution take? Followups to alt.religion.computers.) ---Dan
karl@haddock.ima.isc.com (Karl Heuer) (09/22/90)
In article <14186:Sep2105:48:2290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <10835@rama.UUCP> lvw@rama.UUCP (Lyndon VanWagner) writes: >> On the VAX, we have been able to redefine the assert macro to place >> us into the VMS debugger at the point of error, rather than just >> exiting the program. > [ and in UNIX? ] > >Why not just change the exit() to an abort()? It already *is* an abort(). If you run the program from the debugger, it will stop when it gets the SIGABRT. Do you really need more than that? (Some versions of abort() also close the stdio streams first; I have mixed feelings about this since it makes it harder to do certain kinds of debugging.) Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/22/90)
In article <18100@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: > In article <14186:Sep2105:48:2290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >In article <10835@rama.UUCP> lvw@rama.UUCP (Lyndon VanWagner) writes: > > > On the VAX, we have been able to redefine the assert macro to place > > > us into the VMS debugger at the point of error, rather than just > > > exiting the program. > > [ and in UNIX? ] > > Why not just change the exit() to an abort()? [ followed by an explanation (deleted) of how to answer the question ] > It already *is* an abort(). No, it is not, on this Sun 4 at least. You should be scolded for not paying attention to portability. ( :-) ) > If you run the program from the debugger, it will > stop when it gets the SIGABRT. It may not be worth using the debugger all the time, even when you're developing the program. ---Dan
karl@haddock.ima.isc.com (Karl Heuer) (09/22/90)
In article <18373:Sep2203:32:0790@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >[assert() calls exit() rather than abort() on a Sun 4] So it does; how strange. This violates every standard I've heard of for assert(). Another nonstandard property of that implementation is that you need <stdio.h> as well as <assert.h>, which restriction is not mentioned by the man page. Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
peter@ficc.ferranti.com (Peter da Silva) (09/22/90)
[entering comp.os.misc territory] > > If you run the program from the debugger, it will > > stop when it gets the SIGABRT. > It may not be worth using the debugger all the time, even when you're > developing the program. In which case you get a core dump which you can fire up the debugger on. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
rankin@eql.caltech.edu (09/23/90)
In article <14186:Sep2105:48:2290@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: [... entering the debugger via assert()/abort() ...] > Side note: I typed that in without having to think about it. How long > did your VMS solution take? #include <ssdef.h> #define abort() LIB$SIGNAL(SS$_DEBUG)
evil@arcturus.uucp (Wade Guthrie) (09/24/90)
Lyndon VanWagner writes: > On the VAX, we have been able to redefine the assert macro to place > us into the VMS debugger at the point of error, rather than just > exiting the program. > My question is this. Is it possible to do a similiar thing to Unix C > and dbx? You don't have to! Just let the assertion dump core -- dbx (or dbxtool, if you're on a sun) can debug the core dump to put you at the statement where the core dump occurred. I don't remember whether the VMS debugger will allow one to debug a core dump (or, for that matter, whether VMS actually allows an assertion to dump core); if it does, you might try this approach rather than modifying the macro. Hope this helps. -- Wade Guthrie (evil@arcturus.UUCP) | "He gasped in terror at what sounded Rockwell International; Anaheim, CA | like a man trying to gargle while My opinions, not my employer's. | fighting off a pack of wolves" | Hitchhiker's Guide