stuck with what looks like a compiler bug in VS.NET 2003 vs VS.NET 2002

This is going to be a little vague I'm afraid as it's hard for me to provide
explicit details without a vast quantity of extra information.

I've recently changed compiler from .NET 2002 to .NET 2003. I have a fairly
complicated application, which is an ISAPI extension that relies on several
other rather large projects (Xalan, Xerces, ICU, boost). At some point, i'm
at the bottom of a pretty deep call stack, and I throw an exception which
travels up a lot of it.

It seems that in one particular module, a couple of the functions don't
manage to unwind the call stack properly -- it always crashes in either of
these two functions during the unwind sequence. It's 100% reproducible with
.NET 2003 and 100% not reproducible with .NET 2002, and depending on how
I've been tinkering with the code, always crashes in the same place. I've
tried sprinkling some extra try () { } catch (...) { throw; } blocks around
various parts of these functions. The result is that I can make the problem
go away, presumably by generating different unwind code. Oh, and this only
happens with a release build.

Normally I'd claim responsibility for mashing memory rather than pointing at
the compiler, but in the case, the application (and those things that it
relies on) have been proved to be very stable. I can also make this happen
with a wide variety of initial conditions (effectively doing things that
would drastically change the pattern of memory allocations up to that
point), pageheap /full doesn't spot anything, and if I _don't_ throw the
exception, then things all work as expected, even to the point of being able
to conduct stress tests that previously passed.

I realise that this is a bit of a long shot, but if anyone could offer any
advice on what to try or look for to be certain as to what is going on that
would be great. The application is open source, so if anyone has a great
deal of spare time then it should be possible to recreate it locally.

