minGW iostrem GetLastError 1113

Pages: 12
Aug 24, 2011 at 11:06am
1
2
3
4
5
6
7
8
9
#include <windows.h>
#include <iostream>// GetLastError() will be 0 if these
using namespace std;// two lines are removed

int main() {
	GetLastError();

	return 0;
}

I'm using Win7+MinGW, put the code in notepad -> save -> compile,
the GetLastError() returns 1113
if I don't include iostream, the err code is 0
I tried debug with Ollydbg, seems there are some initializing code for iostream, and what comes the error 1113 is a MultiByteToWideChar,
it all happens before the main() function

like the picture:
http://i1021.photobucket.com/albums/af333/aj3423/oc1.png
the call at 401093 causes the 1113
how can I fix this?

another question is, since I'm using MinGW g++, and don't use any function of msvcrt, why exe loads the msvcrt.dll?

Thanks.
Last edited on Aug 24, 2011 at 11:07am
Aug 24, 2011 at 11:44am
how can I fix this?

Nothing is broken, so there is nothing to fix.

another question is, since I'm using MinGW g++, and don't use any function of msvcrt, why exe loads the msvcrt.dll?

As you already noticed, main isn't the first thing that is being run. Before that, there's some code added by the compiler which properly sets up the environment, initializes global variables and static members etc.
If you look at your executable, you'll see that quite a number of symbols from msvcrt.dll are being imported (__getmainargs, __p__environ, __p__fmode, __set_app_type, _assert, _cexit, _iob, _onexit, _setmode, abort, atexit, free, malloc, memcpy and signal).
Aug 25, 2011 at 2:31am
Thanks Athar,
I googled a lot but found nothing.. seems no one has this problem like I did.
I guess I must put a SetLastError(0) at the beginning of all my main() functions...
Aug 25, 2011 at 4:16am
I googled a lot but found nothing.. seems no one has this problem like I did.

You don't have a problem. I'll quote myself:
Nothing is broken, so there is nothing to fix.
The call to MultiByteToWideChar is an implementation detail and is nothing you should concern yourself with.

I guess I must put a SetLastError(0) at the beginning of all my main() functions...

No! Why would you do that? What are you trying to accomplish?
Aug 25, 2011 at 4:41am
if I write some code like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
// #include ....
#include <iostream>
using namespace std;

int main() {
	call_some_initializing_function();// something like WSAStartup(...)
	int err = GetLastError();
	if(err != 0 ) {
		return err;
	}
	do_the_job(); // never goes here
	return 0;
}

it will never work, the err will always be 1113...
Aug 25, 2011 at 5:10am
That's because WSAStartup does not set any error code. See:
http://msdn.microsoft.com/en-us/library/ms742213%28v=vs.85%29.aspx
Aug 25, 2011 at 6:23am
but maybe not particularly the WSAStartup, may be some other function that need a GetLastError to verify the result
Aug 25, 2011 at 6:32am
And when you call such a function, the error code will be set to a new value (duh?).
Aug 25, 2011 at 6:59am
I tried with ::CreateThread, seems if a function executes successfully, it won't call SetLastError(0), so the err code won't be set to Zero, it's still 1113..
Aug 25, 2011 at 7:05am
Of course, it only sets it when it fails (which is indicated by its return value).
You should really check the documentation of the functions you're using beforehand:
http://msdn.microsoft.com/en-us/library/ms682453%28v=vs.85%29.aspx
Aug 25, 2011 at 7:31am
Thanks for your patient Athar
I do read every function I use from msdn, but in this case I don't mean any particular function. since error checking using GetLastError() is used a lot.
for example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <iostream>
using namespace std;

int main() {
	// now the error code is 1113

	call_some_func_may_change_err_code();
	// if the function goes successfully, it won't modify the err code,
	// so the err is still 1113, then some checking like this will fail
	if(GetLastError() == 0) {	// 0 is expected when no error occurs
		do_something(); 		// but err==1113, so it never goes here
	} else {
		do_something_unexpected();	// it goes here and does a lot of unexpected
		MessageBox('wrong')
		log_error('wrong, err code: ' + GetLastError);
		...
	}
}

Aug 25, 2011 at 7:53am
Most functions do not set the error code when they succeed. Whether a function has failed or not is usually indicated by their return value. You can call GetLastError() when the function has failed, but only if you want to know why it has failed.
Aug 25, 2011 at 8:15am
If there's no error it depends on the function whether it resets the error code. Some do some not. Reliable is it only when there's actually an error condition and this only directly after the function is called. MSDN says:
You should call the GetLastError function immediately when a function's return value indicates that such a call will return useful data. That is because some functions call SetLastError(0) when they succeed, wiping out the error code set by the most recently failed function.

