__lock_fhandle Fails

[TheMadScientist]

Hello,

When I try to allocate some memory:

Samples = new double[Count];

An exception is thrown in lock_fhandle where retval = 0.

Why is this?


It happens in the source file of "InputFileHandler" when it calls the function "AllocateInputState" of the class "VInput", but only when I run this particular function a second time, even if on a different VInput object, but with the same FileHandler.

If I delete the FileHandler and use a new one, this doesn't happen.

How can I fix it without having to use a new FileHandler object every time?

[kbw]

I have no idea what you mean.

Perhaps you could start by saying what library you're using and what you've done with sample code as necessary.

[zb0S216C]

What operating system are you using?
What compiler are you using?
What library are you using?
Have you tried debugging?
Have you tried exception handling?

There's a lot of important information you've left out.

_Wazzak

[TheMadScientist]

Sorry guys.

I'm using Win32 XP.
I'm using Intel C++.
All of these objects are my own.
Yes.
No.


The exception happens in:

osfinfo.c - Win32 _osfhnd[] support routines

[TheMadScientist]

That c file gets called during fgets.c, which then throws the error.

Even if I create TOTALLY NEW objects and use fgets the SAME WAY i did previously (but with new objects), this error gets thrown.

[TheMadScientist]

So, I can't use fgets huh?

This fails now:

fgets(CharInBuffer, 300, InputFile);

Where:

char* CharInBuffer = (char*) malloc (300);

and I opened the input file using:

InputFile = fopen (FileName,"r");
if (InputFile!=NULL)
{
std::cout<<"The File Was Opened"<<"\n";
}

Where FileName is: "Test_1a.txt"

[TheMadScientist]

Its like fgets gets screwed up somehow. Maybe its a bad pointer to the InputFile?

But I open it the same way, and it works one time, but when I try again it doesn't. I even close the inputfile using fclose after the first time.

Wtf?

[kbw]

If a C runtime function will not throw a C++ exception.

If you are seeing an exception, then it's probably an WIN32 Structured Exception (exception supported by the OS). If that's the case, you can find out what kind of SE it is. My bet would be a NULL pointer violation.

If you're getting all these wierd execptions (of whatever type), I'd say that you've corrupted the heap earlier and the error is not at the point where the exceptions are thrown.