Invalid Page Fault in Release mode with ML compiler option 
Author Message
 Invalid Page Fault in Release mode with ML compiler option

Program runs correctly in Debug mode, but fails in Release mode.
However it works in Release mode if I specify the MLd compiler
option. (ML links with LIBC.LIB, MLd links with LIBCD.LIB)
How would one go about tracing a bug like this? I strongly doubt
that the bug is in my code. Stepping through the assembly code,
it appears that the problem occurs while trying to free heap memory.

Thanks for any help.
Regards,
S. K. Mody.



Thu, 16 May 2002 03:00:00 GMT  
 Invalid Page Fault in Release mode with ML compiler option

Quote:
>Program runs correctly in Debug mode, but fails in Release mode.
>However it works in Release mode if I specify the MLd compiler
>option. (ML links with LIBC.LIB, MLd links with LIBCD.LIB)
>How would one go about tracing a bug like this? I strongly doubt
>that the bug is in my code. Stepping through the assembly code,
>it appears that the problem occurs while trying to free heap memory.

Do you have any DLLs or static libraries involved in passing this
memory? If you're linking in a mixture of debug and release
components, that may be a cause of your problem. Have a look at
Knowledge Base article Q166504 "PRB: MFC and CRT Must Match in
debug/release and static/dynamic" for more details.

If that doesn't resolve the issue, you can try debugging your release
version to pinpoint the problem:

On the Project menu, click Settings, and then click the C/C++ tab.
In the Category drop-down box, click General.
In the Debug info drop-down box, click Program Database.
On the Link tab, select Generate Debug Info.

Dave
--
My address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow-up email copies.



Fri, 17 May 2002 03:00:00 GMT  
 Invalid Page Fault in Release mode with ML compiler option


Quote:
> >Program runs correctly in Debug mode, but fails in Release mode.
> >However it works in Release mode if I specify the MLd compiler
> >option. (ML links with LIBC.LIB, MLd links with LIBCD.LIB)
> >How would one go about tracing a bug like this? I strongly doubt
> >that the bug is in my code. Stepping through the assembly code,
> >it appears that the problem occurs while trying to free heap memory.

> Do you have any DLLs or static libraries involved in passing this
> memory? If you're linking in a mixture of debug and release
> components, that may be a cause of your problem. Have a look at
> Knowledge Base article Q166504 "PRB: MFC and CRT Must Match in
> debug/release and static/dynamic" for more details.

> If that doesn't resolve the issue, you can try debugging your release
> version to pinpoint the problem:

> On the Project menu, click Settings, and then click the C/C++ tab.
> In the Category drop-down box, click General.
> In the Debug info drop-down box, click Program Database.
> On the Link tab, select Generate Debug Info.

 Thanks for your suggestion. I was pretty much using the default
 release settings except for LIBC. But using the de{*filter*} as you
 suggested, I found the following gem in my code:-

    if ( (p < (PtrAssoc.begin())->first) || (p > (PtrAssoc.end())->first) )
   {
          ////throw std::range_error.
    }

 Here PtrAssoc is a typedef for std::map<> from the std C++ lib.
 The second condition in the _if_ statement was generating a
 (system) exception when trying to dereference the end point
 of the container. The de{*filter*} started behaving strangely as soon
 as it entered the function containing this code. Actually this should
 have shown up in the debug runs, since dereferencing end() is an
 invalid operation. This seems to point to a bug in the std::map.
 My reasoning is as follows:-
             Under normal circumstances an error should have been
 generated by std::map (which should have thrown a std::exception).
 But this did not happen. So the error was generated at a lower
 level. In the debug runs end() was for some reason pointing to some
 non-zero value, so nothing happened, whereas in the release runs
 it was indeed pointing to 0, hence - illegal operation error. Does this
 seem plausible?

Regards,
S. K. Mody.



Sun, 19 May 2002 03:00:00 GMT  
 Invalid Page Fault in Release mode with ML compiler option
Most STL functions do not throw exceptions when used incorrectly. This
is because the overhead of continually checking for illegal usage would
slow them down. It is possible to get versions of the STL that _assert_
on illegal usage - that is the appropriate way of detecting these problems.

Your analysis seems quite plausible. You might want to investigate why
your C++ exception handling was catching the processor exception
(the access violation from dereferencing zero). In general this is a
REALLY REALLY bad idea, as it hides bugs (as you just found out).
If your program had crashed in an obvious manner as soon as it
dereferenced end(), instead of making a failed attempt to continue,
then you would have tracked this problem down more easily.

Watch out for catch (...) - it can be very dangerous.

Quote:



> > >Program runs correctly in Debug mode, but fails in Release mode.
> > >However it works in Release mode if I specify the MLd compiler
> > >option. (ML links with LIBC.LIB, MLd links with LIBCD.LIB)
> > >How would one go about tracing a bug like this? I strongly doubt
> > >that the bug is in my code. Stepping through the assembly code,
> > >it appears that the problem occurs while trying to free heap memory.

> > Do you have any DLLs or static libraries involved in passing this
> > memory? If you're linking in a mixture of debug and release
> > components, that may be a cause of your problem. Have a look at
> > Knowledge Base article Q166504 "PRB: MFC and CRT Must Match in
> > debug/release and static/dynamic" for more details.

> > If that doesn't resolve the issue, you can try debugging your release
> > version to pinpoint the problem:

> > On the Project menu, click Settings, and then click the C/C++ tab.
> > In the Category drop-down box, click General.
> > In the Debug info drop-down box, click Program Database.
> > On the Link tab, select Generate Debug Info.

