<possibly OT>access violation

[Allen]

Hi all,

I tried posting to one of the ms.win32 groups and haven't gotten a
response yet. It may be my C++ that's at fault anyway so I'll try here too.

I wrote a .dll that is misbehaving (access violation at startup) and I
can't find the problem. I'm using load time linking and, when I try to step
into program execution to find the problem, I don't even get to the start of
WinMain before it throws the exception. The source files are a little too
big to post here but, I'll send them to any who are willing to take the time
to help me. I suspect it's something dumb that I either overlooked or
didn't know about. I'm not a professional and I've never taken any
programming classes so please don't laugh too hard! I'm still sort of new
at this.
--

Best wishes,
Allen

No SPAM in my email !!



Here are some of the sections where I suspect the problem might be.

//commandmain.cpp--main .dll file
#include "CmdBuffer.h"

PCCOMMANDBUF pcbCommandBuf = new CCommandBuffer("concmd.ngc");
/*since the exception is thrown immediatly upon loading, I think this "new"
might be the problem. I have another .dll that works fine though and it
does almost the exact same thing*/

EXPORT int ExecCmdLine(PCOMMANDMSG pCmdMsg, DWORD dwExecFlags=0)
{
return pcbCommandBuf->CBExec(pCmdMsg, dwExecFlags);
}
//end excerpt


//CmdBuffer.h--header for CCommandBuffer
class CCommandBuffer : CCommandList
{
public:
CCommandBuffer(char* pszInitialLibrary);
~CCommandBuffer();
int CBExec(PCOMMANDMSG pCmdMsg, DWORD dwExecFlags);
int CBPopBuf();
int CBFlushBuf();
private:
int CB_iMaxCount;
int CB_iCmdCount;
int CB_iExecIndex;
PCOMMANDMSG CB_pcmCmdBuf;
int AllocBuf();
int PopIndex();
int PushIndex();
int QueueBuf(PCOMMANDMSG pCmdMsg);
int PushBuf(PCOMMANDMSG pCmdMsg);
};
//end excerpt


//CmdBuffer.cpp--main source for CCommandBuffer
#include "CmdBuffer.h"
#include "..\util.h"

CCommandBuffer::CCommandBuffer(char* pszLibrary) :
CCommandList(pszLibrary)
{
CB_iCmdCount = 0;
CB_iMaxCount = 0;
CB_iExecIndex = 0;

AllocBuf();
}

int CCommandBuffer::AllocBuf()
{
PCOMMANDMSG pcmTemp;

//don't overwrite MaxCount yet, PopIndex needs it
int iTempMaxCount = CB_iMaxCount < CMDBUF_MIN_ELEMENTS ?
CMDBUF_MIN_ELEMENTS : CB_iMaxCount+2;
pcmTemp = (PCOMMANDMSG)LocalAlloc(LPTR, sizeof(CommandMsg) *
iTempMaxCount);
if(pcmTemp == NULL)
{
Write_Error("\nCCommandBuffer::AllocBuf() memory allocation
failed");
return ERROR_FATAL;
}

//copy current cmds to new buffer--must end up sequential
if(CB_pcmCmdBuf)
{
for(int i=0; i < CB_iCmdCount; i++)
memcpy((void*)&pcmTemp, (void*)&CB_pcmCmdBuf[PopIndex()],
sizeof(CommandMsg));
}

CB_iExecIndex = 0;
CB_iMaxCount = iTempMaxCount; //ok, now overwrite
if(CB_pcmCmdBuf)
delete CB_pcmCmdBuf;
CB_pcmCmdBuf = pcmTemp;

return OK;
}
//end excerpt

 

[RCS]

Also look out for the insidious "standard" on Windows that memory allocated
by one DLL can't be deleted by another DLL of app (causes an access
violation).

So if the DLL has got this function:

void dll_test (std::vector<std::string> vec)
{
vec.push_back("TEST"); // Memory for string "TEST" allocated by DLL here
}

and you call this from an app that uses the DLL:


void my_test()
{
std::vector<std::string> myvec
dll_test (myvec);
} // Memory for myvec and "TEST" string deleted by app here


You will get an access violation.

RCS

Hi all,

I tried posting to one of the ms.win32 groups and haven't gotten a
response yet. It may be my C++ that's at fault anyway so I'll try here too.

I wrote a .dll that is misbehaving (access violation at startup) and I
can't find the problem. I'm using load time linking and, when I try to step
into program execution to find the problem, I don't even get to the start of
WinMain before it throws the exception. The source files are a little too
big to post here but, I'll send them to any who are willing to take the time
to help me. I suspect it's something dumb that I either overlooked or
didn't know about. I'm not a professional and I've never taken any
programming classes so please don't laugh too hard! I'm still sort of new
at this.
--

Best wishes,
Allen

No SPAM in my email !!



Here are some of the sections where I suspect the problem might be.

//commandmain.cpp--main .dll file
#include "CmdBuffer.h"

PCCOMMANDBUF pcbCommandBuf = new CCommandBuffer("concmd.ngc");
/*since the exception is thrown immediatly upon loading, I think this "new"
might be the problem. I have another .dll that works fine though and it
does almost the exact same thing*/

