From owner-freebsd-questions@FreeBSD.ORG Mon Mar 17 05:29:41 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 278F8106566C for ; Mon, 17 Mar 2008 05:29:41 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoot.lafn.org (zoot.lafn.ORG [206.117.18.6]) by mx1.freebsd.org (Postfix) with ESMTP id 0C17A8FC14 for ; Mon, 17 Mar 2008 05:29:40 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from [10.0.1.2] (pool-71-116-247-93.lsanca.dsl-w.verizon.net [71.116.247.93]) (authenticated bits=0) by zoot.lafn.org (8.13.6/8.13.4) with ESMTP id m2H5TZA4009232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Mar 2008 22:29:35 -0700 (PDT) (envelope-from bc979@lafn.org) Message-Id: <59E2AE8C-70D4-49C8-B495-0F7CCCB042DB@lafn.org> From: Doug Hardie To: Derek Ragona In-Reply-To: <6.0.0.22.2.20080315075146.02610a20@mail.computinginnovations.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 16 Mar 2008 22:29:34 -0700 References: <6.0.0.22.2.20080314171533.023f7c88@mail.computinginnovations.com> <511EC772-36FD-4799-B4A1-3AE690B6D048@lafn.org> <6.0.0.22.2.20080314202817.025de470@mail.computinginnovations.com> <6.0.0.22.2.20080315075146.02610a20@mail.computinginnovations.com> X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: ClamAV 0.88.7/6273/Sun Mar 16 20:03:58 2008 on zoot.lafn.org X-Virus-Status: Clean 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: Mon, 17 Mar 2008 05:29:41 -0000 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.