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.
> 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).
to the newsgroups please. Thanks.
user breakpoint in DBGHEAP.c