Assignment problem with doubles: turning into NaN under Leopard

  • Hi guys,

    I am currently trying to track down a very strange problem that only
    occurs on Intel Macs under Leopard. At various locations in my
    application, assignments  from a method return value to a local double
    variable result in the variable containing NaN although the method
    result is 0.0.

    Example:

    - (double)methodValue
    {
    return 0.0;
    }

    - (void)test
    {
    double value = [self methodValue];

    if(isnan(value))
      NSLog(@"PROBLEM!");
    }

    The problem does not always occur, but is rather following strange
    patterns. It reproducibly occurs inside my application but not in any
    test case I constructed. The problem does not occur if I put a NSLog
    statement before the assignment. The problem in my case has definitely
    nothing to do with nil-messaging or threading.

    During today's research I found a similar case in the gcc mailing list
    from 1999
    http://gcc.gnu.org/ml/gcc-bugs/1999-10/msg00196.html
    This case was described as libc corrupting the FP stack so that
    following FP operations could fail.

    Has anybody encountered a similar problem in applications running on
    Intel machines under Leopard?

    Cheers

      Frank
  • If the compiler doesn't have an interface declaration for "methodValue"
    at the location of "test," you will get:
    (a) a compiler warning
    (b) results similar to what you describe

    Frank Illenberger wrote:
    > Hi guys,
    >
    > I am currently trying to track down a very strange problem that only
    > occurs on Intel Macs under Leopard. At various locations in my
    > application, assignments  from a method return value to a local double
    > variable result in the variable containing NaN although the method
    > result is 0.0.
    >
    > Example:
    >
    > - (double)methodValue
    > {
    > return 0.0;
    > }
    >
    > - (void)test
    > {
    > double value = [self methodValue];
    >
    > if(isnan(value))
    > NSLog(@"PROBLEM!");
    > }
    >
    >
    > The problem does not always occur, but is rather following strange
    > patterns. It reproducibly occurs inside my application but not in any
    > test case I constructed. The problem does not occur if I put a NSLog
    > statement before the assignment. The problem in my case has definitely
    > nothing to do with nil-messaging or threading.
    >
    > During today's research I found a similar case in the gcc mailing list
    > from 1999
    > http://gcc.gnu.org/ml/gcc-bugs/1999-10/msg00196.html
    > This case was described as libc corrupting the FP stack so that
    > following FP operations could fail.
    >
    > Has anybody encountered a similar problem in applications running on
    > Intel machines under Leopard?
    >
    > Cheers
    >
    > Frank
  • John,

    in my application, I certainly have an interface declaration for the
    method and I therefore don't get any warnings. Even in this example,
    the "methodValue" method stands before the caller. The problem does
    not seem to be trivial.

    Cheers

      Frank

    On 06.12.2007, at 20:10, John Stiles wrote:

    > If the compiler doesn't have an interface declaration for
    > "methodValue" at the location of "test," you will get:
    > (a) a compiler warning
    > (b) results similar to what you describe
    >
    >
    > Frank Illenberger wrote:
    >> Hi guys,
    >>
    >> I am currently trying to track down a very strange problem that
    >> only occurs on Intel Macs under Leopard. At various locations in my
    >> application, assignments  from a method return value to a local
    >> double variable result in the variable containing NaN although the
    >> method result is 0.0.
    >>
    >> Example:
    >>
    >> - (double)methodValue
    >> {
    >> return 0.0;
    >> }
    >>
    >> - (void)test
    >> {
    >> double value = [self methodValue];
    >> if(isnan(value))
    >> NSLog(@"PROBLEM!");
    >> }
    >>
    >>
    >> The problem does not always occur, but is rather following strange
    >> patterns. It reproducibly occurs inside my application but not in
    >> any test case I constructed. The problem does not occur if I put a
    >> NSLog statement before the assignment. The problem in my case has
    >> definitely nothing to do with nil-messaging or threading.
    >>
    >> During today's research I found a similar case in the gcc mailing
    >> list from 1999
    >> http://gcc.gnu.org/ml/gcc-bugs/1999-10/msg00196.html
    >> This case was described as libc corrupting the FP stack so that
    >> following FP operations could fail.
    >>
    >> Has anybody encountered a similar problem in applications running
    >> on Intel machines under Leopard?
    >>
    >> Cheers
    >>
    >> Frank
  • On 6 Dec 2007, at 19:29, Frank Illenberger wrote:

    > John,
    >
    > in my application, I certainly have an interface declaration for the
    > method and I therefore don't get any warnings. Even in this example,
    > the "methodValue" method stands before the caller. The problem does
    > not seem to be trivial.

    Can you show us the actual code that's triggering this problem?
    Presumably the example you gave does not (since you state that test
    cases don't reproduce the problem).  Also, check whether you have any
    #defines that might interfere with things.  For instance, if between
    the two methods you gave as an example, someone did

      #define methodValue foo

    then it might give the kind of results you're reporting.

    Also, try adjusting your compiler settings and see if e.g. turning off
    optimizations fixes the problem.  In particular, if you have set any
    settings in your application but not in your test cases, try changing
    those specific settings.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • Thanks for your hints. I just found the root of the problem:
    In my code, I put some calculation selectors on a custom stack to be
    performed at the end of a run loop iteration. These selectors are then
    executed by calling -[NSObject performSelector:withObject:]. One of
    the called methods in my code returns a double value whereas
    performSelector:withObject: expects an id return value. After 8
    repetitions, this mismatch lets the floating point stack overflow so
    that following floating point assignments result in getting a NaN.

    I managed to locate the root of the problem by using gdb's "info
    float" command which dumps the FP stack.

    Cheers

    Frank

    On 06.12.2007, at 19:11, Frank Illenberger wrote:

    > Hi guys,
    >
    > I am currently trying to track down a very strange problem that only
    > occurs on Intel Macs under Leopard. At various locations in my
    > application, assignments  from a method return value to a local
    > double variable result in the variable containing NaN although the
    > method result is 0.0.
    >
    > Example:
    >
    > - (double)methodValue
    > {
    > return 0.0;
    > }
    >
    > - (void)test
    > {
    > double value = [self methodValue];
    >
    > if(isnan(value))
    > NSLog(@"PROBLEM!");
    > }
    >
    >
    > The problem does not always occur, but is rather following strange
    > patterns. It reproducibly occurs inside my application but not in
    > any test case I constructed. The problem does not occur if I put a
    > NSLog statement before the assignment. The problem in my case has
    > definitely nothing to do with nil-messaging or threading.
    >
    > During today's research I found a similar case in the gcc mailing
    > list from 1999
    > http://gcc.gnu.org/ml/gcc-bugs/1999-10/msg00196.html
    > This case was described as libc corrupting the FP stack so that
    > following FP operations could fail.
    >
    > Has anybody encountered a similar problem in applications running on
    > Intel machines under Leopard?
    >
    > Cheers
    >
    > Frank
    >
    >
    >
previous month december 2007 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
31            
Go to today