C / C++ / MFC

16-Apr-09 0:15

Hello,

I am doing an application with an "exe" file and some "dll" that are called from the exe.

When I run the exe in Debug (or Debug64) mode and the dll are compiled in Debug (or Debug64) mode the application runs without any problem. But if I mix Debug with Release (or Debug64 with Release 64) the application does not run, and I get this error:

"Unhandled exception at 0x77d4dd50 in PruebaLinkado.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0012c160.."

The dll has "Multi-threaded DLL (/MD)" option

And the exe file has "Multi-threaded (/MT)" option.

Can anybody help me with this problem?

Thanks in advance

Rajesh R Subramanian16-Apr-09 0:37

16-Apr-09 0:37

Why would you mix debug and release mode binaries? Confused | :confused:

It is a crappy thing, but it's life -^ Carlo Pallini

Epi16-Apr-09 0:41

16-Apr-09 0:41

Just during debugging phase.

If I want to debug in the dll and the exe file is working I don't want to change the exe file each time.

Rajesh R Subramanian16-Apr-09 0:43

16-Apr-09 0:43

I don't understand. My question was - why would you have the executable in release mode and the dll in debug mode?

It is a crappy thing, but it's life -^ Carlo Pallini

Epi16-Apr-09 0:50

16-Apr-09 0:50

For example,

I have a develope Team with 5 developers.

One exe that runs the dlls that each developer builds.

If a developer wants to check his work it is not necesary to complie the exe file in debug, he has just to compile his dll in debug mode and check it.

Regards

Rajesh R Subramanian16-Apr-09 1:25

Welcome again in the CP's members memorable quotes!

16-Apr-09 1:25

And how will you know what is happening in the executable if it is built with no debug information? For instance, if an assertion occurs in the executable (even while loading the DLL), you won't know it. You don't have to compile the executable every time. You say the executable remains the same, so, you can have it built with debug symbols in it. After your bugs are fixed, you can build binaries without debug information in it.

Somehow, the idea of mixing separate binaries, some with and some without debug information doesn't look strikingly impressive. Hmmm | :|

It is a crappy thing, but it's life -^ Carlo Pallini

CPallini16-Apr-09 1:48

CPallini

16-Apr-09 1:48

A warm welcome to 'The Legend' [^].
Big Grin | :-D

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

Re: Welcome again in the CP's members memorable quotes!

Rajesh R Subramanian16-Apr-09 1:55

Re: Welcome again in the CP's members memorable quotes!

16-Apr-09 1:55

Ah, thanks. Blush | :O

The link you provided doesn't work, BTW. I went to your profile to view the updated post.

It is a crappy thing, but it's life -^ Carlo Pallini

CPallini16-Apr-09 2:11

CPallini

16-Apr-09 2:11

Rajesh R Subramanian wrote:
The link you provided doesn't work, BTW. I went to your profile to view the updated post.

Yeah, it looks like the 'Permalink' mechanism is broken.
Smile | :)

Epi16-Apr-09 2:01

16-Apr-09 2:01

So if you you make a macro in Excel, and in this macro you call to a function located in your dll, you are able to put Excel.exe in debug?

Rajesh R Subramanian16-Apr-09 2:10

16-Apr-09 2:10

It would be of help to know the difference between Excel and your program: Excel doesn't throw a bad_alloc exception and crash to death. Your application does.

Which means that there's something wrong (you don't know if it's at the library side or at the consumer side), so I asked you to debug them together. You may drop my idea of using debugging symbols if you didn't like it.

It is a crappy thing, but it's life -^ Carlo Pallini

Epi16-Apr-09 2:18

16-Apr-09 2:18

Yes, acctually that's my problem.

I have done a simple test:

Create a dll with a function. (for example:

__declspec(dllexport) int test1(const std::string& chain)<br />
{<br />
	std::string test;<br />
	<br />
	test = "testing: ";<br />
	test += chain;<br />
	return 13;<br />
}

)

Create a exe that import the funtion. (for example:

 #pragma comment(lib, "DllTest.lib")<br />
__declspec(dllimport) int test1(const std::string& cadena);

)

Call to the function of the dll form the exe. (for example:

int io;<br />
	std::string stTest;<br />
	<br />
	io = test1("testing testing");

)

And the results are:
Both in debug -> works (so I cannot find information about the crash)
Both in release -> works
One in debug and one in release -> Crash to death

I think that the problem is in the project options, because there is nothing strange in the code.

CPallini16-Apr-09 2:20

CPallini

16-Apr-09 2:20

Yes he can.
Be careful: don't challenge Rajesh... Roll eyes | :rolleyes:

Epi16-Apr-09 2:35

16-Apr-09 2:35

Ok Ok..... Smile | :)

Roger Stoltz16-Apr-09 1:20

Roger Stoltz

16-Apr-09 1:20

Epi wrote:
"Unhandled exception at 0x77d4dd50 in PruebaLinkado.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0012c160.."

