Re: NTDLL exception
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Thu, 16 Jun 2005 11:58:37 -0400
That's bad advice. Compiling with the multithreaded release library in a debug version
means that you will get two problems: one, that you will now try to link with two
different libraries, which can produce linker conflicts of various sorts, and should you
succeed, you will be running with two different libraries, each of which thinks it owns
the heap and other state variables. I can't imagine how compiling a piece of debug code
with a release library benefits anyone.
I am prone to migraines; I've had them, officially, since I was 12, and probably for years
before that. And the use of the debug libraries in debug builds has never once triggered a
migraine in me.
Microsoft would like to deep-six the single-threaded libraries, so you should forget that
they exist.
What I find odd is that there seems to be an idea that using debug versions of static
libraries poses any problem whatsoever. I've been using MFC for a decade, and I've never
yet had a problem with this. I just, guess what, build debug versions of the static
libraries I'm using. Since they build into a debug directory, I just use the debug
directories in the debug build and the release directories in the release build. Perhaps
I'm missing somehting subtle here, but I doubt it.
One of the errors comes from trying to emulate the C/MFC approach of having a library with
a name suffixed by a "d" in some way. This is only done because the normal libraries live
in the same Windows\System32 directory and the same .lib directory. For your own use,
build them to separate directories but keep the same name.
There's a lot more you lose than stack checks. You lose assertion reports, uninitialized
local variable use reports, if they are MFC, the correct calls on DEBUG_NEW, and the like.
Overall, I would be more prone to migraines by trying to debug a bizarre mixed hybrid than
by simply taking the easy path of using the correct mix of libraries.
joe
On Thu, 16 Jun 2005 02:30:18 -0400, "Steve Russell" <srussell@xxxxxxxxxxxxxxxxxxxxxx>
wrote:
>Could I get a comment on the following advice I received? :
>
>"A general tip: compile all static libraries and all applications, both when
>in debug and release, as "Multithreaded Release". This will disable runtime
>stack checks that the "Debug" libraries give you, but they're not worth
>the migraines; you can get a small performance increase by using the
>"Single-
>threaded" libraries, but most nontrivial applications end up using threads
>(directly or indirectly) eventually, and the gain is, again, not worth
>the migraines of using other runtimes.
>
>"If you really want to use a debug CRT for debug builds, you'll have to
>compile
>a debug version of every static library you use with that same CRT--I used
>to have eg. "ogg_d.lib", "zlib_d.lib", but that mess goes away if you get
>rid of debug CRTs (or, alternatively, use dynamic libraries)."
>
>"Steve Russell" <srussell@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
>news:uzNyqfjcFHA.220@xxxxxxxxxxxxxxxxxxxxxxx
>> No, I can't get any more info from the debug windows. However, tonight I
>> went to a release build and got a defaultlib "library" conflicts with use
>> of other libs; use /NODEFAULTLIB:library" warning. In Project Settings -
>> Object/Library modules, I have specified "vorbis/vorbisfile.lib
>> speex/libspeex/libspeex.lib." So I commented out all of my Speex code
>> (not yet implemented), and now -- in my Release version only -- ov_open is
>> succeeding.
>>
>> "Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
>> news:qfe0b1d59s44j9679s09jhdkraaspiijkj@xxxxxxxxxx
>>> Usually you also get a pointer to the instruction, and you can inspect
>>> the registers to
>>> see what the instruction was doing. Most commonly, you end up with
>>> something that is
>>> either 0, or a small offset from 0, indicating a reference being done
>>> relative to a NULL
>>> pointer. Since I see that one of the parameters you are passing in is
>>> NULL, but have no
>>> idea what it means, it suggests that the library you are calling is
>>> trying to pass that
>>> value in to something else, which then crashes. Double-clicking the
>>> MSVCRT line in the
>>> backtrace might allow you to browse around and see what runtime library
>>> routine was called
>>> in the C runtime (you do need to have the correct symbols installed to
>>> make this work).
>>> Given you have open source, you should be able to double-click the caller
>>> to MSVCRT and
>>> inspect the code to see what the call was, and from that you should have
>>> a lot of
>>> information to go on.
>>> joe
>>>
>>> On Wed, 15 Jun 2005 00:14:03 -0400, "Steve Russell"
>>> <srussell@xxxxxxxxxxxxxxxxxxxxxx>
>>> wrote:
>>>
>>>>Thanks for your comments, Joe. I passed on everything there is, as far
>>>>as
>>>>debugger info. All the trouble is happening inside the function ov_open.
>>>>It's a mystery to me.
>>>>
>>>>"Unhandled exception in Room 101.exe (NTDLL.DLL): 0xC0000005: Access
>>>>Violation."
>>>>
>>>>I know from googling that I am not the first to wrestle with something
>>>>like
>>>>this in regard to ov_open. I'll see what Chris P. in the Multimedia
>>>>newsgroup might have to say.
>>>>
>>>>ogg vorbis is like an open source codec like mp3.
>>>>
>>>>"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
>>>>news:ah6va1pk4qscitk3u1sjuvjnp2l6jcrth8@xxxxxxxxxx
>>>>>I don't know what ogg vorbis is, but do you have source? Can you
>>>>>single-step into it?
>>>>>
>>>>> Having the traceback is not terribly useful here, because you didn't
>>>>> say
>>>>> what the
>>>>> exception was, or anything useful about it.
>>>>>
>>>>> Typically, this means you have passed an erroneous parameter into a
>>>>> system
>>>>> call. In this
>>>>> case, via MSVCRT. If you have installed the C runtime sources, you
>>>>> should
>>>>> have gotten a
>>>>> meaningful reference to MSVCRT, such as what function was called. What
>>>>> I
>>>>> see is that you
>>>>> have apparently passed something wrong into ov_open, which led to the
>>>>> error.
>>>>> joe
>>>>>
>>>>> On Tue, 14 Jun 2005 19:02:57 -0400, "Steve Russell"
>>>>> <srussell@xxxxxxxxxxxxxxxxxxxxxx>
>>>>> wrote:
>>>>>
>>>>>>While trying to decode an ogg vorbis file within my MFC app, I am
>>>>>>running
>>>>>>into an exception that I do not understand. Is it possible to comment
>>>>>>on
>>>>>>the problem based on the information below?
>>>>>>
>>>>>> OggVorbis_File vf;
>>>>>> FILE* pFile;
>>>>>> pFile = fopen("test.ogg", "rb");
>>>>>> if(!pFile)
>>>>>> AfxMessageBox("fopen failed");
>>>>>> // here's where I get the exception
>>>>>> int err = ov_open(pFile, &vf, NULL, 0);
>>>>>>
>>>>>>NTDLL! 7c918fea()
>>>>>>NTDLL! 7c90104b()
>>>>>>MSVCRT! 77c413b0()
>>>>>>VORBISFILE! 10001d1d()
>>>>>>
>>>>>
>>>>> Joseph M. Newcomer [MVP]
>>>>> email: newcomer@xxxxxxxxxxxx
>>>>> Web: http://www.flounder.com
>>>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>>>
>>>
>>> Joseph M. Newcomer [MVP]
>>> email: newcomer@xxxxxxxxxxxx
>>> Web: http://www.flounder.com
>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>
>>
>
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- NTDLL exception
- From: Steve Russell
- Re: NTDLL exception
- From: Joseph M . Newcomer
- Re: NTDLL exception
- From: Steve Russell
- Re: NTDLL exception
- From: Joseph M . Newcomer
- Re: NTDLL exception
- From: Steve Russell
- Re: NTDLL exception
- From: Steve Russell
- NTDLL exception
- Prev by Date: Re: Pinning dialog on top of other dialogs
- Next by Date: Re: Easy one: Communication in MDI
- Previous by thread: Re: NTDLL exception
- Next by thread: Re: NTDLL exception
- Index(es):
Relevant Pages
|
Loading