I'm out of ideas other than reading the compiler generated assembly at the
moment (which isn't an easy task as my asm is a bit rusty these days). If
it comes to it, I guess I'll have to drop back a compiler version, which
would be a pity.

Thanks,

Mark

Mark
Thu Apr 22 06:01:43 CDT 2004

> It seems that in one particular module, a couple of the functions don't
> manage to unwind the call stack properly -- it always crashes in either of
> these two functions during the unwind sequence. It's 100% reproducible
with
> .NET 2003 and 100% not reproducible with .NET 2002, and depending on how
> I've been tinkering with the code, always crashes in the same place. I've
> tried sprinkling some extra try () { } catch (...) { throw; } blocks
around
> various parts of these functions. The result is that I can make the
problem
> go away, presumably by generating different unwind code. Oh, and this
only
> happens with a release build.
>
One more interesting piece of information I've observed, is just for that
module, if I turn off PCH then it works. The /FAcs listing is very much
different between the two (1Mb smaller in the PCH case) -- is this expected
behaviour?

Also:

With PCH:
/Ox works
/O2 does not
/Od, /O1 incompatible with PCH

Without PCH:
/Od - works
/O1 - works
/O2 - works
/Ox - works

Thanks,

Mark

David
Thu Apr 22 07:53:19 CDT 2004

>One more interesting piece of information I've observed, is just for that
>module, if I turn off PCH then it works. The /FAcs listing is very much
>different between the two (1Mb smaller in the PCH case) -- is this expected
>behaviour?

Mark,

Never having had to look into such an issue, it does seem odd to me
that there would be any difference. Are you somehow picking up
different headers when you use/don't use precompiled headers?

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

Mark
Thu Apr 22 08:10:00 CDT 2004


"David Lowndes" <davidl@example.invalid> wrote in message
news:8off80dggv98m2c44hqvbgp56pjbs0rcgb@4ax.com...
> >One more interesting piece of information I've observed, is just for that
> >module, if I turn off PCH then it works. The /FAcs listing is very much
> >different between the two (1Mb smaller in the PCH case) -- is this
expected
> >behaviour?
>
> Mark,
>
> Never having had to look into such an issue, it does seem odd to me
> that there would be any difference. Are you somehow picking up
> different headers when you use/don't use precompiled headers?
>
I'm pretty much certain that this is not the case. There is only one set of
header files, and without them it wouldn't compile. Plus it's just doing a
#include "stdafx.h" at the top, and both the stdafx.h used by the project
and the source file itself exist in the same directory.

To be sure, I added a #error "go away" line to the stdafx.h and compiled
just that file, and it is picked up by the compiler as expected.

Mark

Carl
Thu Apr 22 08:38:10 CDT 2004

Mark Weaver wrote:
>> It seems that in one particular module, a couple of the functions
>> don't manage to unwind the call stack properly -- it always crashes
>> in either of these two functions during the unwind sequence. It's
>> 100% reproducible with .NET 2003 and 100% not reproducible with .NET
>> 2002, and depending on how I've been tinkering with the code, always
>> crashes in the same place. I've tried sprinkling some extra try ()
>> { } catch (...) { throw; } blocks around various parts of these
>> functions. The result is that I can make the problem go away,
>> presumably by generating different unwind code. Oh, and this only
>> happens with a release build.
>>
> One more interesting piece of information I've observed, is just for
> that module, if I turn off PCH then it works. The /FAcs listing is
> very much different between the two (1Mb smaller in the PCH case) --
> is this expected behaviour?
>
> Also:
>
> With PCH:
> /Ox works
> /O2 does not
> /Od, /O1 incompatible with PCH
>
> Without PCH:
> /Od - works
> /O1 - works
> /O2 - works
> /Ox - works

It does sound like there's likely a codegen bug at the root of your
problems. Given the above, my recommendation would be to compile with /O1
instead of /O2. It's not uncommon for /O1 builds to actually be faster than
/O2 builds anyway.

You might also get in touch with product support - it's possible there's a
QFE/hotfix for the bug you're running into.

-cd

Alexander
Thu Apr 22 09:31:06 CDT 2004

See if there are differences in compiler options for stdafx.cpp and the
problematic file. You can easily check it in the project text file.

"Mark Weaver" <mark@npsl.co.uk> wrote in message
news:usia1kFKEHA.620@tk2msftngp13.phx.gbl...
> > It seems that in one particular module, a couple of the functions don't
> > manage to unwind the call stack properly -- it always crashes in either
of
> > these two functions during the unwind sequence. It's 100% reproducible
> with
> > .NET 2003 and 100% not reproducible with .NET 2002, and depending on how
> > I've been tinkering with the code, always crashes in the same place.
I've
> > tried sprinkling some extra try () { } catch (...) { throw; } blocks
> around
> > various parts of these functions. The result is that I can make the
> problem
> > go away, presumably by generating different unwind code. Oh, and this
> only
> > happens with a release build.
> >
> One more interesting piece of information I've observed, is just for that
> module, if I turn off PCH then it works. The /FAcs listing is very much
> different between the two (1Mb smaller in the PCH case) -- is this
expected
> behaviour?
>
> Also:
>
> With PCH:
> /Ox works
> /O2 does not
> /Od, /O1 incompatible with PCH
>
> Without PCH:
> /Od - works
> /O1 - works
> /O2 - works
> /Ox - works
>
> Thanks,
>
> Mark
>
>

Mark
Fri Apr 23 01:06:40 CDT 2004


"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:Oa1w0ZHKEHA.3380@TK2MSFTNGP09.phx.gbl...
> See if there are differences in compiler options for stdafx.cpp and the
> problematic file. You can easily check it in the project text file.
>
Ah that makes sense of that (there are), thanks.

Mark
Fri Apr 23 01:21:49 CDT 2004

>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:Oa1w0ZHKEHA.3380@TK2MSFTNGP09.phx.gbl...
> > See if there are differences in compiler options for stdafx.cpp and the
> > problematic file. You can easily check it in the project text file.
> >
> Ah that makes sense of that (there are), thanks.
>
No, scratch that -- there weren't. All I did was turn off PCH (I went and
checked properly this time). That's what you get for not getting out of bed
and having tea first!

Sorry!

Mark
Fri Apr 23 01:23:17 CDT 2004

> It does sound like there's likely a codegen bug at the root of your
> problems. Given the above, my recommendation would be to compile with /O1
> instead of /O2. It's not uncommon for /O1 builds to actually be faster
than
> /O2 builds anyway.
>
Thanks, it seems ok with /O1 so far on just that module (I left it running a
previous set of stress scripts overnight and it's still going ok this
morning).

> You might also get in touch with product support - it's possible there's a
> QFE/hotfix for the bug you're running into.
>
Will do.

Thanks for the help,

Mark