TWinNTSystem::Run: handle uncaugth exception, terminating

I apologize in advance for the vagueness of this post. I am running with root 5.17/09 (build from sources on 14-December-07) on winXP - my application is in the form of a DLL. The main window is derived from TGMainFrame. I launch my application by loading the dll with gSystem->Load(), than instantiating the TGMainFrame derived class with new CMyClass(gClient->GetRoot(),800,700). My application crashes frequently (e.g. on the order of once per hour of use) with only “Warning in TWinNTSystem::Run: handle uncaugth exception, terminating” message as a hint. When I build the same code using root 5.06/00, it is very stable - I NEVER get this behavior. Can you suggest a strategy to debug, or at least isolate, the source of this behavior? The occurance of the exception is not reproducible. Sometimes it happens early in a session, sometimes after 10s of minutes of use. It never happens as a result of typing commands or executing scripts. It only happens when I interact with the GUI. Thanks

Ed

Ed,

To get help you will have to provide far more information, including a system reproducing the problem. Bertrand will investigate once we have completed our release at the end of next week and once he has access to a test case.

Rene

My application is quite large and it has proven very difficult to isolate the behavior as a simple application that I can send. After sprinkling printf statements all over my code (the problem has never occured while in the debugger!) I found that the “uncaugth exception” in TWinNTSystem::Run occurs during a call to TH2::Fit("poly","R") where the function poly is created with TF2 *poly = new TF2("poly",myfunc,xlo,xhi,ylo,yhi) and myfunc isDouble_t myfunc(Double_t *x,Double_t *p) { double x2 = x[0]*x[0]; double y2 = x[1]*x[1]; return p[0] + p[1]*x[0] + p[2]*x[1] + p[3]*x2 + p[4]*x[0]*x[1] + p[5]*y2; } In fact, the exception occurs within the Fit() call, but AFTER the printout showing number of function calls, parameter values and errors (all look fine) The problem is not reproducible: I can process the same input file and execute the same functions (via gui clicks) in the exact order. Most times I get no exception, but occasionally (~ 1 percent of time) I do. I NEVER had this problem when I used root 5.06/00.

Are you really doing:

TH2::Fit("poly","R");
you need an object to invoke this function.
As I said we need the strict minimum reproducing your problem.

Rene

Rene,
I call ph->Fit(“poly”,“r”) where ph is a pointer to a TH2D object.
One other points: I built the binaries from svn sources with cygwin using[quote]./configure win32
make[/quote]I have microsoft VC++.net 2003 installed on my computer. I did not use any configure flags or additional libraries
Meanwhile, I will contine to search for the minimum code to demonstrate my problem. Thanks!
Ed

OK Ed.
Bertrand will follow your problem as soon as you provide more information.

REne

I build root 5.18/00 from sources on WinXP using debug (C++.Net 2003) I never encounter the exception when my application (a DLL) is run from the debugger (this must be a clue) When I run the release code, linked against the debug root binaries I can attach to the process and break into the debugger when an exception occurs - which it has. The exception is thrown when

Int_t TH1::Fit(const char *fname ,Option_t *option ,Option_t *goption, Double_t xxmin, Double_t xxmax)

goes out of scope (line 2857 of th1.cxx) Then next entry above libHist.dll!TH1::Fit(…) is

libCore.dll!TAttFill::‘vftable’() + 0x8

Again, this is not a reproducable problem. I have not been able to isolate the problem any further. Any hints of where to look would be greatly appreciated. Thanks

Hi Ed,

I will investigate (try to reproduce the problem) tomorrow.

Cheers, Bertrand.

Hi Ed,

Could you post a working macro with all your settings (i.e. function, parameters and histogram) to be as close as possible from your specific case (just trying to save a bit of my time)… Then I will try to reproduce your problem.

Cheers, Bertrand.

Hi Bertrand,
I have not been able to produce a macro that captures the problem I have. However, I believe I have made some progress: As I’ve mentioned, when the exception is thrown, its always in a call to ph->Fit(“myfunc”,“R0”) where *ph is a TH2D and I am fitting to a TF2 created with TF2(“mfunc”,func,x1,x2,y1,y2) where Double_t func(Double_t *x,Double_t *p) is part of my application. I made the following changes: (1) I changed the fitting option from “R0” to “RN” and (2) I initialized the parameters to the TF2 before fitting (The documentation says that the parameters MUST be initialized first - I’m not sure how I was able to use this code for all these years without parameter initialization!) I have not had an unhandled exception since I made the change - several days - seems much longer than the the usual MTBF. Perhaps this information might help you? Thanks
Ed

Ed,

It is essential to set initial values for the parameters, otherwise (depending how your function is coded) you may obtain NaN or divisions by 0, etc.
The parameters initialisation is not necessary in case of basic functions “gaus”, “polN”,"expo"
On Linux systems, it is easy to see these errors by using the valgrind tool.

Rene

Rene,
Evidently it is not essential to initialize the parameters - at least it was’nt for release 5.06/0. I only got the exception on 5.17/09 and 5.18/0 and then, only occasionally. The exception was not due to NaN or divide by zero. When I used the verbose printing option, the fit converged and displayed parameters, errors, fcn minimum etc. before throwing an unhandled exception. Furthermore, when I used the debug root binaries, the exception occurred during cleanup of TH1::Fit() - that is, as it was going out of scope (line 2857 of th1.cxx for version 5.18/0).
Ed

Hi Ed,

Thanks for the info, but I’m scared it will not help much…
Anyway, one point I would like to raise is that Windows is way more sensitive to uninitialized variables than Linux. Very often, variables are just set to 0 on Linux, but may have any value on Windows, resulting on memory overwrite, or bad memory access…
I don’t clain your problem is due to this, but you have to be very careful :wink:
There are valgrind equivalent (more or less) tools on Windows (I use Rational Purify) which are very useful to trace this kind of problem.

Cheers, Bertrand.