Crash of compiled library on Windows Vista

ROOT
1

Dear ROOTers,

On my Mac I have installed both Windows XP and Vista, and on both Windows systems I have installed
"Visual Studio Express 2008" and the binary version of ROOT for Windows compiled with VC++ 9.

My MakeFile.win to compile my library contains for example the following line:

TStat.obj: TStat.h TStat.cxx
	$(CL) /I"$(ROOTSYS)/include" /FIw32pragma.h /MT /EHsc /Ox /D "MSVC" /D "WIN32" /c TStat.cxx

On WinXP the code compiles w/o problem and it does not matter if I use /MD or /MT. Moreover, the
compiled library runs w/o problem in both cases.

On Windows Vista the code compiles also w/o problem in both cases, /MD or /MT. However, in contrast
to WinXP the library runs only when compiled with /MD, but crashes root immediately when compiled with /MT.

Does anybody know why the library runs w/o problem on WinXP but crashes on Vista when compiled with /MT?

Is there any possibility to change the MakeFile so that the library can be compiled using /MT?

My problem is that I must compile the library with /MT.

Best regards
Christian

2

Hi Christian,

There is no problem using /MT flag on a native Vista (x64) and MSVC++9.0 (not express edition) with a random test application.
The problem could come from the Windows SDK (just trying to guess). I use 6.0A: c:\Users\bellenot\rootdev\test>echo %WindowsSdkDir% C:\Program Files\Microsoft SDKs\Windows\v6.0A\
:exclamation: But note that on Windows, mixing compilation flags is generally not a good idea.

Cheers, Bertrand.

3

Dear Bertrand

Thank you for the reply.
Although “echo %WindowsSdkDir%” returns in my case “%WindowsSdkDir%” I have the same version v6.0A.

I have just tried to compile my library again on Vista with /MT and I get a Dialogbox telling me that
"ROOT application root does no longer function" with the following details:

Problemsignatur:
  Problemereignisname:	APPCRASH
  Anwendungsname:	root.exe
  Anwendungsversion:	5.24.0.1
  Anwendungszeitstempel:	4a4ba240
  Fehlermodulname:	ntdll.dll
  Fehlermodulversion:	6.0.6001.18000
  Fehlermodulzeitstempel:	4791a7a6
  Ausnahmecode:	c0000005
  Ausnahmeoffset:	00065a20
  Betriebsystemversion:	6.0.6001.2.1.0.768.3
  Gebietsschema-ID:	1031
  Zusatzinformation 1:	c607
  Zusatzinformation 2:	059d3c816ce723def79e99fd55488b09
  Zusatzinformation 3:	d16c
  Zusatzinformation 4:	992db5b7d0e2a3bf97fabae4c6cf657a

Do you have any idea what this means?

P.S.: This is not a problem specific to my setup, since the same problem exists on the Bioconductor server.

Best regards
Christian

4

Hi Christian,

Nope, but as I said before, on Windows, you should first try to use the same compiler flags for your application than the ones used by ROOT, especially if you use STL (and please don’t complain to us about this :wink:)

Cheers, Bertrand.

5

Dear Bertrand

To understand my problem with options “/MT” and “/MD” please have a look at:
stat.ethz.ch/pipermail/r-devel/ … 54843.html
where I just explained the problem in detail, since I am afraid that it is mainly an “R” problem.

Best regards
Christian

6

Hi Christian,

You can still try to build Root from source with the /MT option (note I never tried…) to be compatible with R
And note also I’m not aware of a different behavior between XP and Vista concerning these compiler flags… (they should behave the same)

Cheers, Bertrand.

7

Dear Bertrand,

I will try but I need to install cygwin first.

Since you mention tat you are not aware of a different behavior between XP and Vista,
could I ask you to do me a favor and try my source code. It should not take too much
time since there is no need to install anything. You can download the source code from:
bioconductor.org/packages/2. … .16.tar.gz
(see also: bioconductor.org/packages/2. … l/xps.html)

For the following I assume that you unzip the source in directory “C:\home\Bertrand”.
From the Console of your Vista machine compile the source with option /MD:

cd "C:\home\Bertrand\xps\src"
NMAKE /f "Makefile.winVC9MD" CFG="Release"

