seekg crashes

[fluppe]

Hi,

i would like to know what might cause "seekg" to crash ...

        ifstream fips(path);

        if (fips.bad() || !fips.is_open()){
		return -1;
	}
	
	fips.seekg(0, fips.end); // This crashes ...
	std::streamoff length = fips.tellg();
	fips.seekg(0, fips.beg);

I found a lot of things on seekg(), but not what i was searching.
The thing is: On my computer, that works, on another it does not. I don't know why ... i have no idea what to try ... any possible reason would be helpful i guess.

Best regards,
...

[lastchance]

Added some CHECK lines and called it as part of a function:

#include <iostream>
#include <fstream>
using namespace std;

int test( char *path )
{
        ifstream fips(path);

        if (fips.bad() || !fips.is_open())
        {
                cout << "CHECK: Something bad happened" << endl;
                return -1;
        }
        cout << "CHECK: Nothing bad happened" << endl;
        
        fips.seekg(0, fips.end); // This crashes ... NO IT DOESN'T
        std::streamoff length = fips.tellg();
        fips.seekg(0, fips.beg);

        cout << "CHECK: Got to the end and nothing wrong" << endl;
        return 0;
}


int main()
{
        char path[] = "test3.cpp";               // a file in my local directory
        test( path );
}

Ran quite happily to the end (even with g++, which is notoriously sensitive to dubious code).

How do you know it crashes at the point you claim? Perhaps you need to supply us with more code.

From the sensitivity to which computer you use I suspect it might be the file specified in 'path'; however, I have no way of knowing from the information given.

[jlb]

That snippet seems to work fine for me?

What exactly is the operating system reporting when the program "crashes"?

[coder777]

Within a sane environment seekg(...) will not crash. Likely the stack is corrupt and that is the effect.

[helios]

My bet would be a corrupted heap. Probably a double delete or a buffer overflow.

[fluppe]

I use the same code in different VS2013 solutions on different machines ( i have checked some things in the project settings so far ).
I know that a corrupted heap or stack might cause that, but would the behaviour then be machine or "project setting" dependent ?
The debugger on my machine never comlained about any such issue. So if the heap got corrupted, it happened only in one of the environments i think.

In the debugger, i get an access violation in a function (belongs to fstream) called __Lock()
i think it was like

 
CRT_OR_THIS_CALL __Lock(){

....// there it happens 

}

... and it is an access violation.
I just do not know why.
@jlb: so it did seem to me until recently ... but here i am now.
@coder777/helios: How can i get the stack/heap corrupted ... without explicitly coding something to break it ... in this case it must be (at least i think so) related to the project settings i think, but i cannot figure out what that could be. I'll set up a project with exactly the code, to be sure on that.

So far, thanks a lot,
....

[helios]

If you have memory corruption, then the program's behavior is undefined. It might crash or it might not. Showing that the same code doesn't crash on some machines or when compiled in certain ways is not sufficient to prove that the code is correct.

Yes, memory corruption is sensitive to compiler settings. For example, most compilers allocate stack differently when compiled using different options. The dynamic allocation functions may also initialize memory, for example, in debug configurations.

You should stop playing around with compiler settings and just find the place where you're corrupting memory. Look in places where you manage memory manually with new/delete or malloc()/free(), or where you access arrays directly. Sometimes, something as simple as an uninitialized variable being using in a switch statement can be the cause.

[fluppe]

Well, i already tried ... the thing is, i don't use manual alloc/free memory or new and delete and such stuff in the containing program.
There is some dll that maybe does, or maybe does not alloc/free some memory ... i do not know ... but i excluded it ... without finding out the issue.
I simply do not understand how i can corrupt heap there and not corrupt it here ... with the same code.
So I think it might be helpful to know which compiler settings are possibly ... well, not causing the issue, but ... let's say making it visible.
Anyway, i'll try again ... there must be something i missed.

[helios]

