user breakpoint in DBGHEAP.c 
Author Message
 user breakpoint in DBGHEAP.c

I found something interesting:

Try the following code in MSVC:
//--------------------------------start copy here---------------------------------
#include <windows.h>
#include <list>
#include <utility>
#include <stdio.h>

class CPacket
{
public:
        CPacket(void)
        {
                m_szBuffer[0] = 1;
        }
        ~CPacket(void)
        {
                m_szBuffer[0] = 0;
        }
public:
        char m_szBuffer[290];

Quote:
};

typedef std::pair< DWORD, CPacket* > tPacketPair;
typedef std::list< tPacketPair > tPacketList;

void foo(tPacketList ListOfPackets)
{

        tPacketList Packets;

        Packets = ListOfPackets;

Quote:
}

int main(int argc, char* argv[])
{
        CPacket Packet;

        tPacketPair PacketPair(0,&Packet);

        tPacketList Packets;

        Packets.push_back(PacketPair);

        DWORD dwCount = 0;

        for (;;)
        {
                foo(Packets);

                dwCount++;
        }
        return 0;

Quote:
}

//-----------------------------end copy here-----------------------------------

It all looks pretty innocuous, right? Compile and run the code in the MSVC
de{*filter*}. Open up DBGHEAP.c from the VC98\CRT\SRC directory. Put a breakpoint on
line 337 in _heap_alloc_dbg where it reads:

        lRequest = _lRequestCurr;

        /* break into de{*filter*} at specific memory allocation */
        if (lRequest == _crtBreakAlloc)
            _CrtDbgBreak();

lRequest will increment every time you press F5. Eventually it will scroll over
and hit -1, which is the value of _crtBreakAlloc. Then the program will hit a
user breakpoint, even though nothing is wrong.

This will kill your debug executable if you run it outside of MSVC for long
enough. Within MSVC, the de{*filter*} will deal with the INT3.

Any thoughts as to what this user breakpoint is for?

Dan.



Tue, 04 Nov 2003 06:31:58 GMT  
 user breakpoint in DBGHEAP.c
_crtBreakAlloc is there so that you can tell VC++ to break on a particular
allocation - say, the ten thousandth allocation. This can be very useful.

Your program, by the way, can be simplified down to the code below -
just keep allocating and freeing memory.

Did you really encounter this problem? I've got a fast PC and it looks
like it's going to take six hours of doing nothing but alloc/free before it
wraps the allocation counter. I can see that being a problem for some
people, but it's probably pretty rare. Time for 64-bit numbers I guess.

Here's the simpler program that should produce the problem.

#include <stdio.h>

int main(int argc, char* argv[])
{
 int index = 0;
 while (true)
 {
  char* p = new char[10];
  delete [] p;
  if ((++index & 0xFFFFF) == 0xFFFFF)
   printf("Index is %d.\n", index);
 }
 return 0;

Quote:
}

> I found something interesting:

> Try the following code in MSVC:
> //--------------------------------start copy here---------------------------------
> #include <windows.h>
> #include <list>
> #include <utility>
> #include <stdio.h>

> class CPacket
> {
> public:
>         CPacket(void)
>         {
>                 m_szBuffer[0] = 1;
>         }
>         ~CPacket(void)
>         {
>                 m_szBuffer[0] = 0;
>         }
> public:
>         char m_szBuffer[290];
> };

> typedef std::pair< DWORD, CPacket* > tPacketPair;
> typedef std::list< tPacketPair > tPacketList;

> void foo(tPacketList ListOfPackets)
> {

>         tPacketList Packets;

>         Packets = ListOfPackets;

> }
> int main(int argc, char* argv[])
> {
>         CPacket Packet;

>         tPacketPair PacketPair(0,&Packet);

>         tPacketList Packets;

>         Packets.push_back(PacketPair);

>         DWORD dwCount = 0;

>         for (;;)
>         {
>                 foo(Packets);

>                 dwCount++;
>         }
>         return 0;
> }
> //-----------------------------end copy here-----------------------------------

> It all looks pretty innocuous, right? Compile and run the code in the MSVC
> de{*filter*}. Open up DBGHEAP.c from the VC98\CRT\SRC directory. Put a breakpoint on
> line 337 in _heap_alloc_dbg where it reads:

>         lRequest = _lRequestCurr;

>         /* break into de{*filter*} at specific memory allocation */
>         if (lRequest == _crtBreakAlloc)
>             _CrtDbgBreak();

> lRequest will increment every time you press F5. Eventually it will scroll over
> and hit -1, which is the value of _crtBreakAlloc. Then the program will hit a
> user breakpoint, even though nothing is wrong.

> This will kill your debug executable if you run it outside of MSVC for long
> enough. Within MSVC, the de{*filter*} will deal with the INT3.

> Any thoughts as to what this user breakpoint is for?

> Dan.

