Re: C compiler issue perhaps?
At 12:29 AM 3/17/2008, Doug Hardie wrote: On Mar 15, 2008, at 05:59, Derek Ragona wrote: At 09:49 PM 3/14/2008, Doug Hardie wrote: On Mar 14, 2008, at 18:31, Derek Ragona wrote: At 06:56 PM 3/14/2008, Doug Hardie wrote: There is no code running at that point. Its just sitting there waiting for me to enter a gdb command. On Mar 14, 2008, at 15:16, Derek Ragona wrote: At 05:10 PM 3/14/2008, Doug Hardie wrote: I have a program I was testing with gdb. I was trying to figure out why c.rmonths was always zero when it should have been 6. Stepped through using the gdb n command. Here is the output: (gdb) 215 c.rmonths = (edate - tdate) / toMONTHS; (gdb) 223 c.dial_in = u.dial_in[0]; (gdb) 224 c.dsl = u.dsl[0]; (gdb) p c.rmonths $1 = 0 (gdb) p c $2 = {fa = 0, pwp = 0, disp_email = 0, imonths = 0, rmonths = 6, type = 73 'I', cd = 0 '\0', dial_in = 82 'R', dsl = 0 '\0', dsl_kit = 0 '\0', ip = 0 '\0', domain = 0 '\0', n_domain = 0 '\0', renewal = 89 'Y', program = "I\000\000"} (gdb) p c->rmonths $3 = 6 (gdb) p c.rmonths $4 = 6 Notice, the first time i print it its zero. The second time its 6. What gives here? I have seen this before but couldn't pin it down. The program is not compiled with any optimization. It is in a shared library though. It is hard to tell without the code you used. I would put some printf's in the code and see what and when that variable gets set to in actual running code. -Derek I understand it is waiting at a breakpoint in gdb. What I meant was put printf's in your code and run the program and look at the output. You can use fprintf's to stderr if your prefer and just look at the stderr output. It is hard to diagnose what could be a compiler error, or a coding error. Remember in C you can do many things you really shouldn't. It is also advisable to run lint over your source code too. All that lint shows is it doesn't like comments using // and lots of errors in /usr/include files. This sounds more like a c++ program. c++ does a lot of variable initiation in code you usually won't see. If this is a c++ program, put conditional printf's or cout's in to check the code at actual runtime rather than in the debugger. You may want to use asserts. Nope. Very simple c code. I believe as was pointed out earlier that this is a gdb issue. Once gdb found the right value, both it and all the printfs show the correct value. I changed nothing. I am a bit concerned since this is now in a production system that it may eventually start fail again which would have some serious consequences. Doug, That reason is why you should put asserts in your program. Also check your /etc/make.conf file as well as your program's Makefile for any compiler options you may be using. Another option you may want to explore is trying a different version of gcc. There are a few versions of gcc in the ports you can install and try on your program. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: C compiler issue perhaps?
On Mar 15, 2008, at 05:59, Derek Ragona wrote: At 09:49 PM 3/14/2008, Doug Hardie wrote: On Mar 14, 2008, at 18:31, Derek Ragona wrote: At 06:56 PM 3/14/2008, Doug Hardie wrote: There is no code running at that point. Its just sitting there waiting for me to enter a gdb command. On Mar 14, 2008, at 15:16, Derek Ragona wrote: At 05:10 PM 3/14/2008, Doug Hardie wrote: I have a program I was testing with gdb. I was trying to figure out why c.rmonths was always zero when it should have been 6. Stepped through using the gdb n command. Here is the output: (gdb) 215 c.rmonths = (edate - tdate) / toMONTHS; (gdb) 223 c.dial_in = u.dial_in[0]; (gdb) 224 c.dsl = u.dsl[0]; (gdb) p c.rmonths $1 = 0 (gdb) p c $2 = {fa = 0, pwp = 0, disp_email = 0, imonths = 0, rmonths = 6, type = 73 'I', cd = 0 '\0', dial_in = 82 'R', dsl = 0 '\0', dsl_kit = 0 '\0', ip = 0 '\0', domain = 0 '\0', n_domain = 0 '\0', renewal = 89 'Y', program = "I\000\000"} (gdb) p c->rmonths $3 = 6 (gdb) p c.rmonths $4 = 6 Notice, the first time i print it its zero. The second time its 6. What gives here? I have seen this before but couldn't pin it down. The program is not compiled with any optimization. It is in a shared library though. It is hard to tell without the code you used. I would put some printf's in the code and see what and when that variable gets set to in actual running code. -Derek I understand it is waiting at a breakpoint in gdb. What I meant was put printf's in your code and run the program and look at the output. You can use fprintf's to stderr if your prefer and just look at the stderr output. It is hard to diagnose what could be a compiler error, or a coding error. Remember in C you can do many things you really shouldn't. It is also advisable to run lint over your source code too. All that lint shows is it doesn't like comments using // and lots of errors in /usr/include files. This sounds more like a c++ program. c++ does a lot of variable initiation in code you usually won't see. If this is a c++ program, put conditional printf's or cout's in to check the code at actual runtime rather than in the debugger. You may want to use asserts. Nope. Very simple c code. I believe as was pointed out earlier that this is a gdb issue. Once gdb found the right value, both it and all the printfs show the correct value. I changed nothing. I am a bit concerned since this is now in a production system that it may eventually start fail again which would have some serious consequences. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: C compiler issue perhaps?
At 12:02 PM 3/15/2008, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Ragona wrote: > At 05:10 PM 3/14/2008, Doug Hardie wrote: >> I have a program I was testing with gdb. I was trying to figure out >> why c.rmonths was always zero when it should have been 6. Stepped >> through using the gdb n command. Here is the output: >> >> (gdb) >> 215 c.rmonths = (edate - tdate) / toMONTHS; >> (gdb) >> 223 c.dial_in = u.dial_in[0]; >> (gdb) >> 224 c.dsl = u.dsl[0]; >> (gdb) p c.rmonths >> $1 = 0 >> (gdb) p c >> $2 = {fa = 0, pwp = 0, disp_email = 0, imonths = 0, rmonths = 6, >> type = 73 'I', cd = 0 '\0', dial_in = 82 'R', dsl = 0 '\0', >> dsl_kit = 0 '\0', ip = 0 '\0', domain = 0 '\0', n_domain = 0 '\0', >> renewal = 89 'Y', program = "I\000\000"} >> (gdb) p c->rmonths >> $3 = 6 >> (gdb) p c.rmonths >> $4 = 6 >> >> >> Notice, the first time i print it its zero. The second time its 6. >> What gives here? I have seen this before but couldn't pin it down. >> The program is not compiled with any optimization. It is in a shared >> library though. > > It is hard to tell without the code you used. I would put some printf's > in the code and see what and when that variable gets set to in actual > running code. 2points: (1) yes, you are right, without the source code, any guesses are at the same level as black magic, useless (2) if the user is learning to use gdb, then it is really bad manners to suggest that printfs should be used. While I have made massive use of printfs before I got used to gdb, gdb is incredibly more powerful, can do any and all that any prints might accomplish, and anyone who is willing to learn to use that debugger should be encouraged, not given bad habits that really should be a fallback only to environments where gdb won't work. Chuck, On your point 2 let me say that there are simply times when a developer needs to check run-time code versus running the code in a debugger. Debuggers are a great tool, but they do cause some side-effects as was noted in the original post. If the debugger is not consistent in the variable values, it is of little use if those values are causing a problem. What I originally suggested was using conditionally compiled fprintf's to check those variable values running the program by itself instead of inside gdb. I know adding additional code, even just fprintf's, can change the way a program is compiled and optimized. But this at least gives another way to validate the variables. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: C compiler issue perhaps?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Ragona wrote: > At 05:10 PM 3/14/2008, Doug Hardie wrote: >> I have a program I was testing with gdb. I was trying to figure out >> why c.rmonths was always zero when it should have been 6. Stepped >> through using the gdb n command. Here is the output: >> >> (gdb) >> 215 c.rmonths = (edate - tdate) / toMONTHS; >> (gdb) >> 223 c.dial_in = u.dial_in[0]; >> (gdb) >> 224 c.dsl = u.dsl[0]; >> (gdb) p c.rmonths >> $1 = 0 >> (gdb) p c >> $2 = {fa = 0, pwp = 0, disp_email = 0, imonths = 0, rmonths = 6, >> type = 73 'I', cd = 0 '\0', dial_in = 82 'R', dsl = 0 '\0', >> dsl_kit = 0 '\0', ip = 0 '\0', domain = 0 '\0', n_domain = 0 '\0', >> renewal = 89 'Y', program = "I\000\000"} >> (gdb) p c->rmonths >> $3 = 6 >> (gdb) p c.rmonths >> $4 = 6 >> >> >> Notice, the first time i print it its zero. The second time its 6. >> What gives here? I have seen this before but couldn't pin it down. >> The program is not compiled with any optimization. It is in a shared >> library though. > > It is hard to tell without the code you used. I would put some printf's > in the code and see what and when that variable gets set to in actual > running code. 2points: (1) yes, you are right, without the source code, any guesses are at the same level as black magic, useless (2) if the user is learning to use gdb, then it is really bad manners to suggest that printfs should be used. While I have made massive use of printfs before I got used to gdb, gdb is incredibly more powerful, can do any and all that any prints might accomplish, and anyone who is willing to learn to use that debugger should be encouraged, not given bad habits that really should be a fallback only to environments where gdb won't work. > > -Derek > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3AE2z62J6PPcoOkRAsOeAJ9ZcF4K9Rtonrw5oQXVF3opoxvBjgCcDGJR szL8DpVrdPjMMpV4+I+bTg0= =RKOo -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: C compiler issue perhaps?
At 09:49 PM 3/14/2008, Doug Hardie wrote: On Mar 14, 2008, at 18:31, Derek Ragona wrote: At 06:56 PM 3/14/2008, Doug Hardie wrote: There is no code running at that point. Its just sitting there waiting for me to enter a gdb command. On Mar 14, 2008, at 15:16, Derek Ragona wrote: At 05:10 PM 3/14/2008, Doug Hardie wrote: I have a program I was testing with gdb. I was trying to figure out why c.rmonths was always zero when it should have been 6. Stepped through using the gdb n command. Here is the output: (gdb) 215 c.rmonths = (edate - tdate) / toMONTHS; (gdb) 223 c.dial_in = u.dial_in[0]; (gdb) 224 c.dsl = u.dsl[0]; (gdb) p c.rmonths $1 = 0 (gdb) p c $2 = {fa = 0, pwp = 0, disp_email = 0, imonths = 0, rmonths = 6, type = 73 'I', cd = 0 '\0', dial_in = 82 'R', dsl = 0 '\0', dsl_kit = 0 '\0', ip = 0 '\0', domain = 0 '\0', n_domain = 0 '\0', renewal = 89 'Y', program = "I\000\000"} (gdb) p c->rmonths $3 = 6 (gdb) p c.rmonths $4 = 6 Notice, the first time i print it its zero. The second time its 6. What gives here? I have seen this before but couldn't pin it down. The program is not compiled with any optimization. It is in a shared library though. It is hard to tell without the code you used. I would put some printf's in the code and see what and when that variable gets set to in actual running code. -Derek I understand it is waiting at a breakpoint in gdb. What I meant was put printf's in your code and run the program and look at the output. You can use fprintf's to stderr if your prefer and just look at the stderr output. It is hard to diagnose what could be a compiler error, or a coding error. Remember in C you can do many things you really shouldn't. It is also advisable to run lint over your source code too. All that lint shows is it doesn't like comments using // and lots of errors in /usr/include files. This sounds more like a c++ program. c++ does a lot of variable initiation in code you usually won't see. If this is a c++ program, put conditional printf's or cout's in to check the code at actual runtime rather than in the debugger. You may want to use asserts. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: C compiler issue perhaps?
On Mar 14, 2008, at 18:31, Derek Ragona wrote: At 06:56 PM 3/14/2008, Doug Hardie wrote: There is no code running at that point. Its just sitting there waiting for me to enter a gdb command. On Mar 14, 2008, at 15:16, Derek Ragona wrote: At 05:10 PM 3/14/2008, Doug Hardie wrote: I have a program I was testing with gdb. I was trying to figure out why c.rmonths was always zero when it should have been 6. Stepped through using the gdb n command. Here is the output: (gdb) 215 c.rmonths = (edate - tdate) / toMONTHS; (gdb) 223 c.dial_in = u.dial_in[0]; (gdb) 224 c.dsl = u.dsl[0]; (gdb) p c.rmonths $1 = 0 (gdb) p c $2 = {fa = 0, pwp = 0, disp_email = 0, imonths = 0, rmonths = 6, type = 73 'I', cd = 0 '\0', dial_in = 82 'R', dsl = 0 '\0', dsl_kit = 0 '\0', ip = 0 '\0', domain = 0 '\0', n_domain = 0 '\0', renewal = 89 'Y', program = "I\000\000"} (gdb) p c->rmonths $3 = 6 (gdb) p c.rmonths $4 = 6 Notice, the first time i print it its zero. The second time its 6. What gives here? I have seen this before but couldn't pin it down. The program is not compiled with any optimization. It is in a shared library though. It is hard to tell without the code you used. I would put some printf's in the code and see what and when that variable gets set to in actual running code. -Derek I understand it is waiting at a breakpoint in gdb. What I meant was put printf's in your code and run the program and look at the output. You can use fprintf's to stderr if your prefer and just look at the stderr output. It is hard to diagnose what could be a compiler error, or a coding error. Remember in C you can do many things you really shouldn't. It is also advisable to run lint over your source code too. All that lint shows is it doesn't like comments using // and lots of errors in /usr/include files. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: C compiler issue perhaps?
At 06:56 PM 3/14/2008, Doug Hardie wrote: There is no code running at that point. Its just sitting there waiting for me to enter a gdb command. On Mar 14, 2008, at 15:16, Derek Ragona wrote: At 05:10 PM 3/14/2008, Doug Hardie wrote: I have a program I was testing with gdb. I was trying to figure out why c.rmonths was always zero when it should have been 6. Stepped through using the gdb n command. Here is the output: (gdb) 215 c.rmonths = (edate - tdate) / toMONTHS; (gdb) 223 c.dial_in = u.dial_in[0]; (gdb) 224 c.dsl = u.dsl[0]; (gdb) p c.rmonths $1 = 0 (gdb) p c $2 = {fa = 0, pwp = 0, disp_email = 0, imonths = 0, rmonths = 6, type = 73 'I', cd = 0 '\0', dial_in = 82 'R', dsl = 0 '\0', dsl_kit = 0 '\0', ip = 0 '\0', domain = 0 '\0', n_domain = 0 '\0', renewal = 89 'Y', program = "I\000\000"} (gdb) p c->rmonths $3 = 6 (gdb) p c.rmonths $4 = 6 Notice, the first time i print it its zero. The second time its 6. What gives here? I have seen this before but couldn't pin it down. The program is not compiled with any optimization. It is in a shared library though. It is hard to tell without the code you used. I would put some printf's in the code and see what and when that variable gets set to in actual running code. -Derek I understand it is waiting at a breakpoint in gdb. What I meant was put printf's in your code and run the program and look at the output. You can use fprintf's to stderr if your prefer and just look at the stderr output. It is hard to diagnose what could be a compiler error, or a coding error. Remember in C you can do many things you really shouldn't. It is also advisable to run lint over your source code too. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: C compiler issue perhaps?
There is no code running at that point. Its just sitting there waiting for me to enter a gdb command. On Mar 14, 2008, at 15:16, Derek Ragona wrote: At 05:10 PM 3/14/2008, Doug Hardie wrote: I have a program I was testing with gdb. I was trying to figure out why c.rmonths was always zero when it should have been 6. Stepped through using the gdb n command. Here is the output: (gdb) 215 c.rmonths = (edate - tdate) / toMONTHS; (gdb) 223 c.dial_in = u.dial_in[0]; (gdb) 224 c.dsl = u.dsl[0]; (gdb) p c.rmonths $1 = 0 (gdb) p c $2 = {fa = 0, pwp = 0, disp_email = 0, imonths = 0, rmonths = 6, type = 73 'I', cd = 0 '\0', dial_in = 82 'R', dsl = 0 '\0', dsl_kit = 0 '\0', ip = 0 '\0', domain = 0 '\0', n_domain = 0 '\0', renewal = 89 'Y', program = "I\000\000"} (gdb) p c->rmonths $3 = 6 (gdb) p c.rmonths $4 = 6 Notice, the first time i print it its zero. The second time its 6. What gives here? I have seen this before but couldn't pin it down. The program is not compiled with any optimization. It is in a shared library though. It is hard to tell without the code you used. I would put some printf's in the code and see what and when that variable gets set to in actual running code. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: C compiler issue perhaps?
At 05:10 PM 3/14/2008, Doug Hardie wrote: I have a program I was testing with gdb. I was trying to figure out why c.rmonths was always zero when it should have been 6. Stepped through using the gdb n command. Here is the output: (gdb) 215 c.rmonths = (edate - tdate) / toMONTHS; (gdb) 223 c.dial_in = u.dial_in[0]; (gdb) 224 c.dsl = u.dsl[0]; (gdb) p c.rmonths $1 = 0 (gdb) p c $2 = {fa = 0, pwp = 0, disp_email = 0, imonths = 0, rmonths = 6, type = 73 'I', cd = 0 '\0', dial_in = 82 'R', dsl = 0 '\0', dsl_kit = 0 '\0', ip = 0 '\0', domain = 0 '\0', n_domain = 0 '\0', renewal = 89 'Y', program = "I\000\000"} (gdb) p c->rmonths $3 = 6 (gdb) p c.rmonths $4 = 6 Notice, the first time i print it its zero. The second time its 6. What gives here? I have seen this before but couldn't pin it down. The program is not compiled with any optimization. It is in a shared library though. It is hard to tell without the code you used. I would put some printf's in the code and see what and when that variable gets set to in actual running code. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
C compiler issue perhaps?
I have a program I was testing with gdb. I was trying to figure out why c.rmonths was always zero when it should have been 6. Stepped through using the gdb n command. Here is the output: (gdb) 215 c.rmonths = (edate - tdate) / toMONTHS; (gdb) 223 c.dial_in = u.dial_in[0]; (gdb) 224 c.dsl = u.dsl[0]; (gdb) p c.rmonths $1 = 0 (gdb) p c $2 = {fa = 0, pwp = 0, disp_email = 0, imonths = 0, rmonths = 6, type = 73 'I', cd = 0 '\0', dial_in = 82 'R', dsl = 0 '\0', dsl_kit = 0 '\0', ip = 0 '\0', domain = 0 '\0', n_domain = 0 '\0', renewal = 89 'Y', program = "I\000\000"} (gdb) p c->rmonths $3 = 6 (gdb) p c.rmonths $4 = 6 Notice, the first time i print it its zero. The second time its 6. What gives here? I have seen this before but couldn't pin it down. The program is not compiled with any optimization. It is in a shared library though. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"