OK, feel free to email me directly when you get the time.
Thanks,
Kang Su Gatlin
Visual C++ Program Manager
File Bugs at:
http://msdn.microsoft.com/feedback
--------------------
| Reply-To: "Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com>
| From: "Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com>
| References: <eQ**************@TK2MSFTNGP12.phx.gbl>
<Tu**************@cpmsftngxa06.phx.gbl>
| Subject: Re: /OPT:REF in mixed assemblies
|
| Hi,
|
| Knew you would ask that :-)
|
| I don't have a simple repro case, just our project (which is fairly large,
| and also owned by my company). The code the problem appears to occur in
does
| not reproduce the behaviour oustide this project, and in any case I think
it
| looks more like a stack or memory corruption than a problem with any one
| section of code. We're also under a bit of a deadline at the moment, so I
| don't have a lot of time to look at this. I did try creating a small repro
| project but it didn't cause the problem. This deadline should be out of
the
| way in a couple of weeks, so I may revisit it then.
|
| Thanks,
|
| Steve
|
| "Kang Su Gatlin [MS]" <ka******@microsoft.com> wrote in message
| news:Tu**************@cpmsftngxa06.phx.gbl...
| > Steve, would you happen to have a repro that we could take a look at?
| >
| > Thanks,
| >
| > Kang Su Gatlin
| > Visual C++ Program Manager
| >
| > Enter bug reports at:
| >
http://msdn.microsoft.com/feedback
| >
| > --------------------
| > | Reply-To: "Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com>
| > | From: "Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com>
| > | Subject: /OPT:REF in mixed assemblies
| > | Date: Tue, 10 Aug 2004 18:18:14 +0100
| >
| > |
| > | Hi,
| > |
| > | Sorry for the long post, it's a bit epic (and sums up the last 10
hours
| of
| > | my life, apart from my car's gearbox melting).
| > |
| > | We've got a mixed C++ assembly that's exhibiting odd behaviour when
the
| > | /OPT:REF (remove unreferenced data) linker option is set. We first
| noticed
| > | the problem after removing the /DEBUG option (which silently alters
the
| > | defaults for the /OPT option) and assumed that was the cause for a few
| > hours
| > | until I read the documentation (ahem).
| > |
| > | Having done some more checks, it definitely appears /OPT:REF is the
| cause
| > | (eliminating COMDATs has does not cause the strange behaviour). The
| > | application crashes with an access violation that's always in the same
| > place
| > | for a particular codebase, but changing something (like changing a
| > | function's argument from taking a const reference to taking a copy)
| alters
| > | the location of the crash slightly.
| > |
| > | The only symptom we have is a boost::shared_ptr which appears not to
be
| > | valid in a piece of code that executes perfectly without /OPT:REF and
| > falls
| > | over with it. However, the debugger is behaving less than reliably in
| the
| > | area of the crash even when /OPT:REF is not set, so I'm not sure that
| the
| > | shared_ptr is damaged at all.
| > |
| > | So, to recap:
| > | /OPT:REF causes the program to exhibit the symptoms (although we've no
| way
| > | to check if this is a problem with /OPT:REF, or simply a knock on
effect
| > of
| > | this linker flag). We don't know what's causing it, and the only
| > suspicious
| > | thing we can find is what happens in the function outlined above.
| > |
| > | Has anyone had any experience with problems like this? And does anyone
| > have
| > | any clues as to where we should go? We're loath just to turn off
| /OPT:REF
| > | since I think it's going to pop up and bite us at some point. I will
| have
| > a
| > | crack at getting a repro case but I may not succeed.
| > |
| > | TIA, and again, sorry for the length of the post,
| > |
| > | Steve
| > |
| > |
| > |
| > |
| >
|
|
|
