[ts-gen] MacOS Shim problems

[Bill Pippin]

Ric,

> Thanks for the quick turn around.

You're welcome.
 
> But the Mac build is still doing something wrong ...

Perhaps there is currently something wrong with gcc optimization for
the particular version of gcc provided by Apple; this problem occurred
in the past with Debian on one occasion, although -03 seems to be fine
now for that platform.  Please download the newest release, edit the
Makefile to eliminate the -O3 option from the CFLAGS variable, and see
if the shim works then.

> One question, could this have anything to do with the mysql build?

Conceivably, though that *can't* be the only problem; there is
definitely a problem with the sources and/or release and/or build,
and we have it narrowed down so tightly to one place in the code that
we should be close to finding it.  At this point I view possible
database problems as just a useful form of destructive testing.

If, after compiling without -03 and retesting, you still have what
seems to be the same problem, I believe build problems, although
still conceivable, are *very* unlikely.

At that point, please use the patch following my sig to collect
print_line() trace info.  As long as your downloaded sources patch
cleanly, we can be sure that, for the loop in question, the sources
you're compiling are the same as the ones I'm working with.  That
should eliminate release problems, leaving the code as the culprit,
which is after all the first suspect in any case.

> log of ./shim --data cout > ./log/capure090528.log 2>&1 attached ...

There's no need to use the cout option, or to merge stdout and sterr
via 2>&1; the stderr produced by print_line() is what I need here,
plus possibly more trace info from within the loop that just hasn't
occurred to me yet, simply because what we see seems so impossible.

According to your report, a loop not much different than the one below
produces the following [lightly edited] trace during startup:

    <     2 25811 51620 STK STK, CAD JPY, US JP, AUD !=     6155 ...
    >     2 12906 25810 STK STK, CAD USD, US US, AUD !=     UVCL ...
    > 12907 19358 25810 STK STK, CAD CAD, US CA, AUD != BSC.PR.A ...
    < 19359 22584 25810 STK STK, CAD CAD, US US, AUD !=      HPH ...
    < 19359 22584 25810 STK STK, CAD CAD, US US, AUD !=      HPH ...
    < 19359 22584 25810 STK STK, CAD CAD, US US, AUD !=      HPH ...

If you look at the loop in leaf.c [code below extracted from the
patch that follows my sig], I claim that the loop test variables
change state at every iteration, and in a way that is guaranteed
to narrow the interval or fail the test.  Yet that is not what
you have been seeing.  I can conceive of a number of ways in which
bugs elsewhere could cause the loop to fail prematurely, so that
search fails; what I can't imagine is how the state variables
can be steady state for loop test success. 
 
      for(nat i(mid(a, b)); a<=i && i<=b && b && !p; i = mid(a, b)) {
          switch((x = compare(v[i - 1]))) {
              case cmp::Lt: b = i - 1;				break;
              case cmp::Gt: a = i + 1;				break;
              case cmp::Eq: p = &v[i - 1];			break;
              default:      b = 0, enum_value_outside_range(f, x);
          }
      }

The key point in your trace report is the triple of lower bound, probe,
upper bound indices in the first three numeric columns.  The trace
you've reported shows that, for unsigned ints, (19359 + 25810) >> 1
is 22584, which is true, and goes on to claim that, after executing the
switch, a, b, and the pointer p remain unchanged, since the following
calls to print_line() show steady state --- that's what's so difficult
for me to understand when reading the code.  One way or another
something is wrong here, and as long as you can hang in there, we'll
find out what it is.

Thanks,

Bill

-------- cut here ------------------------------------------------------

*** old/leaf.c	Fri May 29 11:59:06 2009
--- new/leaf.c	Fri May 29 11:59:32 2009
***************
*** 175,189 ****
              b(v.size());
  
      for(nat i(mid(a, b)); a<=i && i<=b && b && !p; i = mid(a, b)) {
! //      print_line(v[i - 1], a, i, b, 0,
! //                  compare(v[i - 1]) );
          switch((x = compare(v[i - 1]))) {
              case cmp::Lt: b = i - 1;				break;
              case cmp::Gt: a = i + 1;				break;
              case cmp::Eq: p = &v[i - 1];			break;
              default:      b = 0, enum_value_outside_range(f, x);
          }
! //      print_line(v[i - 1], a, i, b, 1, x);
      }
  
      return p;
--- 175,189 ----
              b(v.size());
  
      for(nat i(mid(a, b)); a<=i && i<=b && b && !p; i = mid(a, b)) {
!         print_line(v[i - 1], a, i, b, 0,
!                     compare(v[i - 1]) );
          switch((x = compare(v[i - 1]))) {
              case cmp::Lt: b = i - 1;				break;
              case cmp::Gt: a = i + 1;				break;
              case cmp::Eq: p = &v[i - 1];			break;
              default:      b = 0, enum_value_outside_range(f, x);
          }
!         print_line(v[i - 1], a, i, b, 1, x);
      }
  
      return p;
*** old/else.c	Fri May 29 11:59:06 2009
--- new/else.c	Fri May 29 11:59:32 2009
***************
*** 772,778 ****
                          p.base.args.aaa(3).text() );
  //                      p.base.args[3].text() );
  
! //  if (snd)          fprintf(stderr, "\n");
      if (!x || a >= b) fprintf(stderr, "\n");
  }
  
--- 772,778 ----
                          p.base.args.aaa(3).text() );
  //                      p.base.args[3].text() );
  
!     if (snd)          fprintf(stderr, "\n");
      if (!x || a >= b) fprintf(stderr, "\n");
  }