Debugging Mutex and Locks

When there are multiple Mutex's in the program, it may be required to find if a particular thread is locked far longer than necessary. This can cause problems and the output may not be what is expected.

To get round this, I took an old example from here and modified it to help me print some debugging info.

I modified the printSomething() in Singleton.h to add a sleep as follows:

  void printSomething(char *name, int count)
 {
   Lock guard(mutex_);
   Sleep(10);
   Lock guard2(mutex_);
   std::cout << name << " loop " << count << std::endl;
 }

and I modified the Mutex.h as follows:

//Example from http://www.relisoft.com/Win32/active.html
#if !defined _MUTEX_H_
#define _MUTEX_H_

class Mutex
{
   friend class Lock;
public:
   Mutex () { InitializeCriticalSection (& _critSection); }
   ~Mutex () { DeleteCriticalSection (& _critSection); }
private:
   void Acquire ()
   {
     DWORD start = GetTickCount();
     EnterCriticalSection (& _critSection);
     DWORD elapsed = GetTickCount() - start;
     if (elapsed > 15)
     {
       //Debugging Info
        std::cout<<"Debugging Info: Waited at mutex for "<<elapsed<<std::endl;
     }
   }
   void Release ()
   {
       LeaveCriticalSection (& _critSection);
   }

   CRITICAL_SECTION _critSection;
};

#endif 

The output is as follows:

The small problem with the above approach is that if a Thread is deadlocked, we may not get the debug output as we would have to kill the process.

Consequences of Ignoring Compiler Warnings

Though this is a fictional program that I have picked up from here, I have seen similar problems in real life.

Lets say my program (below) was expected to return this

but instead returned:

Program as follows:

//Program tested on Microsoft Visual Studio 2008 - Zahid Ghadialy
#include<iostream>

using namespace std;

class Bclass
{
public:
 Bclass() {}
 virtual void func()
 {
   cout<<"In Bclass::func()"<<endl;
 }
};

class Dclass : public Bclass
{
public:
 Dclass() {}
 virtual void func()
 {
   cout<<"In Dclass::func()"<<endl;
   Bclass:func();
 }
};

int main()
{
 Dclass d;
 d.func();
 //...
  return 0;
}

The clue of the problem was given by the compiler that generated the following warning:

main.cpp(23) : warning C4102: 'Bclass' : unreferenced label

pointing to the line

Bclass:func();

The problem lies in the fact that due to a single : rather than :: the line above is being treated as label and since its an unreferenced label it goes back to the start of the same function.

You can read the complete discussion here. Make sure to check the warnings the next time your program behaves unexpectedly.

Debugging Run BASIC Web Apps

In Run BASIC's first release there is effectively no built-in debugger. Of course you can use print to log to the browser page or to a file, and this is no more or less than many other web scripting systems. We aim to do something about this in the very near future.

One of our users suggested that it would be good to create an inspector panel in Run BASIC itself and that we should add some reflection via an EVAL$() function that would allow arbitrary execution of BASIC code at runtime. We would probably also need to at least metaprogramming features like the ability to get information from the runtime like:

• The name of the current context (ie. function or subroutine)
• The names of all the variables and arrays in scope
• The source code for the current context
• A collection of objects that models the stack
• Probably more stuff

While this sort of thing is possible I think that we probably will initially provide a high level runtime inspection panel that the programmer can show and hide as needed. This is BASIC after all, and it should be as easy as possible to use. The metaprogramming stuff is cool though. ;-)

Web Debugging

The topic of web debugging in Run BASIC came up today in the forums, and the topic started with some ambitious ideas from Bill W. who always has something interesting to say (here for example).

Run BASIC does need a debugging facility. I realize that most web programmers probably write to logs, and you can do that in RB without adding anything but we can make it a lot easier. Just for starters I was thinking of adding a logging object of some kind. A debug button would be added to the toolbar, and then you could specify either logging of all variable changes, or specify watches so that only certain variables would get logged, and a LOG statement could also be added that would only log if the program is executed in debug mode (instead of merely run).

Also, it would be no hard matter to include an inspector object which could be rendered into the page whereever it is convenient for the programmer. You could examine and change the value of variables, and perhaps even execute code dynamically on a running program in the web browser.

I'm eager for feedback on this!