EXPORT int ExecCmdLine(PCOMMANDMSG pCmdMsg, DWORD dwExecFlags=0)
{
return pcbCommandBuf->CBExec(pCmdMsg, dwExecFlags);
}
//end excerpt


//CmdBuffer.h--header for CCommandBuffer
class CCommandBuffer : CCommandList
{
public:
CCommandBuffer(char* pszInitialLibrary);
~CCommandBuffer();
int CBExec(PCOMMANDMSG pCmdMsg, DWORD dwExecFlags);
int CBPopBuf();
int CBFlushBuf();
private:
int CB_iMaxCount;
int CB_iCmdCount;
int CB_iExecIndex;
PCOMMANDMSG CB_pcmCmdBuf;
int AllocBuf();
int PopIndex();
int PushIndex();
int QueueBuf(PCOMMANDMSG pCmdMsg);
int PushBuf(PCOMMANDMSG pCmdMsg);
};
//end excerpt


//CmdBuffer.cpp--main source for CCommandBuffer
#include "CmdBuffer.h"
#include "..\util.h"

CCommandBuffer::CCommandBuffer(char* pszLibrary) :
CCommandList(pszLibrary)
{
CB_iCmdCount = 0;
CB_iMaxCount = 0;
CB_iExecIndex = 0;

AllocBuf();
}

int CCommandBuffer::AllocBuf()
{
PCOMMANDMSG pcmTemp;

//don't overwrite MaxCount yet, PopIndex needs it
int iTempMaxCount = CB_iMaxCount < CMDBUF_MIN_ELEMENTS ?
CMDBUF_MIN_ELEMENTS : CB_iMaxCount+2;
pcmTemp = (PCOMMANDMSG)LocalAlloc(LPTR, sizeof(CommandMsg) *
iTempMaxCount);
if(pcmTemp == NULL)
{
Write_Error("\nCCommandBuffer::AllocBuf() memory allocation
failed");
return ERROR_FATAL;
}

//copy current cmds to new buffer--must end up sequential
if(CB_pcmCmdBuf)
{
for(int i=0; i < CB_iCmdCount; i++)
memcpy((void*)&pcmTemp, (void*)&CB_pcmCmdBuf[PopIndex()],
sizeof(CommandMsg));
}

CB_iExecIndex = 0;
CB_iMaxCount = iTempMaxCount; //ok, now overwrite
if(CB_pcmCmdBuf)
delete CB_pcmCmdBuf;
CB_pcmCmdBuf = pcmTemp;

return OK;
}
//end excerpt

 

[RCS]

{
vec.push_back("TEST"); // Memory for string "TEST" allocated by DLL here
}

That should be:

void dll_test (std::vector<std::string>& vec)
{
vec.push_back("TEST"); // Memory for string "TEST" allocated by DLL
here
}

 

[Alf P. Steinbach]

Also look out for the insidious "standard" on Windows that memory allocated
by one DLL can't be deleted by another DLL of app (causes an access
violation).

That's not a "standard", and it is in fact 100% incorrect.

You need to know what you're doing when programming on any
platform.

If you do things correctly, regardless of platform, then there is
no such problem as you describe; otherwise, there is. The details
just concern tool usage and so are off-topic in this group. For
more information visit the os-specific groups, comp.os.*.

 

[RCS]

That's not a "standard", and it is in fact 100% incorrect.

That's why I said "standard", and not standard .
And in fact, it's 100% correct (on Windows, that is).

You need to know what you're doing when programming on any
platform.

Pretty obvious, isn't it?
That's why, as a help, I pointed out that on the platform WINDOWS you can
get into trouble if you delete memory allocated by a DLL outside the DLL,
and this is one of the things one need to know when programming for Windows
(using Visual C++).

If you do things correctly, regardless of platform, then there is
no such problem as you describe; otherwise, there is.

What does this mean? You might as well have said: "If you stand on your
head, your feet is in the air, otherwise they don't"

just concern tool usage and so are off-topic in this group. For
more information visit the os-specific groups, comp.os.*.

The problems Allen reported could be os-spesific (for Windows). That's why I
mentioned an possible os-spesific source of troubles.

RCS

 

[Christian Janßen]

Also look out for the insidious "standard" on Windows that memory
allocated
Things like this may happen if - and only if - you statically link your EXE
against RT libs and dynamically link your DLL against RT libs...

 

[Christian Janßen]

And in fact, it's 100% correct (on Windows, that is).

It's 100% wrong - see my prev posting. When things like this happen it's
your fault...

 

[RCS]

It's 100% wrong - see my prev posting. When things like this happen it's
your fault...

No, it's your fault

RCS

 

[Christian Janßen]

No, it's your fault

Mine? It works like expected here. No problems. So if _you_ have
difficulties with this, it _must_ be your mistake!

 

[RCS]

Mine? It works like expected here. No problems. So if _you_ have
difficulties with this, it _must_ be your mistake!

Hey, I was only trying to be funny

RCS