Most functions in the Win32 API that set the thread's last error code value set it when they fail; a few functions set it when they succeed. Function failure is typically indicated by a return value error code such as FALSE, NULL, 0xFFFFFFFF, or –1. Some functions call SetLastError under conditions of success; those cases are noted in each function's reference page.

Error codes are 32-bit values (bit 31 is the most significant bit). Bit 29 is reserved for application-defined error codes; no system error code has this bit set. If you are defining an error code for your application, set this bit to one. That indicates that the error code has been defined by an application, and ensures that your error code does not conflict with any error codes defined by the system.

To obtain an error string for system error codes, use the FormatMessage function. For a complete list of error codes, see Error Values or the SDK header file WINERROR.H.
Aug 25, 2011 at 8:19am
closed account (1vRz3TCk)
MSDN wrote:
You should call the GetLastError function immediately when a function's return value indicates that such a call will return useful data.
As Athar says, you should call GetLastError to find out what the last error was and NOT to find out if the last function call failed.
Aug 25, 2011 at 8:57am
I tried with VC6 with the same code, and the error code is Zero;
Seems I should be careful with my MinGW programs -_-
Aug 25, 2011 at 9:01am
I tried with VC6 with the same code, and the error code is Zero;
Seems I should be careful with my MinGW programs -_-

No. You should actually read what people say (or MSDN, for that matter).
No offense, but one kinda gets the feeling of talking to a wall.
Aug 25, 2011 at 9:23am
:)
I think I got it about the preferred way of calling functions and error checking. but I still think the 1113 is caused by the minGW and may be there's some configuration could correct this.
same code comes different result between VC6 and MinGW g++, I think this is what really matters.
Aug 25, 2011 at 9:36am
Obviously g++ calls MultiByteToWideChar with a certain parameter as the last error code setting function of the startup routine while VC6 does not and...

I think this is what really matters.

... it does not matter one bit.
What the startup routine does is none of your concern. Its job is to set up a C++ environment. How that is done and what functions are called in order to accomplish that is left to the compiler.
Last edited on Aug 25, 2011 at 9:41am
Aug 25, 2011 at 11:46am
I know I'm stubborn, please don't take it seriously :)

but I still don't think a compiler should change anything that is shared with user(the main() function). no matter what and how you do with your initialization, the user's environment should be left clean.
now the user says: "hey, I've done anything yet, and I'm wrong, with error code 1113."
MinGW say: "you're not wrong, you should check yourself in a better way, check the return value first, then the error code"
user say: "That's my habbit, it always work with VC"
it's not right to kill a program if it's written with bad habit, sounds like kill a man if he has a bad habit. it's not the compiler's business, IMO, if it changes something, it should restore it back.

this's my another piece of code, a program to very the result of tls initialization
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// tls_check.cpp
#define _WIN32_WINNT 0x600

#include <windows.h>
#include <iostream>
using namespace std;

#include "tls.h"

int main() {
	int err = GetLastError(); // verify the tls result, it should be 999, but it's 1113
	if(err != 0) {
		//call_some_api_that_not_available_in_tls();
		cout << "failed on initializing" << endl;
	}
}

1
2
3
4
5
6
7
8
9
10
11
12
13
// tls.h
void NTAPI tls_initialize(void* h, DWORD dwReason, PVOID pv) {
	//if(err_occur_when_initlizing()) {
		::SetLastError(999);
	// }
}
extern "C" {

const IMAGE_TLS_DIRECTORY32 _tls_used __attribute__ ((section(".CRT$XLB"))) = {
		(DWORD)&tls_initialize,
		(DWORD)NULL
	};
}

since the tls callback is limited, lots of api are not available, so I put the error handling in main() function, and it got the error 1113.

I'm not waiting to get a workaround for this code, there always be a workaround, I'm just trying to say, a lot of programs may have this 1113 problem, what's strange to me is I didn't found anything about this from google, there isn't any documentation, no one had even talked about this.
Aug 25, 2011 at 11:56am
Well I'm following your discussion a while and am getting more and more amused. I've got one question for you in return: why are you asking stuff here if you give a shit what people answer?

As far as I understand (and I'm not familar with windows) just from the stuff the other say: GetLastError(); is NOT a function to check whether THERE ARE errors but to spice up your error report once you encountered one!
Pages: 12