From owner-freebsd-questions@FreeBSD.ORG Sat Mar 15 21:16:49 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2399A1065670 for ; Sat, 15 Mar 2008 21:16:49 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from betty.computinginnovations.com (mail.computinginnovations.com [64.81.227.250]) by mx1.freebsd.org (Postfix) with ESMTP id D34DD8FC26 for ; Sat, 15 Mar 2008 21:16:48 +0000 (UTC) (envelope-from derek@computinginnovations.com) Received: from p28.computinginnovations.com (dhcp-10-20-30-100.computinginnovations.com [10.20.30.100]) (authenticated bits=0) by betty.computinginnovations.com (8.14.2/8.13.8) with ESMTP id m2FLGSMt074593; Sat, 15 Mar 2008 16:16:29 -0500 (CDT) (envelope-from derek@computinginnovations.com) Message-Id: <6.0.0.22.2.20080315161039.0260cbe0@mail.computinginnovations.com> X-Sender: derek@mail.computinginnovations.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 15 Mar 2008 16:16:17 -0500 To: Chuck Robey From: Derek Ragona In-Reply-To: <47DC0136.5020707@chuckr.org> References: <6.0.0.22.2.20080314171533.023f7c88@mail.computinginnovations.com> <47DC0136.5020707@chuckr.org> Mime-Version: 1.0 X-Antivirus: avast! (VPS 080315-0, 03/15/2008), Outbound message X-Antivirus-Status: Clean X-ComputingInnovations-MailScanner-Information: Please contact the ISP for more information X-ComputingInnovations-MailScanner: Found to be clean X-ComputingInnovations-MailScanner-From: derek@computinginnovations.com X-Spam-Status: No Content-Type: text/plain; charset="us-ascii"; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-questions Subject: Re: C compiler issue perhaps? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2008 21:16:49 -0000 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.