Does the crash keep happening if you don't use any functions from that DLL?
If not, then you've proven that there's some problem with how you're using that DLL, or that there's a bug in the DLL's code.
If they do keep happening, then you've proven that the problem is unrelated to the DLL.

[cire]

How can i get the stack/heap corrupted ... without explicitly coding something to break it ...

I'd say it's pretty rare someone explicitly codes something to corrupt memory and then asks for help. As to the how, it is far too simple -- just access memory you shouldn't be accessing. A one-past-the-end access of a buffer is sufficient to cause these sorts of problems. You don't need to be managing your own memory for this to happen.

[jlb]

Your program is crashing, so use your debugger, your debugger will tell you exactly where it detects the problem and when the program crashes look at the variables at the time of the crash and study the crash log. Back trace until you are in your own code, code from the standard libraries will rarely cause your program to crash, normally it will be in your own code.

If you still can't find the source of the problem then post your complete program, one that we can compile and run if we so desire.

[helios]

If the problem is corrupted memory, as it very likely is, the ultimate cause of the crash may be arbitrarily far from the point of crash. That's what makes debugging memory corruption so difficult. You need to use a memory debugger like Valgrind, or have very few places where memory might be manipulated directly.

[fluppe]

@cire: Well i did mean ... a line of code that was "explicitly", but still accidently written by my own faulty fingers ... so please excuse me if i said that wrong.
Is an access violation really enough to break the heap? I have only come across such heap troubles when freeing memory that should not be freed, or free it twice or something like that. Well, i am the beginner.
@jlb: as i stated earlier, i get an "access violation" in a method of "fstream" class ... that was what the debugger told me. And that will not occur in general but it depends on the containing project and machine. Therefore almost everyone here suggested that the problem might be caused by damaged heap ... the method that crashes won't do that if everything is OK ... i would consider it to be more stable than everything i have coded so far.

I have isolated the functions that i have created and that use fstream so far and it works, on both machines, with both project settings. So i have to consider that some function call to an external .dll i missed to remove from the project earlier causes a heap problem ... which is really bad, i guess. I will have a look at that.

Can such a thing be caused by using different MSVC libs in the .dll and the containing exe? I think of debug dlls and such stuff, but well ...

[lastchance]

Check every array element that you use - if it goes outside the array bounds every compiler/operating system/coding environment will send it somewhere different.

Check every use of new or delete.

[jlb]

You really really need to learn how to use your debugger properly. Perhaps this like may help.

https://msdn.microsoft.com/en-us/library/k0k771bt.aspx

[fluppe]

Hi again,

Using my own code all alone worked fine. On every machine with the same compiler and linker settings ...

The issue could be solved with adjusting the "C++ / Code Generation / Runtime library" setting in the VS project settings ... from "/MDd" to "/MD"

Of course i do not know, why exactly that happened, but that dll i called was built with another "Runtime library" than the Executable and that seemed to cause that serious problem ... anyway, to me it seems like the dll must have damaged the heap because it was built with other dependencies, now calling the same dependencies that the executable used ... that might happen, or not?
And that is usually avoided by the linker that throws tons of "undefined external" errors if for example i try linking a 64bit lib into a 32bit executable, or not?

Anyway, it was not code from the std. libs ( by the way never considered that to be really possible ) but i am quite happy: It wasn't mine as well ...

@jlb: To clarify ... if i backtrace the crash from where it occures ( in "seekg " method ) up to my own code ... what i did ... i end up right in the line that i posted initially ... once again:

       ifstream fips(path);
       if (fips.bad() || !fips.is_open()){
		return -1;
	}
	
	fips.seekg(0, fips.end); // This crashes ...
	std::streamoff length = fips.tellg();
	fips.seekg(0, fips.beg);

which i found puzzeling.
... so i do not know ... maybe in this special case, how a better knowledge of this debugger should have helped me any further ... the point is: the code is and was OK ...


Thanks for the answers and replies, thanks for thinking about my problem, and best regards so far,
...