C compiler issue perhaps?

[Derek Ragona]

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.