Running test/stress using ROOT 5.14 on Windows

ROOT
1

Hi,

We are in the process of testing out ROOT 5.14 before we upgrade.

I compiled and tried to run the stress application with 30 events on Windows XP both using the compiled executable (using VC++ 7.1) and through CINT and I find that the 8th test (trees split and compression modes) fails some assert statement. Attached is a copy of the Windows pop up that appears.

Is this something to be concerned about?

Thanks,
Heather

2

Heather,

I cannot reproduce this problem on Windows with VC7.1.
I run both compiled and interpreted cases.

Is it the only test failing? Can you run all the other stressXXX programs?

Rene

3

Can you show us your ROOTSYS and PATH env variables values?

4

It actually is not the only test failing. stressGraphics and stressLinear also fail for me.

First my ROOTSYS and PATH env variables are:
C:>echo %ROOTSYS%
C:\heather\glast\extlib\ROOT\v5.14.00\root

C:>echo %PATH%
C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program Files\Support Tools;c:\Program Files\Microsoft SQLServer\90\Tools\binn;C:\Program Files\cvsnt;C:\Program Files\QuickTime\QTSystem;C:\ProgramFiles\cvsnt;C:\heather\Home\SSH;C:
\heather\glast\extlib\ROOT\v5.14.00\root\bin;C:\heather\glast\extlib\ROOT\v5.14.
00\root\lib;C:\heather\glast\tools\ruby\bin;C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE;C:\heather\bin

I had another member of our collaboration install ROOT on another windows machine - and I find the same failure on that windows machine as well.

Some things to note, I’ve installed ROOT using the binary tar.gz (recommended) version of ROOT 5.14.00 from the ROOT download web page. When I start up ROOT, the splash screen reports that the version is 5.13.07, though the command line for CINT, does state the version is 5.14.00.

The stackTrace for my failure when running stress is as follows:
Test 8 : Trees split and compression modes…

=============== STACKTRACE ===============

================ Thread 0 ================
MSVCR71D!operator delete
c:\heather\glast\extlib\root\v5.14.00\root\test\event.cxx(344): Track::Clear()

libCore!TClonesArray::Clear()
c:\heather\glast\extlib\root\v5.14.00\root\test\event.cxx(120): Event::~Event()
libEvent!Event::`vector deleting destructor’()
c:\heather\glast\extlib\root\v5.14.00\root\test\stress.cxx(731): stress8read()

c:\heather\glast\extlib\root\v5.14.00\root\test\stress.cxx(797): stress8()
c:\heather\glast\extlib\root\v5.14.00\root\test\stress.cxx(172): stress()
c:\heather\glast\extlib\root\v5.14.00\root\test\stress.cxx(130): main()
f:\vs70builds\3077\vc\crtbld\crt\src\crtexe.c(398): mainCRTStartup()
kernel32!RegisterWaitForInputIdle()

================ Thread 1 ================
ntdll!KiFastSystemCallRet()
kernel32!WaitForSingleObject()
libCore!`anonymous namespace’::HandleConsoleThread()
0xffffffffe87c8024 ??

================ Thread 2 ================
ntdll!KiFastSystemCallRet()
kernel32!Sleep()
libCore!TWinNTSystem::TimerThread()

================ Thread 3 ================
ntdll!KiFastSystemCallRet()
libWin32gdk!TGWin32RefreshTimer::~TGWin32RefreshTimer()

==========================================
============= END STACKTRACE =============

Upon looking at Event.cxx, I see the failure occurs at line 344:
delete [] fPointValue;
for fun, I put in a check to see that fPointValue was non-null - that didn’t prevent the failure, but commenting out the delete statement altogether did help it get further…I then commented out two other lines:
delete [] fClosestDistance;
delete [] fEventName;
merely checking that these variables were non-null was not enough…but completely eliminating the deletions did allow the stress routine to complete with no trouble.

So I’m still a bit bothered by this…

5

Hi,

we might understand what’s happening - and it depends on how you build stress. Root was built with /MD, requesting the release version of the runtime libraries. You must make sure to build the stress binaries in release mode, too, or they will pull in the debug version of delete which does not match the release version of new. It seems like you built stress with the debug version of the release libraries - otherwise there would be no assert. The two options to build the tests in release more are a simple “make” on cygwin and on a win shell (cmd.exe) NMAKE /f "Makefile.win32" CFG="Release"
Cheers, Axel.

1 Like
6

Hi,

Yes - recompiling with CFG=“Release” allowed the stress executable to complete without problems using the original copy of Event.cxx.

Thanks!
Heather