Standalone app access violation (gClient related I think)

I’m trying to get up and running a basic standalone gui application using ROOT. Yesterday I had this running but today it is giving me fits. I don’t remember exactly what I’ve changed since then but I’ve stripped it down to a pretty basic app that still isn’t working.

#include "TApplication.h"
#include "TGClient.h"

int main(int argc, char **argv)
	TApplication baseApp("RootTest", &argc, argv);
	return 0;

Stepping through with the debugger I get 'Access violation reading location 0x00000040"on the
gClient->GetRoot() line. What am I doing wrong?

Windows XP
Visual Studio 2010
Production version 5.34 of ROOT downloaded from that prebuilt tarball (I’ve also tried using my own compiled version but have the same problem)
I’m linking against $ROOTSYS/lib/*.lib


A couple of simple rules:
[ul][li]compile your application with the exact same version of Visual C++ and same configuration (debug vs release) than ROOT itself[/li]
[li]If you plan to have your application running at some point, you should add baseApp.Run(); (otherwise the events will not be processed)[/li][/ul]
And I just tested to compile and run your code with this command:

cl -nologo -Z7 -MDd -GR -EHsc test.cxx -I %ROOTSYS%\include /link -LIBPATH:%ROOTSYS%\lib libCore.lib libGui.libWithout any problem (with the HEAD of ROOT v5-34-00-patches).

Cheers, Bertrand.

I didn’t really expect that the code is the problem. I assume it’s an environment thing somewhere but I don’t know where to go looking for it. Compiling with the command exactly as you have it still produces the same runtime error that I had before. My custom built version of ROOT was done on the exact same compiler setup but linking against those libraries still produces the same error :frowning:

OK. Then you should make sure that the ROOTSYS environment variable is properly set and %ROOTSYS%\bin is in your %PATH% (you can set that in your user environment variables, or execute root\bin\thisroot.bat)

Still no luck.

I have ROOTSYS set to C:\ROOT\install

and PATH is set to C:\ROOT\install\bin;…

I did restart visual studio to (hopefully) make sure it reloaded the environment variables but no change.

Are you able to use the debugger to see why gClient doesn’t get initialized in TApplication-constructor and if not, does setting gDebug to higher level reveal anything?

Since it’s loaded from a dll I’m not sure how to query it very well in Visual Studio. Doing cout, I do know that it is pointing to 0x0, which I would guess at given the error.

What is gDebug?

gDebug is the global variable to print ROOT debug messages. And to debug from visual studio, you can add a breakpoint on this line: TApplication baseApp("RootTest", &argc, argv);And “step into” from the debugger. Visual Studio is the easiest debugger out there…

(posted before seeing bellenot’s reply)
gDebug can be used to change what debug messages ROOT prints out, e.g. writing
gDebug = 3;
at very beginning of main will cause more debug messages to be generated in TApplication constructor (not sure whether that will help, though).

Debugging into ROOT’s DLL’s should work fine if there are ROOT’s PDB-files available: you can simply try that by trying to step into TApplication constructor. For me the call stack that sets gClient-pointer looks like:

Trying to step into the TApplication constructor isn’t working for me because I’m linking against dlls which apparently don’t have debug information (which is a separate issue, I built those in debug mode. Do I need to do something more?)

Setting gDebug=3 I get the following output, which seems like something

Info in TPluginManager::FindHandler: did not find plugin for class TVirtualPad
Info in TPluginManager::FindHandler: did not find plugin for class TVirtualX and uri win32gdk
Info in TPluginManager::FindHandler: did not find plugin for class TGuiFactory and uri root

OK. hold on a minute. I was trying to figure out the issue with not being able to debug into the dlls and apparently it was grabbing the dlls from somewhere other than what I expected. I THINK I have the location fixed and it is no longer crashing on me. I’ll play around some more to confirm and then mark as solved.

Thanks for all your help!

The DLL location thing is indeed worth noting to prevent debug builds from loading release DLL’s or vice versa.