QFile::open() crashes application on call to previously written file

nagesh

@Pollarm check whether file is successfully opened(return value of open) before accessing it.

Pollarm

Hello all,

I've also seen while messing with it that calling file.remove() also causes this behavior.

Is it possible that perhaps there is some kind of corruption in the file, so that when QFile tries to access it this behavior occurs? Just guessing. That seems unlikely to me, because I can open files with QIODevice::ReadOnly in my method that reads the data from the file to reconstruct the project, it only crashes when opened with file.open(QIODevice::WriteOnly).

Thanks

nagesh

@Pollarm Did you check file open return value?
QFile file(projectName);
if(file.open(QIODevice::WriteOnly))
{
QDataStream out(&file); // we will serialize the data into the file
}
else
{
//Failed to open the file
}

Pollarm

Hello @nagesh,

I did try that, and it crashed, I believe inside the if-statement.

Thanks

nagesh

@Pollarm use debugger breakpoint to check which line it crashed?

It only crashes when it is used on a file that was previously passed through this method.

open the file which was saved using this method through explorer and check whether it's having any content?

Pollarm

I'm pretty sure that it crashes on the line that calls

file.open(QIODevice::WriteOnly)

And I have confirmed the file contains the appropriate content.

Thanks

Pollarm

I was able to catch an exception code 0xc0000409, which I've seen means STATUS_STACK_BUFFER_OVERRUN. What could I do that gets around this?

If that is the case, does that mean that this is not a QT issue after all?

kshegunov

@Pollarm said in QFile::open() crashes application on call to previously written file:

If that is the case, does that mean that this is not a QT issue after all?

It doesn't, but I'd be rather surprised this to be a bug in the Qt codebase. Did you extract the above stack trace (the one you posted) from the point of the crash, or did you just stop the debugger there at another time? If the stack was not from a crash, you should reproduce the crash in the debugger and when it happens extract it. Aside from that there are 2 typical reasons for such an error:

You're running an infinite recursion, you should check this. For example it may be a slot calling itself indirectly (through a signal).

or

You've corrupted the stack somewhere without realizing. Writing to a buffer in the stack over its allowed boundaries should do it. Do you have char data[someSize] anywhere you may be saving to, or something of that sort?

It'd be also helpful to see some more code around the point of crash, would you provide how you read the file, what you save from it, etc.

PS. Btw, it doesn't appear your application (assuming Roto is your app) contains debug information. You should build in debug before testing anything else.

Pollarm

@kshegunov I believe I've identified the source of the overflow:

My parameters are being written incorrectly because for some reason (completely unrelated issue) and its causing large values, 9 digits, to be pushed as in index to an array that I think can only hold a maximum of around 57.

Your comment helped me track that down, thanks!!

JKSH

@Pollarm said in QFile::open() crashes application on call to previously written file:

My parameters are being written incorrectly because for some reason (completely unrelated issue) and its causing large values, 9 digits, to be pushed as in index to an array that I think can only hold a maximum of around 57.

If you replace the C arrays with std::vector or QVector, this type of error will be caught immediately when your code is built and run in Debug mode.

Pollarm

Hello all,

Sorry for the long delay in response, I had other issues in this project to work on. The solution to this issue was found, I was using my own extension for the files and it was making windows antivirus grab the files and scan them. Changing the extension to a simple .txt circumvented this issue. Thanks all for your help on this.