PRODUCT  :  Borland C++                           NUMBER  :  1173
  VERSION  :  1.0
       OS  :  OS/2
     DATE  :  October 22, 1993                         PAGE  :  1/2

    TITLE  :  Configuring the Borland Tools under OS/2.





            OS/2 2.0. Operating system known Anomaly
            ========================================

       While using the Debugging Kernel:

       At some point when running Turbo Debugger for OS/2 2.0. you
  may encounter a full system halt.  The entire OS/2 2.0. operating
  system will come to a grinding halt.  The error message will
  display error in dbger.c at line 245. This is a known problem
  with the debugging kernel. Seems that although there is a halt
  generated the operating system is not damaged. So what can be
  done as a work around is to force the debugging kernel to run
  from the debugging terminal. I have found that usually you have
  to use the G command twice to allow the operating system restart.
  This works to start the system again but you will need to pop-up
  a full screen OS/2 or DOS session on the monitor in order to have
  PM repaint the desktop. Usually the desktop is trashed but the OS
  is fine.




  QUESTION:
       In a circustance where many threads are running under a
  debugging session and the threads are waiting for semaphores that
  are posted/reset by the other threads, the OS/2 2.0 debugging
  support has an oversight in it's design that can causes a system
  halt.

  ANSWER:
       OS/2 2.0. has provided no way to interrupt a API call until
  after the API function returns execution to the ring 3 program
  code.   What this means is that hitting control-break will not
  interrupt the program until the execution has return to the next
  line after the OS/2 2.0. API call.

  Lets say we have:

       Thread1:  Blocked on an event semaphore. This event
                 semaphore will be posted by THREAD2.

       Thread2:  Executing a lengthy task and then posting the













  PRODUCT  :  Borland C++                           NUMBER  :  1173
  VERSION  :  1.0
       OS  :  OS/2
     DATE  :  October 22, 1993                         PAGE  :  2/2

    TITLE  :  Configuring the Borland Tools under OS/2.




                 semaphore that Thread1 is blocked on.


  Under this debugging circumstance TD will hang if one tries to
  step or trace ( F7/F8 )thru the DosWaitEventSemaphore().  The
  reason being that the step/trace will not allow the debugger to
  give the other thread time slices.   Thus not allowing the
  semaphore to get posted and not allowing OS/2 to return from the
  OS/2 2.0. API where it can break program execution

       As a workaround one can set a breakpoint immediately after
  the 'DosWaitEventSemaphore()' and RUN the program. This will
  allow the debugger to give the other threads




  DISCLAIMER: You have the right to use this technical information
  subject to the terms of the No-Nonsense License Statement that
  you received with the Borland product to which this information
  pertains.