Every time a question with an error description like this it will be followed by another question: have you actually used your debugger?

On the other hand, mixing debug and release built EXE and DLLs will in many cases lead to exceptions that complain about dynamic memory allocations. This is due to that new is redefined in the debug version and adds some book keeping features in order to detect buffer overruns and such. It seems like this is your current problem.

Epi wrote:
The dll has "Multi-threaded DLL (/MD)" option

And the exe file has "Multi-threaded (/MT)" option.

Shouldn't one of them be a debug version? Unsure | :~

You may also benefit from reading this excellent article[^].

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

Epi16-Apr-09 1:46

16-Apr-09 1:46

I am using the debugger, and now I change the options of the executable to Multi-threaded Debug (/MTd) and I get the same.

For instance I am working with a little example.

In this example in the dll I have this funtion:

__declspec(dllexport) int test1(const std::string& chain)<br />
{<br />
	std::string test;<br />
	<br />
	test = "testing: ";<br />
	test += chain;<br />
	return 13;<br />
}

and I am calling it from the exe.

I import it:

<br />
#pragma comment(lib, "DllTest.lib")<br />
__declspec(dllimport) int test1(const std::string& cadena);

and after I call it

int io;<br />
std::string stTest;<br />
io = test1("testing testing");

When I call the function test1, as you predict I get a bad ptr 0xcccccccc.... So should be in the size...

Roger Stoltz16-Apr-09 2:28

Roger Stoltz

16-Apr-09 2:28

Epi wrote:
I change the options of the executable to Multi-threaded Debug (/MTd) and I get the same.

Linking with the debug built version of a library you're using when you're building the debug version of your own binary seems like a Good Idea. Wink | ;)

Yes, you will get the same result, but now you're using the correct version of the runtime libraries if you happen to run into other problems.

Epi wrote:
When I call the function test1, as you predict I get a bad ptr 0xcccccccc....

This suggests an uninitialized stack value.
Read more here[^].
I suspect this to origin from the mix up between debug and release versions and the fact the a debug built binary will add book keeping for both the stack and heap.
Stop mixing them and you'll probably get the result you want.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

Epi16-Apr-09 2:53

16-Apr-09 2:53

I am about to fininsh the article Debug vs Release it is really interenting.

But I think it is not a code problem, because in the test that I have done just now, I haven't anything else except an executable that call a function in a dll passing it a string. No pointers, no arrays...

Cedric Moonen16-Apr-09 2:58

Cedric Moonen

16-Apr-09 2:58

I guess it is due to a mismatch between the runtime library which is used for your exe and for your dll.

Epi wrote:
I haven't anything else except an executable that call a function in a dll passing it a string. No pointers, no arrays...

No really correct: a std string allocates an array internally, and that's what causing the troubles. You are allocating it in your executable and trying to release it in your dll (or the other way around). As you are using two different runtime libraries, there's a crash when the destructor of the string is called because the dll and the exe do not use the same heap.
I'm not really an expert there but I encountered that problem before, I think you are facing the same problem.

Cédric Moonen
Software developer

Charting control [v2.0 - Updated]
OpenGL game tutorial in C++

Epi16-Apr-09 3:40

Re: Issue using SQL server

16-Apr-09 3:40

Ok. Thank you,

Also is related the project option

Basic RunTime Check,

"Default" in all the configurations

Now it works,

Thank you very much to all of you

Issue using SQL server

ShilpiP15-Apr-09 20:36

ShilpiP

15-Apr-09 20:36

Hi, I am creating one sample application that uses SQL Server and create one table having ID and Title (Unicode data).My problem is that i am using unicode data and when i open the table, "Question mark " is displayed in Title instead of unicode data. My workspace is unicode compiled and i am using nvarchar for lingual data as a variable. Here is my code

CDatabase db;
	CString strLingual = L"";
	// strLingual contains unicode data.
	m_edt_lingual.GetWindowTextW(strLingual);
	CString strQuery;
	try
	{
		// Test with Access database
		if (db.Open(NULL, FALSE, FALSE, _T("Driver={SQL Native Client};Server=SHILPI_PHADNIS\\SQLEXPRESS;Database=TransTool;Uid=sp;Pwd=np;")))
		{
			// Create a test table
			db.ExecuteSQL(_T("CREATE TABLE WDCheckLingual (ID INT, Title NVARCHAR(50))"));

			// Add some test data
			for (int i = 0; i < 10; i++)
			{
				strQuery.Format(_T("INSERT INTO WDCheckLingual (ID, Title) VALUES (%d, '%s')"),
					i + 1, strLingual);
				db.ExecuteSQL(strQuery);
			}

		}
	}
	catch (CException *e)
	{
		e->ReportError();
		e->Delete();
	}

Thanks in advance.... Smile | :)

Yes U Can ...If U Can ,Dream it , U can do it ...ICAN

Rajesh R Subramanian28-Jun-09 9:28