Saturday, October 29, 2011

Static/global variable and shared library behaviour

[Note : This would be a very long discussion and reader would need considerable amount of time to complete the reading]

Problem Description
Let's take an example of a class having a static variable or a global variable.  

Header file : x.h
extern int g_s;

class XYZ
        static int s;
        static int getInt();
Implementation file:x.cpp

int XYZ::s = 777;
int g_s = 7;
int XYZ::getInt()
  return s;

Now let us go through below questions (Little Quiz) and answer them
  • What is the scope of global variable (g_s) and static class variable (XYZ::s)? 
    • Naturally, the answer would be global. 
    • For class static data member variable, the scope would be global with additional limitation of privilage (i.e all objects belonging to XYZ in the executable will have only one copy of s and only accessible for class interface).
  • How many copies of the variable exists? 
    • One 
Are the above answers really correct? What happens in case of executable involving multiple shared libraries (so's) - each having object files of x (i.e x.o)? 
We will explore these and come back questions (Little Quiz) and re-answer them in the end.


Consider that you are building and executable a.exe.
Now this executable consists of many objects and libraries - as shown in below diagram.

  1. consists of 3 objects X.o, Y.o and Z.o 
  2. consists of 3 objects V.o, W.o and X.o 
  3. consists of 3 objects W.o, X.o and Y.o 
  4. and, the executable a.exe consists of  
    1. objects X.o, M.o and A.o and  
    2. shared libraries (linked using -L/-l option in make file), and 
From the diagram,you can see that there are 4 copies of the x.o present in the final executable (represented by 4 copies of x.o object). Thus in the final executable, there are 4 copies of the static variable X::s in the system.
  • Does Building the executable like the above throw linker error during compilation (complaining of multiple definitions)? 
    • Surprisingly No!!!. From a detailed study I have done, the multiple definition is determined based on certain rule set - described below.
    • If the same symbol is found among the peers of objects and/or static library then it is flagged as error during compilation.For example
      • if and only if X.o and M.o contains same symbol, then it is flagged as an error - in case of bulding executable.
      • if and only if X.o and Y.o contains same symbol, then it is flagged as an error - in case of bulding a shared library.   
    •  During linking (last stage of execution building), the shared library symbols are not resolved. That means, linker will not go into the symbol definitions present in any of the linker - in case it is already present in the object file of the executable.
  • Now let us come to the most interesting fact, In such circumstances, which symbol is used? 
    • It depends on the OS. 
        SUSE 10 Linux: 
        Here, the first encountered symbol is always placed in the Global Symbol Table (GST).
        So during execution symbol resolution from any of the library, the GST is dipped into and     would always gets the first symbol - leading to always pointing to same copy of the variable. 

        Here, when the execution flows through a library, it would refer to its "global" variable in the scope of its library. This can be visualized as GST containing global variable with the resolution of the library name also.
       This is contrary to SUSE Linux.

In short, SUSE Linux seems to have a single copy of reference for the global variable across all the libraries, overlapping objects in the executable. However, HPUX seems to have global copy for each library and it would be referenced during the execution. 
  • Doesn't it lead to different kind of behavior in both SUSE and HPUX OS for the same machine?
    • Yes, Try it out!!!

  • How to avoid this kind of problem? 
    • The main problem in this example, is the use of global objects/static global variables in multiple shared libraries and also in the main object file. The general expectation is that the linker to complain the problem - but it does not.
So only other option is to change the libraries into static library and link to the executable, if no error is thrown, relink with shared libraries.

Now let us come back to the little quiz (discussed in the beggining).
  • What is the scope of global variable (g_s) and static class variable (XYZ::s)?
    • (Previous answer)
      • Naturally, the answer would be global. 
      • For class static data member variable, the scope would be global with additional limitation of privilage (i.e all objects belonging to XYZ in the executable will have only one copy of s). 
    • (Now)
      • Global, with the scope of shared library (while building ".so") or executable. 
      • Symbol resolution is done at peer object (.o) or static library (.a).  
      • Recursive symbol resolution is not done among linked shared library to find out conflict resolution.
  • How many copies of the variable exists? 
    • (Previous answer) One 
    • (Now) One per the linkage scope (i.e shared library in this case, or executable for main object file) 
Tech Unravel
Supreme Debugging

Tuesday, October 4, 2011

[C++] Additional parenthesis are always safe! Really?


In general, a programmer would be advised to provide additional parenthesis in the code "when in doubts" with a presumption that it is safe. We will see on example here on how in certain scenarios it cannot be safe and programmer needs to be extra careful.

Consider this code (which does nothing but puts a map of class pointer index versus class pointer index)

Sample 1
1:  #include <iostream>  
2:  #include <unistd.h>  
3:  #include <map>  
4:  using namespace std;
51:  int main()  
52:  {  
53:       const unsigned int MAX_COUNT = 20000;  
54:       map <I*,J*> contextHolder;  
55:       char *p[MAX_COUNT];  
62:       map <I*,J*>::iterator itr = contextHolder.begin();  
63:       map <I*,J*>::iterator itrEnd = contextHolder.end();  
64:       while(itr != itrEnd)  
65:       {  
66:            if(someCondition)  
67:            {  
68:                 itr->first->f();  
69:                 itr->second->f();  
70:                 I* pTempI = itr->first;  
71:                 J* pTempJ = itr->second;  
72:                 delete pTempI;  
73:                 delete pTempJ;  
74:                 contextHolder.erase(itr);  
75:            }  
76:            itr++;  
77:       } 
82:       return 0;  
83:  } 

Now, let us discuss the code which is highlighted.

This would lead to well known problem - crash,
  • Line 74 deletes the contents pointing to itr - thereby invalidating the pointer.
  • Line 76 increments the invalidated pointer - thus causing the crash.
to solve this problem, developers are known to add the iteration increment during the erase operation itself. Like

Sample 2
64:       while(itr != itrEnd)  
65:       {  
66:            if(someCondition)  
67:            {  
68:                 itr->first->f();  
69:                 itr->second->f();  
70:                 I* pTempI = itr->first;  
71:                 J* pTempJ = itr->second;  
72:                 delete pTempI;  
73:                 delete pTempJ;  
74:                 contextHolder.erase(itr++);  
75:            }  
76:          else  
77:          {  
78:           //do something else.  
79:             itr++;  
80:          }  
81:       }  

The fix in line 74 (In sample 2 versus sample 1) solves the problem with an increment operator for the iterator (because increment is done before invalidating the iterator).  

Detailed Description

All is well till now. But assume that a amateur programmer, who is confused about the working of increment operation in a complex statement like that of Sample 2, line 74 adds an addition braces for the increment iterator.

Sample 3
64:       while(itr != itrEnd)  
65:       {  
66:            if(someCondition)  
67:            {  
68:                 itr->first->f();  
69:                 itr->second->f();  
70:                 I* pTempI = itr->first;  
71:                 J* pTempJ = itr->second;  
72:                 delete pTempI;  
73:                 delete pTempJ;  
74:          contextHolder.erase((itr++));  
75:            }  
76:          else  
77:          {  
78:           //do something else.  
79:             itr++;  
80:          }  

We see that the application crashes at line 74.


Now this seemingly innocent braces (highlighted in red) looks to do more harm than good. This is a classical coding problem - the iterator is extended (incremented) beyond the boundary (i.e itr.end() ) and then the map tries to erase the same element - "causing crash".

So adding this additional parenthesis lead to a disastrous bug. Moreover, hard to debug/difficult to reoccur.Any static check tool also will mostly will fail to unearth the problem.

Take Away's 

  • These kind of problems are very very difficult to catch at any cycle of SDLC phase. Even a reviewer (with immense experience) also will find difficult to catch these kind of issues.

  • It is best to share these kind of unique issues which occur in projects as technical sharing across the organisation - so that developers are sensitised (adj : having an allergy or peculiar or excessive susceptibility :)), to such potential problem in code.

  • It is best for the developer not to blindly follow "any rule", but to understand the concept behind the logic and how compiler interprets the code - in this case - the priority of execution in the complex execution statement.

Tech Unravel
Supreme Debugging

Thursday, September 1, 2011

C++ Static data member variable and its initialization

With regard to static data member initialization, as we are all aware of the syntax used in c++, a sample example is provided below

class Account 
        static double rate() { return interestRate; }
        static void rate(double); // sets a new rate
        static const int period = 30; // interest posted every 30 days
        static double interestRate;
        double daily_tbl[period]; // ok: period is constant expression

// define and initialize static class member
double Account::interestRate = initRate();

int main()
    Account ac;

Now here we see two kinds of initialization of static member variable.

a. The const data member variable is initialized at the time of declaration.
b. The non-const data member variable is initialized outside the class declaration.

My initial view was - this is strange!!!
Is it still retained in language because of legacy mistake? Or is there really a need to have such kind of differentiation?

I did ponder over this question and posted the same in a popular Q&A portal
(stackoverflow).You can find the original question with detailed reply by members here.

Let me start re-discussion the same question in a more detailed fashion.

One of the first pointer is ODR (Wikipedia One Definition Rule).
a. This states that any translation unit - a template/type/function or an object can have no more than one definition.since a definition provides the instance, it can be only one in a translation unit. However, declarations can be many.

b. The same argument extends for the exceutable. In an executable, there can be only one definition for a variable (after scope resolution) and function definitions.

This answers the second question. 

  • If non-const static member was allowed to be defined in the class itself,then it would have been impossible to include these class declaration in different translation units. 
  • Thus to avoid violation of ODR rule,the non-const static data member must be defined outside the class declaration.

Now let us come to the first part of the question (which can be explained much more easily), a const data member can be defined inside the class member for two reasons - 
  • Even if multiple copies are present in each translation unit, the expression will be evaluated during compile time and does not violate the ODR theme.
  • A const must be defined during the creation of the instance (Since it cannot be changed later), if not for the above rule, there would have been chance to change it on every object instansiation or having different definition in each translation unit.

Take Away's

Developers need not remember each language syntax and its subtle changes based on memorizing the scenarios under which error are thrown by compilers.

Instead simple interpretation and logical understanding of the constraints that forced to structure the language can be studied and thus understand the syntax by logical interpretation.

Tech Unravel,
Supreme Debugging.

Friday, August 26, 2011

Win32 Env variable Pitfall of mismatching SetEnvironmentVariable and getEnv

Problem Description

Below article will give a brief introduction on environment variables and one strange (for a Unix programmer) behavior in WIN32. 

i.e getEnv() does not retrieve some environment variable but retrieve some in WIN32. But in Unix, all environment variables are retrieved.


As quoted in wiki -

Environment variables are a set of dynamically named values that can affect the way running processes will behave. ( )

In Unix environment, it is usual to set environment variables in 2 ways -

  • Type 1 setting : Use setenv command (generally collect these command into a environment sourcing file) and call it to set all the environment variables.
A point of note : The first option is executed from the shell command and all these environment variables are inherited by the process - it is more of a statically set environment variable. The second option is a more dynamic option which can be set during the process execution.

These variables, thus set can be accessed with getEnv ( again available from stdlib.

Now, let us come to the crux of the problem.

In Unix, both the environment variables set by "Type 1" and "Type 2" can be accessed by getEnv function. When this code is ported in WIN32, it is strangely seen that statically set environment variables only will be accessible for getEnv function.

Any environment variable set using "Type2" setting (i.e dynamically set variable) using setEnvironmentVariable API ( cannot be accessed by getEnv() function.

Let us take a look at below code
Example 1
(In command line, setenv LIB="c:\\mylib;c:\\yourlib" is already done)-

1:  #include <stdlib.h>  
2:  #include <stdio.h>  
3:  int main( void )  
4:  {  
5:  char *libvar;  
6:  /* Get new value. */  
7:  libvar = getenv( "LIB" );  
8:  if( libvar != NULL )  
9:  printf( "New LIB variable is: %s\n", libvar );  
10:  return 0;  
11:  }  
In the above case, we will be able to get the output with detailed environment variable set from command line.

However, the below example has a start change in behavior 
Example 2
(In command line, LIB="c:\\mylib;c:\\yourlib" is not set from command line, but set in program)-

1:    #include <stdlib.h>  
2:    #include <stdio.h>  
3:    int main( void )  
4:    {  
5:      char *libvar;  
6:      SetEnvironmentVariable("LIB", "C:\WIN32");  
7:      /* Get new value. */  
8:      libvar = getenv( "LIB" );  
9:      if( libvar != NULL )  
10:       printf( "New LIB variable is: %s\n", libvar );  
11:     return 0;  
12:    } 
Here, the output would not be printed, owing to the fact that Type 2 setting env variables are not obtained by the getenv() API.

Root cause
The getEnv() function provides the output only from the internal cache (data structures) populated during the process start-up i.e the environment variable set in the shell. This is mentioned in the MSDN manual -
getenv operates only on the data structures accessible to the run-time library and not on the environment "segment" created for the process by the operating system
Thus in WIN32, getEnv() will not reflect the environment variable set during the execution of the program. Instead users need to use GetEnvironmentVariableA() API provided by MSDN.

Take Away's
  • Developers needs to be very discreet in using API's and also checking for differing "meanings" across different OS.
  • The manual should be read in detail and "in the corner" mentioning of the difference in behavior must be checked with a magnifying lens.
Tech Unravel.
Supreme Debugging

Friday, August 19, 2011

[Windows Programming] : Exception Generation during process creation or system command execution

Problem Description

During my windows porting activity (Existing code base in *ix - CPP programming language)
I came across a very strange problem

The project code bases uses many system command for various activity,
and one such operation is to untar (unrar in windows) the package to be launched.

Strangely the problem faced was that the unrar command used was not working as expected in XP SP3 patch.
Instead for both error and success scenario strange error code was displayed.
Below steps provides an insight with the investigation steps and the final end result.

Investigation Steps

Step 1: The initial suspect was related to compatibility of system command in Windows.
Unlike *ix, where the command is very well defined, it was hard to find out a suitable documentation for the same in

So immediately suspect was API issue (compatibility problem).

Step 2: Next the focus shifted to an well established, command execution methodology. Immediate reference came
from MSDN content -

Step 3: A sample program was derived - which used the createProcess API was used for untarring.

Sample code looked as shown below

1:  int main()  
2:  {  
3:  string ProgramName = "C:\\Program Files\\WinRAR\\WinRAR.exe";  
4:  STARTUPINFO StartupInfo;  
6:  memset(&StartupInfo, 0, sizeof(STARTUPINFO));  
7:  memset(&ProcessInfo, 0, sizeof(PROCESS_INFORMATION);  
8:  if (CreateProcess((LPCTSTR)ProgramName.c_str(),(LPCTSTR)"WinRAR.exe x -y -ibck d:\\abc.tar d:\\"),NULL,  
9:  NULL,  
10:  FALSE,  
12:  NULL,  
13:  NULL,  
14:  &StartupInfo,  
15:  &ProcessInfo) == 0)  
16:  {  
17:  string tmpStr("Error executing");  
18:  tmpStr += ProgramName;  
19:  cout<<"StmtDesigner"<<<"createprocess dword="" exitcode="0;" if="" span="" string="" tmpstr="">  
20:  }  
21:  CloseHandle(ProcessInfo.hProcess);  
22:  CloseHandle(ProcessInfo.hThread);  
23:  getch();  
24:  return 0;  
25:  }

In this case strangely,
SP2 provided expected result - i.e 0 for success and 1 (non-zero) for failure.
SP3 provided unexpected result - i.e 3221225477 for both success and failure.

Step 4:
The exit code value - 3221225477 was very critical, now when this was transformed
into HEX,it represented - C0000005 - which represents access violation in windows.
Now the investigation took a turn on what could have lead to the problem.

Step 5:
With lot of google'ing and detailed search, It was found that a good utility
called "Process Monitor" would mimic the functionality of strace in Unix.

Was downloaded and on SP3 machine and the sample program above was run with
monitor tool.

Step 6:
Process Monitor helped (with very good filtering feature) to find out that
WinRar process exited with exception.

This was noted as an event in the Process Monitor,
Further analysis of the stack during the Winrar exit event showed that the
$WINDOWS/system32/ntdll.dll interacted with one of the proprietary library present
in the same path thus the exit status was not captured correctly as ntdll.dll
was trying to access some function of proprietary library - causing access violation.

This was cross confirmed by SP2 machine - which did not have this dll file
(and program
was executed successfully).

Also after renaming/removing the proprietary library from system32 directory,
the operation succeeded even in SP3 operation (both createProcess and system command)

Take Away's

1. It is still unclear why the presence of proprietary application library in
$WINDOWS/system32 caused ntdll.dll to fail thread/process exit for WinRar application.

2. Exceptions are also thrown by the API's GetExitCodeProcess.
So it is not restricted to a range of values.

3. Placing proprietary application in the system32 location was not a good idea.
No thought on its impact was done.

4. Process Monitor is an excellent tool and is one of the must haves for the windows


5. Whenever C0000005 and other exceptions are the outcome of a program, program and
its system dependency must be thoroughly checked for all kinds of violation
(In this case an unwanted library causing some kind of interference).

6. Initial suspect on SP2/SP3 difference proved futile and invalid,
afterall looks like windows is maintaining good backward compatibility :).

Tech Unravel
Supreme Debugging