← Back to index

Is there an "offical" place for CTime tool?

Ameen Sayegh
#8939
I tried CTime and it is a very cool tool.

I found a bug when trying to display the stats on a file that contains a single entry, it crashes at line 399.
Is there a place where I can find updates and bug fixes for this tool?
I found this gist: https://gist.github.com/mmozeiko/4972c28be07e2b7c10dc88089eec7083
It is revision 7 (mine from hmh source code is revision 6) but it crashes always, localtime function returns null at line 195.
Does everyone has this bug or is it just me?
ratchetfreak
#8940
that one is forked from: https://gist.github.com/cmuratori/8c909975de4bb071056b4ec1651077e8
Mārtiņš Možeiko
#8941
What OS/compiler you are using?
I have tried that on Windows+msvc2015 and on Linux+gcc/clang and it works for me.
What are you invoking when it crashes? -begin/-end? something else? Are you sure it is localtime that returns NULL which make program to crash? If you are compiling with optimizations then often its tricky to see what place in source code causes the crash.
hugo
#8942
I just tried on Windows/cl.exe and got a "program stopped working" when the ctime file had a single entry and I ran ctime -stats <file>

ctime -csv <file> worked even with a single entry.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
C:\work>del a.time

C:\work>ctime -begin a.time

C:\work>ctime -end a.time
CTIME: 1.621 seconds (a.time)

C:\work>ctime -csv a.time
a.time Timings
ordinal, date, duration, status
0, 2016-10-13 14:40.58, 1.621s, succeeded
Edited by hugo on
Ameen Sayegh
#8943
The code I took from gist (I assume it is yours) was crashing when I ran it to see the stats (localtime returns null).
I investigated the problem, it was checking that the file time is less than some value and it fails.
I realized that I was running -stats using your version of the tool on a file generated by the original version.
The time values generated by the original seems to be much larger than the ones generated by your version.
The original uses win32 function to get the file time in 100-nano seconds while yours is using time function which returns milliseconds.
So you version is actually OK (if you don't care about compatibility).

But yours has the same bug as the original when running -stats on a file with one entry.

However, Both versions (yours and the original) are crashing whenever you invoke -stats on a file that has one entry (after running -begin/-end once):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
    double FirstDayAt = 0;
    double LastDayAt = 0;
    double DaySpan = 0;

    graph TotalGraph = {0};
    graph RecentGraph = {0};

    WithErrors.FastestMs = 0xFFFFFFFF;
    NoErrors.FastestMs = 0xFFFFFFFF;

    // NOTE
    // if this condition is false (when EntryCount is one)
    // FirstDayAt will stay zero
    if(Array.EntryCount >= 2)
    {
        double MilliD = MillisecondDifference(Array.Entries[Array.EntryCount - 1].StartDate, Array.Entries[0].StartDate);
        DaySpanCount = (int unsigned)(MilliD / (1000.0 * 60.0 * 60.0 * 24.0));

        FirstDayAt = (double)DayIndex(Array.Entries[0].StartDate);
        LastDayAt = (double)DayIndex(Array.Entries[Array.EntryCount - 1].StartDate);
        DaySpan = (LastDayAt - FirstDayAt);
    }
    DaySpan += 1;

    for(EntryIndex = 0;
        EntryIndex < Array.EntryCount;
        ++EntryIndex, ++Entry)
    {
        if(Entry->Flags & TFEF_Complete)
        {
            stat_group *Group = (Entry->Flags & TFEF_NoErrors) ? &NoErrors : &WithErrors;

            int unsigned ThisDayIndex = DayIndex(Entry->StartDate);
            if(LastDayIndex != ThisDayIndex)
            {
                LastDayIndex = ThisDayIndex;
                ++DaysWithTimingCount;
            }

            UpdateStatGroup(Group, Entry);
            UpdateStatGroup(&AllStats, Entry);

            AllMs += (double)Entry->MillisecondsElapsed;

            {
                //
                // The GraphIndex is bogus (very large) because FirstDayAt is zero
                // And the crash happens inside UpdateStatGroup
                //
                int GraphIndex = (int)(((double)(ThisDayIndex-FirstDayAt)/DaySpan)*(double)GRAPH_WIDTH);
                UpdateStatGroup(TotalGraph.Buckets + GraphIndex, Entry);
            }

Ameen Sayegh
#8944
@hugo, the code that generates the graphs is the code that is crashing.
I accidentally triggered the bug after I deleted the .ctm file I thought I broke something.
It turns out it is there.
Mārtiņš Možeiko
#8945
Well if original crashes then this is expected in my version. Only thing I changed is code that gets time from system and I/O, so it is cross-platform. I didn't change anything else. And yes, time storage format changed to unify cross-platform code.
Edited by Mārtiņš Možeiko on
Casey Muratori
#8957
There is no official place for the code. It's released into the public domain and so if someone wants to start an officially maintained branch somewhere, go nuts. It sounds like Martins has the most advanced copy so far, so perhaps he should be the owner :)

- Casey
Simon Anciaux
#8960
When I try to compile mmozeiko's ctime.c with VS2012 I get an error:
1
2
3
4
5
6
7
cl ctime.c
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

ctime.c
ctime.c(224) : error C2143: syntax error : missing ';' before 'type'
ctime.c(225) : error C2065: 'ReadSize' : undeclared identifier

Casey's version compiles with not problem.
Mārtiņš Možeiko
#8961
Yeah, I guess C99 is required. Upgrade compiler to VS2013 or VS2015.
Or either rename file to .cpp extension, or use /Tp.
Or rearrange code to have "int ReadSize" variable definition before call to fseek.
Many options :)
Edited by Mārtiņš Možeiko on
Simon Anciaux
#8965
So that's what that error means. Now I feel stupid. Thanks
Mārtiņš Možeiko
#8969
C89 has a strict requirement where variable definitions need to be first statements in a scope.

So this code is OK:
1
2
3
4
5
6
{
  int i = 42;
  float* p;
  foobar();
  ...
}

But this code is NOT ok:
1
2
3
4
5
6
{
  int i = 42;
  foobar();
  float* p; // this cannot be after foobar() statement
  ...
}

Edited by Mārtiņš Možeiko on
Simon Anciaux
#8970
Yes, I just didn't make the connection between that and the error message.
Reply to Thread
← Back to index