Somewhat opaque error popup

[Steve_Nuchia]

In a debug build I'm getting these popups for uninitialized variables. I'm working with a large legacy codebase, porting from a much older compiler and trying to clean up as I go. See the attached screencap: there are hex addresses and no routine names or line numbers.

I have to assume I'm doing something wrong and that some change will make this thing show symbolic information. When I hit OK it traps into theVisual Studiodebugger but the stack traceback is crippled too -- it quits before it gets back to my code. The popup shows a lot more stack frames than are visible to the C++ debugger.

VS2008, 32-bit buld on single-core Intel 32-bit machine, 10.1.019, mixed fortran / C++ application. Any suggestions for settings changes -- or how to trap into the Fortran debugger -- are welcome.

-swn

[Steven_L_Intel1]

Is your Fortran code built as a Debug configuration? I just tried this with 10.1.021 and it broke into the debugger at the right place. I don't think traceback works with a C++ main program, but I will ask about that.

[Steve_Nuchia]

Definitely built in a debugging configuration, though there were a number of configuration changes to meet backward compatibilty requirements. For instance, we put the string lengths at the end. And I had to turn off interface generation to get around some really scary type puns.

If it won't work with a C++ main that's a pretty serious limitation for us. We'll live of course but wow, it's pretty harsh. I'm working my way down to one now by setting breakpoints and hoping for the best. Half an hour so far and I still haven't reached fortran.

-swn

[Steven_L_Intel1]

Oh, I know. In the linker properties, turn off incremental linking. That disables traceback.

[Steve_Nuchia]

We were indeed linking some of our DLLs and the failing EXE incrementally, I think I've fixed the settings everywhere now.

No help so far, I ended up doing a clean-and-build overnight to be sure I got everything. The main and the victim are linked non-incrementally but there is a third-party DLL (a script interpreter) in between that may have been linked incrementally. Could that be responsible? It is also possible that I still have one or two of our DLLs linking incrementally.

Another thought: the IVF default setup under Visual Studio is to have the intermediate directory coincide with the output directory. We've got them in different places; is it reasonable to suspect that the runtime traceback code is failing to locate the symbols? I guess I can use procmon to test that hypothesis.

No help so far, at least for the popup. I did get what looks like a fairly reasonable stack window in the Microsoft debugger after dismissing the popup but then it froze and I'm having to restart the environment. We're working right at the hairy edge of what the IDE will handle in terms of code volume.

If it doesn't get any better I'll follow up with a cut-down example, if I can find one.

Thank you!

[Steven_L_Intel1]

I did a test with a C++ main and Fortran library and turning off incremental linking allowed the traceback to work. Yes, it's possible if you changed the output folders it might cause a problem, I don't know for sure.

What specifically is the problem with the popup? This is the error message and it names the routine and variable (in the name the form is routine$variable)

A test case would be useful.

[Steve_Nuchia]

Once I managed to track down the offending line of code I realized that the routine name and variable name were in fact encoded in the popup. I was thrown off by the large stack trace full of question marks and the fact that I'm not intimate enough with the code to have twigged to the encoding on first (or seconde, or third) encountering it. And knowing the variable name is seldom helpful when navigating a maze of twisty source files, all alike.

I'm handing out bugs in the ported application as I encounter them and that popup, in combination with the fact that we can't get a stack trace out of the Visual Studio debugger either, means I'm having to pick a developer more or less blind and hand them a puzzle. Serves 'em right if I pick the right guy, they shouldn't be writing buggy code in the first place. :-) But I'm getting nasty looks in the hallways.

A stack trace is often important in figuring out how the code path leading to an uninitialized use is entered and where exactly it should be fixed:

If (case1) var = a

If(case2) var = b

C that ought to be all the cases

if (var.eq.b) foobar(baz,bat)

That's a simplification of the code situation in the case reported in the screencap, except there are no comments and the conditional initialization is a lot more tortured. Keeping in mind this is legacy code, understanding how we managed to slide through the decision tree without initializing the variable is important and more context than 'ROUTINE$VARIABLE'would be very nice to have. Like maybe line number? The offending code was in one of half a dozen copy-paste-and-modify blocks selected bya computed GOTO. Which one is broken?

On a different level, there's a peception-of-quality and a trust issue here. We're new to the Intel tools and everything that is different (from Digital VF 6) is "bad". I'm the guy with the arrows in his back on this one so I'm looking for a way to improve the perceived authority of the popup and the overall debugging experience.

Also, we have automatic crash dump capture for our products. We may not always be able to repeat a failue over and over again in the debugger to get the information we need; the traceback needs to work the first time. We can manually decode the hex addresses if necessary but I'm sure you can appreciate that I'd rather not.

On the good news side, when I single-stepped into the offending code the experience was clean: right source lines showing on the screen, breakpoints worked, local variables displayed, stack trace window fully functional. It's only on exceptions that the world is broken.

[Steven_L_Intel1]

As I said, in my tests I got a file name and line number in the traceback and the debugger break went to the right place. I'd be interested in seeing a test case where it does not.

The uninitialized variable popup is generally correct, when it appears. CVF did compile-time only uninitialized variable detection, IVF does it only at run-time (as an option).

Yes, I'm familiar with "different=bad". Have you seen my white paper on porting from CVF?

[Steve_Nuchia]

Since we're skipping right over the Compaq era there is a lot in the porting guide we can't directly use; I didn't spend much time with it initially but I'll read it again now that the vocabulary means something to me.

Something in our build process or environment is breaking the runtime's traceback, I'll work on debugging it here and let you know what I find, probably next week.