Variable evaluating improperly

  • A picture is worth a thousands words:

    http://highrolls.net/What.png

    You se the variable be DGProduct in the the variables display with a values of 0.

    You se the current location in the source which should only be possible if DGProduct != 0.

    What could possibly be the problem?

    -koko
  • On Apr 29, 2013, at 17:30, "koko" <koko...> wrote:

    > A picture is worth a thousands words:
    >
    > http://highrolls.net/What.png
    >
    >
    > You se the variable be DGProduct in the the variables display with a values of 0.
    >
    > You se the current location in the source which should only be possible if DGProduct != 0.
    >
    > What could possibly be the problem?

    Are you 100% sure it's showing the correct value? I've seen many cases where variable displays are wrong. Try running with gdb instead, changed in the scheme editor. Also try printfing it.

    Steve via iPad
  • On Mon, 29 Apr 2013 16:28:50 -0600, koko said:

    > A picture is worth a thousands words:
    >
    > http://highrolls.net/What.png
    >
    >
    > You se the variable be DGProduct in the the variables display with a
    > values of 0.
    >
    > You se the current location in the source which should only be possible
    > if DGProduct != 0.
    >
    > What could possibly be the problem?

    This happens to me very often with boolean values.  The debugger lies and say it's false when true, or vice verse.  My bug is <rdar://12816285>, which is 'closed' because Apple is unable to reproduce.  Not sure why, I see it every single day.  :(  If you have a repro case, please send it to them.

    Cheers,

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
  • Compilers often optimize flow of control statements in non-obvious ways (especially if the conditional expression is a compile time constant as it in your case). This can lead to misleading or even impossible seeming representations in debugger windows. Insert a printf statement to see if you really get into the then clause. Of course, this might also completely change any optimization rearrangements. All very Heisenbergian.

    Tom

    On Apr 29, 2013, at 6:28 PM, koko <koko...> wrote:

    > A picture is worth a thousands words:
    >
    > http://highrolls.net/What.png
    >
    >
    > You se the variable be DGProduct in the the variables display with a values of 0.
    >
    > You se the current location in the source which should only be possible if DGProduct != 0.
    >
    > What could possibly be the problem?
    >
    > -koko
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Xcode-users mailing list      (<Xcode-users...>)
    > Help/Unsubscribe/Update your Subscription:
    > https://lists.apple.com/mailman/options/xcode-users/<ttw4...>
    >
    > This email sent to <ttw4...>
  • On Mon, Apr 29, 2013 at 7:51 PM, Sean McBride <sean...> wrote:
    > On Mon, 29 Apr 2013 16:28:50 -0600, koko said:
    >
    >> A picture is worth a thousands words:
    >>
    >> http://highrolls.net/What.png
    >>
    >>
    >> You se the variable be DGProduct in the the variables display with a
    >> values of 0.
    >>
    >> You se the current location in the source which should only be possible
    >> if DGProduct != 0.
    >>
    >> What could possibly be the problem?
    >
    > This happens to me very often with boolean values.  The debugger lies and say it's false when true, or vice verse.  My bug is <rdar://12816285>, which is 'closed' because Apple is unable to reproduce.  Not sure why, I see it every single day.  :(  If you have a repro case, please send it to them.
    >
    Apple's Debug Information settings are 'DWARF' and 'DWARF with dSYM'.
    Both use '-g', which is equivalent to -g2'.

    -g3 will often give you better result. At -g3, even symbolic defines
    and macros are recorded in the debug information. To change to -g3,
    add it to 'Other C Flags'.

    There are lots of opportunities to set up a project more appropriately
    for both Debug and Release. Some of them are discussed at
    https://www.owasp.org/index.php/C-Based_Toolchain_Hardening. There's a
    radar filed to have Apple include some of them in the iOS and Mac OS X
    default schemes (Radar 12941954).

    Jeff
  • On Apr 29, 2013, at 5:54 PM, Thomas Wetmore <ttw4...> wrote:

    > Compilers often optimize flow of control statements in non-obvious ways (especially if the conditional expression is a compile time constant as it in your case). This can lead to misleading or even impossible seeming representations in debugger windows. Insert a printf statement to see if you really get into the then clause. Of course, this might also completely change any optimization rearrangements. All very Heisenbergian.

    In this case the above appears to be the case as I was running with the Release configuration.  Switching to Debug config it all looks well … but here is the kicker my Release build that is being purchased exhibits this behavior … !

    -koko
  • On Apr 30, 2013, at 11:36 AM, koko wrote:

    >> Compilers often optimize flow of control statements in non-obvious ways (especially if the conditional expression is a compile time constant as it in your case). This can lead to misleading or even impossible seeming representations in debugger windows. Insert a printf statement to see if you really get into the then clause. Of course, this might also completely change any optimization rearrangements. All very Heisenbergian.
    >
    > In this case the above appears to be the case as I was running with the Release configuration.  Switching to Debug config it all looks well … but here is the kicker my Release build that is being purchased exhibits this behavior … !

    Your code is running fine so there's no need to really worry. When it's just the debugger / Xcode that's displaying the wrong value it happens infrequently but it's a nuisance for sure. The only thing to do is try to find some way to reproduce it and file a bug on lldb and/or Xcode. I've had cases where Xcode shows a variable's value as A, 'print' in the debugger console shows it as B, and printf() in code shows it as C.

    In the past at least, when using gdb you generally won't see this problem but it can still happen. With lldb it happens far less frequently than it used to.

    --
    Seth Willits
  • On 30.04.2013, at 01:54, Thomas Wetmore wrote:

    > Compilers often optimize flow of control statements in non-obvious ways (especially if the conditional expression is a compile time constant as it in your case). This can lead to misleading or even impossible seeming representations in debugger windows. Insert a printf statement to see if you really get into the then clause. Of course, this might also completely change any optimization rearrangements. All very Heisenbergian.
    >
    > Tom

    DGProduct is certainly not a compile-time constant, otherwise the debugger wouldn't have a symbol reference for DGProduct. In other words, compile-time constants do not have a location in memory where its value is stored, that is they do not have an address.

    Btw: sometimes we might get confused by a linker error  about a "undefined symbol" from a compile-time constant. In fact there is no symbol for compile-time constants. In that case, your code is probably requiring the address (or a pointer or a C++ reference) of that constant, but it doesn't exist.  ;)
previous month april 2013 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
Go to today