|
i have program and i believe that it works fine under debug mode, the program does not have memory leak or any other leaks, what happened that i switched to release mode, and somehow i see weird problems showing up
1- the free and calloc work fine but sometime the program crash tells me a heap corruption issue, where as each pointer is checked, when i look at task manger the program works with regular around 10mg, but somehow it gets increased to 1gb1! and this happens after the crash
2- when i use openfile function the api one, it works fine then somehow the window gets busted? such lists or prarts from openfile disperse?
i do not believe it's related to uninitialized data cuz all the variables are initialized even the pointers
i did check with all leak tools and non of them show memory leak, i did see access violation but it's also handled with exceptions
i do not understand why it's still crashing whereas i checked everything? any ideas or similar issues?
|
|
|
|
|
Given how little you have told us about how you handle the data or even what the program does, it's really hard for us to say what is wrong.
It is possible that you simply keep creating objects and adding them to a list, which has functionality for deleting all the objects when the list is destroyed. If that is the case, you don't have memory leaks, you just don't release memory until the program shuts down. You mention that you don't see failures in the debug build, but that could be because the release build is able to allocate objects at a much higher rate than the debug build.
Like I said, this is just one possibility.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
thanks for your time,
which has functionality for deleting all the objects when the list is destroyed. If that is the case, you don't have memory leaks, you just don't release memory until the program shuts down
can you explain what does release memory mean? i know that free it does release the memory, and yes i do have one array it's 2d char pointer array...
|
|
|
|
|
Deleting allocated objects is the same as releasing the memory used for the objects. It's just a different way of saying the same thing.
Alright, so you have an array. What is the purpose of that array? Do you expand it array with data you read from somewhere?
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
yes using realloc, and i do check the pointers each time, and i do add 1 for the null in the end? but it does not show any error, actually i have feelings that this 2d array makes so many issues
|
|
|
|
|
Memory leaks did not lead to crashes. They just block memory. Your program corrupts the heap and generates access violations. Handling access violations by exceptions does not help. When they occur, your program is in an undefined state. So you must find the source code that corrupts the heap and generates the access violation.
Common sources are invalid pointers or array indexes and don't checking error returns. You can try to execute only portions of your program and check if corruptions occur to narrow down the source code that contains the error. Best practice to avoid such errors is using asserts in debug build that check all function parameters and return values.
|
|
|
|
|
thanks for your time, gonna try assert
|
|
|
|
|
Note that you can change the options for your release build to also create debug information. That way you can debug your release build and thus analyze what's happening. The only difference to your "true release" build will be performance - but your problem doesn't sound like it's caused by a program that is running "too fast".
"release" and "debug" are just terms commonly used by IDEs to declare a set of build options most suitable for debugging or releasing an application, respectively. But you can change these options or create a third set in any way you like.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
thanks for your time, i already done that 
|
|
|
|
|
|
|
jone20132 wrote: i did see access violation but it's also handled with exceptions
A memory access violation? If so then you do not "handle" that with exceptions.
|
|
|
|
|
thanks, i do "handle" the exceptions as i mentioned before, the reason why i saw the access violation that i turned them on....
|
|
|
|
|
I have 3 files (bitmap files) which has the modified date:
file1.bmp ------- 9/19/2013 01:02 PM
file2.bmp ------- 9/20/2013 07:57 PM
file3.bmp ------- 11/21/2013 10:39 AM
that is what windows explorer show me in XP ... ok, but in Win7, windows explorer show
file1.bmp ------- 9/19/2013 02:02 PM (+1 hour)
file2.bmp ------- 9/20/2013 08:57 PM (+1 hour)
file3.bmp ------- 11/21/2013 10:39 AM
The first two of them has the date before DST (October 2013), and last one after DST (October 2013), but this issue exist only in Win7.
The issue come when I try to get file modified datetime, with follow code:
CFileStatus status;
CFile::GetStatus(sPath, status);
CTime time(status.m_mtime);
TRACE("%d:%d - %s\n", time.GetHour(), time.GetMinute(), sPath);
which show me the modified dates like XP does:
13:2 - file1.bmp
7:57 - file2.bmp
10:39 - file3.bmp
but if I run this code on Win7, I have a problem with first two files: show me modified date less by one hour than windows explorer does (as I said in Win7) .... how can I fix this issue ? Does anyone faced with this kind of problem ?
Thank you.
|
|
|
|
|
I'm not sure what this has to do with C++, but you should check your regional settings for date and time and timezone in both systems.
Veni, vidi, abiit domum
|
|
|
|
|
The CTime class represents dates and times in UTC (the filetime stored on the disk is also UTC). If you want to show local times you must convert the timestamp. This can be done using localtime() and SystemTimeToTzSpecificLocalTime(). Depending on the timezone, the times shown by the Explorer of different Windows versions may be not identical. When using an old OS version without updated DST information and the DST switch dates has been changed, it may show wrong values.
EDIT: Quote: the filetime stored on the disk is also UTC
is wrong and must be: 'the filetime stored on NTFS partitions is also UTC'.
FAT uses local times. See also File Times[^] in the MSDN.
|
|
|
|
|
Unfortunately, I didn't succeeded, using below code:
CTime time2(status.m_mtime);
time_t tt = time2.GetTime();
struct tm* timeinfo;
timeinfo = localtime(&tt);
time_t tt2 = mktime(timeinfo);
CTime time3(tt2);
SYSTEMTIME stUTC, stLocal;
time3.GetAsSystemTime(stUTC);
TIME_ZONE_INFORMATION tzi;
GetTimeZoneInformation(&tzi);
SystemTimeToTzSpecificLocalTime(&tzi, &stUTC, &stLocal);
CTime time4(stLocal);
TRACE("%d:%d\n", time4.GetHour(), time4.GetMinute());
the dates less than october 2013 is incremented by 3 hours, and date greater than october 2013 is incremented by 2 ... according by first post:
file1.bmp --- 16:2
file2.bmp --- 10:57
file3.bmp --- 12:39
I did something wrong ?
Last edit: the file system is NTFS.
modified 8-Jan-14 4:15am.
|
|
|
|
|
Flaviu2 wrote: dates less than october 2013 is incremented by 3 hours, and date greater than october 2013 is incremented by 2
That sounds correct, the ones before October have daylight savings added to them. As I said before, you should check your regional timezone sttings.
Veni, vidi, abiit domum
|
|
|
|
|
The dates before october have DST enabled and so an additional hour is expected. The offset without DST is 2 hours. So your time zone is EET.
The trace output from your previous post corresponds to:
2013-09-19 16:02 EEST
2013-09-20 10:57 EEST
2013-11-21 12:39 EET
Converting these to UTC/Zulu matches the trace output of your initial post:
2013-09-19 13:02 Z
2013-09-20 07:57 Z
2013-11-21 10:39 Z
The dates shown by Windows XP from your initial post:
file1.bmp ------- 9/19/2013 01:02 PM
file2.bmp ------- 9/20/2013 07:57 PM
file3.bmp ------- 11/21/2013 10:39 AM
This is identical to UTC (assuming 07:57 PM should be AM). So it seems that your Windows XP is configured to use UTC/Z (which does not use DST).
The dates shown by Windows 7 from your initial post:
file1.bmp ------- 9/19/2013 02:02 PM (+1 hour)
file2.bmp ------- 9/20/2013 08:57 PM (+1 hour)
file3.bmp ------- 11/21/2013 10:39 AM
It seems that your Windows 7 is configured to use GMT which uses DST.
So all dates match when using the above time zones (and assuming that the PM of file2 should be AM).
|
|
|
|
|
Well, I am working on Win7, which have Automatically adjust clock for Daylight Saving Time option checked, file system is NTFS. Here, I read (in windows explorer):
file1.bmp ------- 9/19/2013 02:02 PM (+1 hour)
file2.bmp ------- 9/20/2013 08:57 PM (+1 hour)
file3.bmp ------- 11/21/2013 10:39 AM
And I have an virtual machine, where I had installed an XP SP3 (for testing purpose). This system also have Automatically adjust clock for daylight saving changes option checked, and you are right, I read follow values (in windows explorer):
file1.bmp ------- 9/19/2013 01:02 PM
file2.bmp ------- 9/20/2013 07:57 PM
file3.bmp ------- 11/21/2013 10:39 AM
The file system is NTFS as well.
I have to digg in ...
|
|
|
|
|
It would be interesting to know which time zone is set in both (right click on time in task bar, change date/time, change time zone). On my German Windows 7 and the virtual XP3 there are multiple entries for UTC/GMT: With city names and one labelled 'Universal Time'. The last one is plain UTC (called Zulu) without DST. It seems that your XP has this set.
|
|
|
|
|
On my Window 7 I have time zone:
(UTC + 2) Athens, Bucharest, Istanbul
Automatically adjust clock for Daylight Saving Time checked
On my virtual XP SP3 I have:
(GMT + 2) Bucharest
Automatically adjust clock for daylight saving clock checked
In both of them I have the same hour (2:43 PM is now) as well ...
|
|
|
|
|
That looks OK. But for some reason your Explorer uses different time zones (GMT/UTC rather than EET of the systems). What if you create a new file now? According to your previous posts, the Explorers would show a two hour offset.
But that should not be the case (from How to handle dates and times that include DST[^]):
Quote: For example, Windows Explorer applies the time zone and the DST setting to the UTC timestamp before it displays dates and times for files in a Windows NT File System (NTFS) directory.
I suggest to read the full text. It contains a block that explains that the Explorer may show different times.
Reading the above, there is a possible reason for your observations:
XP uses the current time zone and DST state to display the time stamp. So there is no additional hour for dates with DST because DST is not active today. With Vista, dynamic time zones has been introduced. When the Explorer of Windows 7 uses them, it may show the time stamp with DST offset.
|
|
|
|
|
I finally made it:
CFileStatus status;
CFile::GetStatus(sPath, status);
SYSTEMTIME systimeFile;
status.m_mtime.GetAsSystemTime(systimeFile);
COleDateTime dt(systimeFile);
if(m_bGreaterThanXP)
{
TIME_ZONE_INFORMATION tzi;
DWORD dwTZI = GetTimeZoneInformation(&tzi);
if(dwTZI == TIME_ZONE_ID_STANDARD || dwTZI == TIME_ZONE_ID_DAYLIGHT)
{
SYSTEMTIME stLocal;
SystemTimeToTzSpecificLocalTime(&tzi, &systimeFile, &stLocal);
COleDateTime dtLocal(stLocal);
COleDateTimeSpan span(0, 0, (int)tzi.Bias, 0);
dt = dtLocal + span;
}
}
CString sTime = dt.Format(VAR_TIMEVALUEONLY);
where bGreaterThanXP is retrieved like that:
m_bGreaterThanXP = FALSE;
OSVERSIONINFO osvi;
ZeroMemory(&osvi, sizeof(OSVERSIONINFO));
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
GetVersionEx(&osvi);
if(osvi.dwMajorVersion > 5)
m_bGreaterThanXP = TRUE;
hope to help on somebody ... thank you all !
P.S. Please correct me if I did something wrong.
modified 9-Jan-14 8:28am.
|
|
|
|
|
Fine that you have solved it and thank you for the feedback.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
