Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
175 user(s) are online (160 user(s) are browsing Forums)

Members: 3
Guests: 172

NinjaCyborg, amigait, VooDoo, more...

Support us!

Headlines

 
  Register To Post  

(maybe solved) Mysterious mem corruption from some standard C code???
Home away from home
Home away from home


See User information
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:

Quote:
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>

long FileLength(char* path) {
long size;

FILE* stream = fopen(path ,"rb");
if( stream== NULL) {
size = -1;
} else {
fseek(stream, 0, SEEK_END);
size = ftell(stream);
fclose(stream);
}
return size;
}

int main() {
//char* path = "T:usb.log";
char* path = "RAM:does_not_exist";
printf("Size of '%s' is %ld bytes.\n", path, FileLength(path));
return 0;
}


(sorry for the lack of indenting, but I couldn't work out how to preserve it. Amigans.net seems to lack support for HTML tags and [pre].)

I don't normally write C code directly, so perhaps I overlooked something??


Edited by ChrisH on 2015/10/5 14:23:33
Author of the PortablE programming language.
Go to top
Re: Mysterious mem corruption from some standard C code???
Just popping in
Just popping in


See User information
@ChrisH
Quote:
it was being called on two paths


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?

Maintainer and developer for Jamiga2 - Java for Amiga
Go to top
Re: Mysterious mem corruption from some standard C code???
Home away from home
Home away from home


See User information
@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...)

Author of the PortablE programming language.
Go to top
Re: Mysterious mem corruption from some standard C code???
Just popping in
Just popping in


See User information
@ChrisH

I am not a C specialist as I prefer using C++.

I read the manual here http://www.gnu.org/software/libc/manu ... ode/File-Positioning.html

Here some hints.
The fseeko and ftello are preferable. I will add you shoud use fseeko64() and ftello64().

I will change the code by using :

int error = fseeko64(stream, 0, SEEK_END);

to test if there is some problem with fseek because error must be 0.

I will test with some file in the same direcrory to verifiy if the probem is not related to RAM:

Let me know if no when you will find the error.
So, le us learn some more.




Since a lot of months without an amiga to love, I was lost.
Now I feel happiness again with a Sam Flex 800 .
Go to top
Re: Mysterious mem corruption from some standard C code???
Just popping in
Just popping in


See User information
@ChrisH

Ah, ok, I missunderstood then.

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.)

Maintainer and developer for Jamiga2 - Java for Amiga
Go to top
Re: Mysterious mem corruption from some standard C code???
Home away from home
Home away from home


See User information
@jaokim Quote:
One possibility might be that the code you think is at fault (FileLength) isn't.

Well yes, that's always possible when you have memory corruption, but currently all evidence points to FileLength() being the cause...

(snip)


Edited by ChrisH on 2015/10/4 20:33:28
Author of the PortablE programming language.
Go to top
Re: Mysterious mem corruption from some standard C code???
Just popping in
Just popping in


See User information
Do you get a stack trace when it crashes?

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.

Maintainer and developer for Jamiga2 - Java for Amiga
Go to top
Re: Mysterious mem corruption from some standard C code???
Home away from home
Home away from home


See User information
@jaokim Quote:
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
Author of the PortablE programming language.
Go to top
Re: (maybe solved) Mysterious mem corruption from some standard C code???
Quite a regular
Quite a regular


See User information
@ChrisH

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++
Go to top
Re: (maybe solved) Mysterious mem corruption from some standard C code???
Home away from home
Home away from home


See User information
@Deniil Quote:
So you had this problem for a long time while never rebooting the machine?

No. I have Odyssey behave like Firefox, by which I mean it re-opens the tabs I had opened last time.

Author of the PortablE programming language.
Go to top
Re: (maybe solved) Mysterious mem corruption from some standard C code???
Quite a regular
Quite a regular


See User information
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):

uint64 FileLength (char *path)
{
BPTR file = ZERO;
uint64 fileLength = 0;

file = IDOS->Open (path);
if (file != ZERO)
{
fileLength = IDOS->GetFileSize (file);
IDOS->Close (file);
}
return fileLength;
}



cheers
tony
Go to top
Re: (maybe solved) Mysterious mem corruption from some standard C code???
Home away from home
Home away from home


See User information
@tonyw Quote:
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.)

Author of the PortablE programming language.
Go to top
Re: (maybe solved) Mysterious mem corruption from some standard C code???
Home away from home
Home away from home


See User information
@ChrisH

(f)stat

Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project