By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,078 Members | 1,846 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,078 IT Pros & Developers. It's quick & easy.

/OPT:REF in mixed assemblies

P: n/a
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

Nov 17 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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
|
|
|
|

Nov 17 '05 #2

P: n/a
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
|
|
|
|

Nov 17 '05 #3

P: n/a
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
| > |
| > |
| > |
| > |
| >
|
|
|

Nov 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.