I was getting some mysterious memory corruption in a large PortablE program (which is converted to C++ code that GCC compiles). It happened early in the program, and despite my best efforts all the code looked perfectly fine.
Eventually I seemingly tracked it down to a procedure built-in to PortablE called FileLength(), and after replacing that with an entirely different implementation the program now seems to be completely stable.
The baffling part is that FileLength() just uses standard C procedures, so I cannot see how it could be responsible for the corruption. Even more, most of the code was never executed because it was being called on two paths that has no corresponding file. Here's the code, along with a main() procedure that attempts to emulate the situation:
Could it be that fopen doesn't handle directories very well? According to a stack overflow thread: Quote:
Directories do not exist in the C99 standard (or the C2011 one). So by definition, fopen-ing a directory is either implementation specific or undefined behavior.
Is perhaps errno set to something indicating you're dealing with a directory? Or could you perhaps use stat() to determine if it really is a file?
@jaokim I'm not opening a directory, so I don't see how that's relevant... (In fact I'm not even opening a file, because it doesn't exist!)
The non-existant files were in ENVARC: and ENV:, but I don't see that should make any difference. (ENV: is special on OS4, but again I don't see that should make any difference, unless the bug is in OS4...)
One possibility might be that the code you think is at fault (FileLength) isn't. Could it be that something before or after doesn't clear or allocates memory as it should, and that the FileLength-call you changed to somehow manages to clear the memory. I'm thinking that some pointer accidently gets used twice somewhere, or something like that.
You say memory corruption, how do you know that? (I'm not implying you're wrong, I'm merely seeking more information.)
Given that the code you pasted only contain a few calls, and neither of them are strange and rather basic, it's unlikely they're at fault to be honest.
There's no long/int conversion thing that goes wrong? I'm thinking that perhaps the -1 should be something like -1L.
Given that the code you pasted only contain a few calls, and neither of them are strange and rather basic, it's unlikely they're at fault to be honest.
That's what I thought. I just wanted to be sure I hadn't done something really stupid in the FileLength() code. I guess I'll keep digging...
edit: I'm currently unable to reproduce the crash again, despite undoing the relevant code changes I've made. But since then I've got rid of a ton of tabs that I'd had for ages in Odyssey, which on their own seemed to cause Odyssey problems if left for long enough. I can't recall whether I ever had it crash when I had *not* run Odyssey, so it's not impossible that one of the tabs was causing Odyssey to trash something that indirectly happened to affected my program...
Edited by ChrisH on 2015/10/4 20:39:42 Edited by ChrisH on 2015/10/4 20:40:31
So you had this problem for a long time while never rebooting the machine? The mediaplayer in Odyssey is buggy and causes memory corruption. If facebook or any other site "accidently" or intentionally played any video, the system should be considered unstable and normal crashes should be disregarded until reproduced without running Odyssey. IMHO.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
That seems to be a peculiar way to find out the size of a file. Besides, you are assuming that the result will fit into 32 bits, whereas the result of (current) DOS calls is 64-bit.
I would suggest something like this (sorry, it's in C):
That seems to be a peculiar way to find out the size of a file.
I would disagree! Apart from the fact that I'm using built-in C functions, rather than AmigaDOS functions, I would say that seeking to the end of the file & then finding the current position is a very COMMON way of finding file sizes on the Amiga, probably since 2.x if not 1.x times
Quote:
Besides, you are assuming that the result will fit into 32 bits, whereas the result of (current) DOS calls is 64-bit.
I'm quite aware of that particular limitation, but the FileLength() function is only there for backwards compatibility with ancient AmigaE programs, and it can't be fixed since the AmigaE didn't even support 64-bit numbers! (PortablE does, but it provides a much better way to handle files.)
Quote:
I would suggest something like this (sorry, it's in C)
Even if I could support 64-bit FileLength(), I still couldn't use your code because it calls AmigaDOS, but the place where FileLength() is defined canNOT access any Amiga librarys. (Well it *could*, but it would cause such problems for PortablE that it doesn't bear thinking about.)