>  Thanks for your suggestion. I was pretty much using the default
>  release settings except for LIBC. But using the de{*filter*} as you
>  suggested, I found the following gem in my code:-

>     if ( (p < (PtrAssoc.begin())->first) || (p > (PtrAssoc.end())->first) )
>    {
>           ////throw std::range_error.
>     }

>  Here PtrAssoc is a typedef for std::map<> from the std C++ lib.
>  The second condition in the _if_ statement was generating a
>  (system) exception when trying to dereference the end point
>  of the container. The de{*filter*} started behaving strangely as soon
>  as it entered the function containing this code. Actually this should
>  have shown up in the debug runs, since dereferencing end() is an
>  invalid operation. This seems to point to a bug in the std::map.
>  My reasoning is as follows:-
>              Under normal circumstances an error should have been
>  generated by std::map (which should have thrown a std::exception).
>  But this did not happen. So the error was generated at a lower
>  level. In the debug runs end() was for some reason pointing to some
>  non-zero value, so nothing happened, whereas in the release runs
>  it was indeed pointing to 0, hence - illegal operation error. Does this
>  seem plausible?

> Regards,
> S. K. Mody.

--
.Bruce Dawson, Cavedog Entertainment.
Makers of Total Annihilation - http://www.*-*-*.com/


Sun, 19 May 2002 03:00:00 GMT  
 Invalid Page Fault in Release mode with ML compiler option
Yes, I just remembered that STL containers are not range checked.
In fact since, some container implementations simply use a pointer as
the iterator type, it wouldn't even be possible for them to prevent
invalid dereferencing.
I assume(?) that catch(...) would be safe in the form:-
                     catch(...) { //.. ; throw; }

Thanks.
Regards,
S. K. Mody.


Quote:
> Most STL functions do not throw exceptions when used incorrectly. This
> is because the overhead of continually checking for illegal usage would
> slow them down. It is possible to get versions of the STL that _assert_
> on illegal usage - that is the appropriate way of detecting these
problems.

> Your analysis seems quite plausible. You might want to investigate why
> your C++ exception handling was catching the processor exception
> (the access violation from dereferencing zero). In general this is a
> REALLY REALLY bad idea, as it hides bugs (as you just found out).
> If your program had crashed in an obvious manner as soon as it
> dereferenced end(), instead of making a failed attempt to continue,
> then you would have tracked this problem down more easily.

> Watch out for catch (...) - it can be very dangerous.




> > > >Program runs correctly in Debug mode, but fails in Release mode.
> > > >However it works in Release mode if I specify the MLd compiler
> > > >option. (ML links with LIBC.LIB, MLd links with LIBCD.LIB)
> > > >How would one go about tracing a bug like this? I strongly doubt
> > > >that the bug is in my code. Stepping through the assembly code,
> > > >it appears that the problem occurs while trying to free heap memory.

> > > Do you have any DLLs or static libraries involved in passing this
> > > memory? If you're linking in a mixture of debug and release
> > > components, that may be a cause of your problem. Have a look at
> > > Knowledge Base article Q166504 "PRB: MFC and CRT Must Match in
> > > debug/release and static/dynamic" for more details.

> > > If that doesn't resolve the issue, you can try debugging your release
> > > version to pinpoint the problem:

> > > On the Project menu, click Settings, and then click the C/C++ tab.
> > > In the Category drop-down box, click General.
> > > In the Debug info drop-down box, click Program Database.
> > > On the Link tab, select Generate Debug Info.

> >  Thanks for your suggestion. I was pretty much using the default
> >  release settings except for LIBC. But using the de{*filter*} as you
> >  suggested, I found the following gem in my code:-

> >     if ( (p < (PtrAssoc.begin())->first) || (p >

(PtrAssoc.end())->first) )

- Show quoted text -

Quote:
> >    {
> >           ////throw std::range_error.
> >     }

> >  Here PtrAssoc is a typedef for std::map<> from the std C++ lib.
> >  The second condition in the _if_ statement was generating a
> >  (system) exception when trying to dereference the end point
> >  of the container. The de{*filter*} started behaving strangely as soon
> >  as it entered the function containing this code. Actually this should
> >  have shown up in the debug runs, since dereferencing end() is an
> >  invalid operation. This seems to point to a bug in the std::map.
> >  My reasoning is as follows:-
> >              Under normal circumstances an error should have been
> >  generated by std::map (which should have thrown a std::exception).
> >  But this did not happen. So the error was generated at a lower
> >  level. In the debug runs end() was for some reason pointing to some
> >  non-zero value, so nothing happened, whereas in the release runs
> >  it was indeed pointing to 0, hence - illegal operation error. Does this
> >  seem plausible?

> > Regards,
> > S. K. Mody.

> --
> .Bruce Dawson, Cavedog Entertainment.
> Makers of Total Annihilation - http://www.*-*-*.com/



Sun, 19 May 2002 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Invalid Page Fault in Release mode with ML compiler option

2. Page fault when compile using Release mode but not Debug mode

3. NEED HELP: Thread Termination causes invalid page fault in Release built only

4. Invalid page fault in Windows98

5. Invalid Page Fault?

6. Invalid page faults when accessing large arrays

7. caused an invalid page fault in module ...

8. Invalid Page fault in module MSJT3032.DLL

9. Invalid page fault

10. Invalid page fault

11. invalid page fault

12. invalid page fault ...

 

 
Powered by phpBB® Forum Software