To test if the compiled code works I include the file “macroTest4XPS.C”.
Please replace in the macro everywhere “C:/home/Rabbitus/CRAN” with “C:/home/Bertrand”.
Then you can start root and run the test as follows:

.L macroTest4XPS.C 
Init("C:/home/Bertrand/xps/src/xps.dll") 
ImportDataTest3("tmp_DataTest3", "C:/home/Bertrand")
ExportDataset("C:/home/Bertrand/xps/inst/schemes/SchemeTest3.root","C:/home/Bertrand/tmp_DataTest3_cel.root","DataSet/*.cel","*","C:/home/Bertrand/DataTest3_cel.txt")

This test works for me on both WinXP and Vista.

Now please delete the compiled files from “C:\home\Bertrand\xps\src” and compile with /MT:

cd "C:\home\Bertrand\xps\src"
NMAKE /f "Makefile.winVC9" CFG="Release"

If you start then root and run the above test again you will probably see that root
crashes on Vista displaying the corresponding Dialogbox that “ROOT application root
does no longer function”.

Can you please tell me if you get the crash, too, or if the test works on your machine?
If you get also the crash, do you have any idea what might be the reason?

Thank you in advance for your help.
Best regards
Christian
macroTest4XPS.C (3.65 KB)

8

Hi Christian,

Sorry for the late reply, I’m on vacation and didn’t have online connection… I’ll try as soon as I’m back at work (mid October)

Cheers, Bertrand.

9

Dear Bertrand,

Thank you, I am looking forward to your test results. Until then I wish you a nice vacation.

Best regards
Christian

10

Hi Christian,

OK, it crashes only on Vista. No idea why it works on XP and not on Vista. But anyway, as Microsoft says:

[quote]Caution Do not mix static and dynamic versions of the run-time libraries. Having more than one copy of the run-time libraries in a process can cause problems, because static data in one copy is not shared with the other copy. The linker prevents you from linking with both static and dynamic versions within one .exe file, but you can still end up with two (or more) copies of the run-time libraries. For example, a dynamic-link library linked with the static (non-DLL) versions of the run-time libraries can cause problems when used with an .exe file that was linked with the dynamic (DLL) version of the run-time libraries. (You should also avoid mixing the debug and non-debug versions of the libraries in one process.)
[/quote]
So solving this problem will require much more work than just changing one compiler flag…

Cheers, Bertrand.

11

Dear Bertrand,

I must admit that I cannot say that I am glad that you could confirm my problem.
My problem is not Vista, which luckily almost none of my users used, but the upcoming Windows 7 since many
users may switch to Windows 7 and I am afraid that the problem may be the same. I am not even sure if my
program may work in the WinXP compatibility modus of Windows 7, and this will be a huge problem.

At the moment the only solution that I can think of is trying to compile root with option /MT. However,
I would be very happy if you could propose another solution.

Best regads
Christian

12

Christian,

The solution is well known: use the same compiler flags.
As I told you, I’ll investigate and let you know.

Cheers, Bertrand.

13