--
.Bruce Dawson, Humongous Entertainment (we're hiring).
http://www.*-*-*.com/
Send job applications by e-mail, post technical questions
to the newsgroups please. Thanks.


Tue, 04 Nov 2003 07:12:32 GMT  
 user breakpoint in DBGHEAP.c
Thanks, Bruce.

Yep, I encountered the problem. I'm using the de{*filter*} to do some "soak" tests on
a complex application. Of course, the same tests will have to be performed on a
release build. Like you say, it takes a long time before the problem will occur.
And given that the break occurs based on the number of allocations, the time it
takes to happen depends largely on system load.

The m{*filter*}to the story (if anyone else is reading this...)?

Debug builds are fine for testing and debugging, but that's it. The only version
that should ever be released is a fully tested release build (hence the name).

Dan.



Tue, 04 Nov 2003 22:27:16 GMT  
 user breakpoint in DBGHEAP.c
I've had this problem "User breakpoint called from code 0xXXXX", for quite
some time. I've been using some MFC and the CSocket class, and everytime I
start my application through the de{*filter*}, I get this this message box,
"User breakpoint.....".
This behavior has been pretty consistent with the all socket apps I run
through the de{*filter*}. When the same app is executed from the de{*filter*} using
Ctrl-F5, none of this is seen.


Quote:
> _crtBreakAlloc is there so that you can tell VC++ to break on a particular
> allocation - say, the ten thousandth allocation. This can be very useful.

> Your program, by the way, can be simplified down to the code below -
> just keep allocating and freeing memory.

> Did you really encounter this problem? I've got a fast PC and it looks
> like it's going to take six hours of doing nothing but alloc/free before
it
> wraps the allocation counter. I can see that being a problem for some
> people, but it's probably pretty rare. Time for 64-bit numbers I guess.

> Here's the simpler program that should produce the problem.

> #include <stdio.h>

> int main(int argc, char* argv[])
> {
>  int index = 0;
>  while (true)
>  {
>   char* p = new char[10];
>   delete [] p;
>   if ((++index & 0xFFFFF) == 0xFFFFF)
>    printf("Index is %d.\n", index);
>  }
>  return 0;
> }


> > I found something interesting:

> > Try the following code in MSVC:
> > //--------------------------------start copy

here---------------------------------

- Show quoted text -

Quote:
> > #include <windows.h>
> > #include <list>
> > #include <utility>
> > #include <stdio.h>

> > class CPacket
> > {
> > public:
> >         CPacket(void)
> >         {
> >                 m_szBuffer[0] = 1;
> >         }
> >         ~CPacket(void)
> >         {
> >                 m_szBuffer[0] = 0;
> >         }
> > public:
> >         char m_szBuffer[290];
> > };

> > typedef std::pair< DWORD, CPacket* > tPacketPair;
> > typedef std::list< tPacketPair > tPacketList;

> > void foo(tPacketList ListOfPackets)
> > {

> >         tPacketList Packets;

> >         Packets = ListOfPackets;

> > }
> > int main(int argc, char* argv[])
> > {
> >         CPacket Packet;

> >         tPacketPair PacketPair(0,&Packet);

> >         tPacketList Packets;

> >         Packets.push_back(PacketPair);

> >         DWORD dwCount = 0;

> >         for (;;)
> >         {
> >                 foo(Packets);

> >                 dwCount++;
> >         }
> >         return 0;
> > }
> > //-----------------------------end copy

here-----------------------------------

- Show quoted text -

Quote:

> > It all looks pretty innocuous, right? Compile and run the code in the
MSVC
> > de{*filter*}. Open up DBGHEAP.c from the VC98\CRT\SRC directory. Put a
breakpoint on
> > line 337 in _heap_alloc_dbg where it reads:

> >         lRequest = _lRequestCurr;

> >         /* break into de{*filter*} at specific memory allocation */
> >         if (lRequest == _crtBreakAlloc)
> >             _CrtDbgBreak();

> > lRequest will increment every time you press F5. Eventually it will
scroll over
> > and hit -1, which is the value of _crtBreakAlloc. Then the program will
hit a
> > user breakpoint, even though nothing is wrong.

> > This will kill your debug executable if you run it outside of MSVC for
long
> > enough. Within MSVC, the de{*filter*} will deal with the INT3.

> > Any thoughts as to what this user breakpoint is for?

> > Dan.

> --
> .Bruce Dawson, Humongous Entertainment (we're hiring).
> http://www.*-*-*.com/
> Send job applications by e-mail, post technical questions
> to the newsgroups please. Thanks.



Tue, 04 Nov 2003 22:43:18 GMT  
 user breakpoint in DBGHEAP.c
Shridhar,

Your problem is not the same as Dan's. Dan encountered a limitation in the
debug C run time libraries that only occurs if you do 4 billion allocations.
Dan's
problem is unrelated to the socket libraries.

You have memory corruption of some sort. Look in the output window for
details. You may be encountering the same problem that Randy Charles
Morin mentions in a different thread - in which case W2K SP2 will fix
your problem.

Quote:

> I've had this problem "User breakpoint called from code 0xXXXX", for quite
> some time. I've been using some MFC and the CSocket class, and everytime I
> start my application through the de{*filter*}, I get this this message box,
> "User breakpoint.....".
> This behavior has been pretty consistent with the all socket apps I run
> through the de{*filter*}. When the same app is executed from the de{*filter*} using
> Ctrl-F5, none of this is seen.



> > _crtBreakAlloc is there so that you can tell VC++ to break on a particular
> > allocation - say, the ten thousandth allocation. This can be very useful.

> > Your program, by the way, can be simplified down to the code below -
> > just keep allocating and freeing memory.

> > Did you really encounter this problem? I've got a fast PC and it looks
> > like it's going to take six hours of doing nothing but alloc/free before
> it
> > wraps the allocation counter. I can see that being a problem for some
> > people, but it's probably pretty rare. Time for 64-bit numbers I guess.

> > Here's the simpler program that should produce the problem.

> > #include <stdio.h>

> > int main(int argc, char* argv[])
> > {
> >  int index = 0;
> >  while (true)
> >  {
> >   char* p = new char[10];
> >   delete [] p;
> >   if ((++index & 0xFFFFF) == 0xFFFFF)
> >    printf("Index is %d.\n", index);
> >  }
> >  return 0;
> > }


> > > I found something interesting:

> > > Try the following code in MSVC:
> > > //--------------------------------start copy
> here---------------------------------
> > > #include <windows.h>
> > > #include <list>
> > > #include <utility>
> > > #include <stdio.h>

> > > class CPacket
> > > {
> > > public:
> > >         CPacket(void)
> > >         {
> > >                 m_szBuffer[0] = 1;
> > >         }
> > >         ~CPacket(void)
> > >         {
> > >                 m_szBuffer[0] = 0;
> > >         }
> > > public:
> > >         char m_szBuffer[290];
> > > };

> > > typedef std::pair< DWORD, CPacket* > tPacketPair;
> > > typedef std::list< tPacketPair > tPacketList;

> > > void foo(tPacketList ListOfPackets)
> > > {

> > >         tPacketList Packets;

> > >         Packets = ListOfPackets;

> > > }
> > > int main(int argc, char* argv[])
> > > {
> > >         CPacket Packet;

> > >         tPacketPair PacketPair(0,&Packet);

> > >         tPacketList Packets;

> > >         Packets.push_back(PacketPair);

> > >         DWORD dwCount = 0;

> > >         for (;;)
> > >         {
> > >                 foo(Packets);

> > >                 dwCount++;
> > >         }
> > >         return 0;
> > > }
> > > //-----------------------------end copy
> here-----------------------------------

> > > It all looks pretty innocuous, right? Compile and run the code in the
> MSVC
> > > de{*filter*}. Open up DBGHEAP.c from the VC98\CRT\SRC directory. Put a
> breakpoint on
> > > line 337 in _heap_alloc_dbg where it reads:

> > >         lRequest = _lRequestCurr;

> > >         /* break into de{*filter*} at specific memory allocation */
> > >         if (lRequest == _crtBreakAlloc)
> > >             _CrtDbgBreak();

> > > lRequest will increment every time you press F5. Eventually it will
> scroll over
> > > and hit -1, which is the value of _crtBreakAlloc. Then the program will
> hit a
> > > user breakpoint, even though nothing is wrong.

> > > This will kill your debug executable if you run it outside of MSVC for
> long
> > > enough. Within MSVC, the de{*filter*} will deal with the INT3.

> > > Any thoughts as to what this user breakpoint is for?

> > > Dan.

> > --
> > .Bruce Dawson, Humongous Entertainment (we're hiring).
> > http://www.*-*-*.com/
> > Send job applications by e-mail, post technical questions
> > to the newsgroups please. Thanks.

--
.Bruce Dawson, Humongous Entertainment (we're hiring).
http://www.*-*-*.com/
Send job applications by e-mail, post technical questions
to the newsgroups please. Thanks.


Wed, 05 Nov 2003 00:45:55 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Breakpoint (0x80000003) in dbgheap.c

2. Unhandled Exception:User Breakpoint Message

3. User breakpoint called from code at 0x77fa018c

4. Mysterious user breakpoint?

5. user breakpoint

6. User BreakPoint problem

7. User breakpoint from code ad 0x77f9f9df

8. user breakpoint

9. User Breakpoint in WS2_32.DLL

10. user breakpoint

11. User breakpoint called from ...

12. Unexplicable User breakpoint called at 77F9EEA9 - exact error someone else had posted

 

 
Powered by phpBB® Forum Software