It is not enough to use the same compilation flags; you actually need the SAME system DLLs too. I.e. you need the same version of the MS VC DLL (the same issue with g++. Fortunately, by now under Linux this requirement was not as harsh as under Windows )
This is why so-called “manifest” was introduced.
see: en.wikipedia.org/wiki/Features_n … assemblies
msdn.microsoft.com/en-us/library/aa376307(VS.85.aspx
support.microsoft.com/kb/835322
Just google for “side-by-side” to get the further information.

14

As far as I know the ROOT build script applies the “built-in” type of the “manifest”. I.e. it is the “private” assembly. See msdn.microsoft.com/en-us/library/aa375365(VS.85.aspx )
(Bertrand may want to correct me ). That means the version of the system DLL’s are hardcoded and bured inside of the ROOT executable and it can not be changed / adjusted easily.

15

Hi Valeri,

your statement gives the impression that this is a limitation, and it’s not. The manifest is integrated into the binaries. Given a binary file it cannot be changed, that’s correct. But given a binary file you also cannot change the compiler flag! So there is no limitation here; it’s just improved usability because the information is embedded instead of side-by-side.

Cheers, Axel.

16

[quote=“Axel”]… your statement gives the impression that this is a limitation, and it’s not. The manifest is integrated into the binaries. Given a binary file it cannot be changed, that’s correct. …
Cheers, Axel.[/quote]Well, talking about MS “manifest” murky issue can takes years. Let’s discuss the user’s issue. I think one can help him by answering the questions:

  • Are you agree that the using the same compilation flags is required but it is not sufficient?
  • Do you embed (supply) the system DLLs that “integrated into the binaries manifest” requires to use?
  • How one can check the version of the VC run-time DLLs those ROOT was built against of?
  • How can user make sure that ROOT and another SDK are linked against of one and same VERSION of the run-time DLLs?
17

Dear Valeri,

Thank you for your comments, however I must admit that I am confused.
Do you mean that it is not possible to compile root with option /MT?

Best regads
Christian

18

[quote=“cstrato”]…Thank you for your comments, however I must admit that I am confused.
Do you mean that it is not possible to compile root with option /MT?
[/quote]No, I did not say that.
However, I had to go back and re-read your initial message to understand what you do and why. Frankly, I am confused.
Please, correct me:[ul] - You use the ROOT binary from CERN (or do yourself) compiled with /MD flag. That means the run-time library is to be loaded at run-time from the VC DLL.

  • You compile your own class with /MT flag. That means that a copy of run-time library is to be statically INCLUDED into your TStat DLL [/ul]What do you do NEXT? Does your MakeFile.win create a separate DLL and you want this DLL (with the built-in copy of run-time library inside) to be dynamically loaded into the ROOT session?

Can you say where the original requirement to use /MT option comes from?
(For me, the "/MT” requirement sounds like your R-system accepts the “simplest single self-contained” DLL extensions only.)

19

Dear Valeri,

Yes, I use the ROOT binary from CERN (or compile it myself) with /MD flag.
Yes, I compile my own classes with /MT flag.
Yes, my Makefile.win creates a separate library “xps.dll”.
Then I load my library in a ROOT session with gSystem->Load(“xps.dll”). This work w/o problems on WinXP but crashes ROOT immediately on Vista!

The requirement for /MT arises since R cannot find library libCore.dll when I compile my library with /MD.
The Vista dialogbox displays a message with Errormodulename: libCore.dll_unloaded
For a detailed description please see: stat.ethz.ch/pipermail/r-devel/ … 54843.html

Best regads
Christian

20

[quote=“cstrato”]Yes, I use the ROOT binary from CERN (or compile it myself) with /MD flag.
Yes, I compile my own classes with /MT flag.[/quote]Ok, we are coming back to the very first advice made by Bertrand. The reason of your trouble is not “MT” flag alone rather the application assembled with the DLLs linked against of “/MD” and “/MT” libraries simultaneously. This is a ticking bomb.

[quote=“cstrato”]Yes, my Makefile.win creates a separate library “xps.dll”.
Then I load my library in a ROOT session with gSystem->Load(“xps.dll”). This work w/o problems on WinXP but crashes ROOT immediately on Vista!
[/quote]You did use the different compilation options for ROOT DLLs and your custom DLL. This means that your application works propely on XP just by “chance”

What does "R cannot find library libCore.dll " :open_mouth: stands for ?. Is that /MT requirement written somewhere or it is just your invention, the combination you found eventually?

[quote=“cstrato”]For a detailed description please see: stat.ethz.ch/pipermail/r-devel/ … 54843.html[/quote]Yes, I did see that too.
However, that does not explain me the interface between “R” and ROOT.

If “R&ROOT” is one application then all components of such combined application have to be compiled and linked against of one and the same run-time DLL.
Otherwise you are going to get the multiply copies (and probably the several different non-compatible implementations) of one and the subroutines. That may or may not crash your application. The outcome is defined by luck. You were very lucky with XP.
It is neither “ROOT” nor “R” nor “Vista” issue. It is the issue of your way to build the “R&ROOT” application. As you described, the different parts are non-consistent. I am very sorry, but it is you who should find the way to fix it.
For example, I doubt my experiment, STAR, may have appreciated any effort to play with “R” installation / customization on Windows right now.