Changeset a9fe533 in rtems-testing


Ignore:
Timestamp:
Jul 21, 2009, 3:42:48 PM (10 years ago)
Author:
Joel Sherrill <joel.sherrill@…>
Branches:
4.11, 8895273c193787f84c4585a10f6d6aceb3b25dc4
Children:
1ba71d7
Parents:
3c390fc
Message:

2009-07-21 Joel Sherrill <joel.sherrill@…>

  • Explanations.txt: Multiple updates based on changes from myself and Santosh.
Location:
rtems-coverage
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • rtems-coverage/ChangeLog

    r3c390fc ra9fe533  
     12009-07-21      Joel Sherrill <joel.sherrill@OARcorp.com>
     2
     3        * Explanations.txt: Multiple updates based on changes from myself and
     4        Santosh.
     5
    162009-07-20      Joel Sherrill <joel.sherrill@OARcorp.com>
    27
  • rtems-coverage/Explanations.txt

    r3c390fc ra9fe533  
    55+++
    66
    7 setcancelstate.c:53
    8 Simple Test Case
    9 This is a missing error case.
    10 +++
    11 
    12 /opt/rtems-4.10/lib/gcc/sparc-rtems4.10/4.4.0/../../../../sparc-rtems4.10/include/pthread.h:280
    13 Simple Test Case
    14 Really setcancelstate.c:65 and setcanceltype.c:65. Apparently we don't
    15 hit the end of this if which sets cancel = true.
    16 
    17 Could possibly share cancellation evaluatation code with setcanceltype.c
    18 and setcancelstate.c.
    19 +++
    20 
    21 /opt/rtems-4.10/lib/gcc/sparc-rtems4.10/4.4.0/../../../../sparc-rtems4.10/include/pthread.h:281
    22 Simple Test Case
    23 Really setcancelstate.c:65 and setcanceltype.c:65. Apparently we don't
    24 hit the end of this if which sets cancel = true.
    25 
    26 Could possibly share cancellation evaluatation code with setcanceltype.c
    27 and setcancelstate.c.
    28 +++
    29 
    30 setcancelstate.c:69
    31 Simple Test Case
    32 This is actually two cases because of how the exit code it generated.
    33 
    34 One is really line 69.  We do not hit the cancellation requested but
    35 deferred case where we will need to run the handners.
    36 
     7setcancelstate.c:50
     8Simple Test Case
     9A very simple test case where a NULL pointer to the oldstate is passed in.
     10+++
     11
     12setcancelstate.c:65
     13Simple Test Case
    3714The other is a branch from line 50 for !oldstate.
    38 
    39 Could possibly share cancellation evaluatation code with setcanceltype.c.
    40 +++
    41 
    42 setcanceltype.c:53
    43 Simple Test Case
    44 This is a missing error case.
    45 +++
    46 
    47 setcanceltype.c:68
    48 Simple Test Case
    49 This is actually two cases because of how the exit code it generated.
    50 
    51 One is really line 68.  We do not hit the cancellation requested but
    52 deferred case where we will need to run the handners.
    53 
    54 The other is a branch from line 50 for !oldtype.
    55 
    56 Could possibly share cancellation evaluatation code with setcanceltype.c.
    57 +++
    58 
    59 condwaitsupp.c:59
    60 Simple Test Case
    61 This code is either easy or impossible to hit.  The condition variable is
    62 associated with a mutex but it is not the one we are specifying.  Probably
    63 will require having two threads wait on the same condition variable but
    64 each uses a different mutex.
     15+++
     16
     17setcanceltype.c:50
     18Simple Test Case
     19This is a case of passing in a bad cancelation type.
     20+++
     21
     22setcanceltype.c:64
     23Simple Test Case
     24The other is a branch from line 50 for bad type.
    6525+++
    6626
     
    174134Interrupt Synchronization
    175135This is a timeout while blocking waiting for an event receive with timeout.
    176 +++
    177 
    178 ratemonperiod.c:310
    179 Interrupt Synchronization
    180 period must expire while attempting to block
    181 +++
    182 
    183 watchdog.inl:129
    184 Interrupt Synchronization
    185 
    186 period expires while blocking (ratemontimeout.c:66)
    187136+++
    188137
     
    306255+++
    307256
     257threadqenqueuepriority.c:99
     258Interrupt Synchronization
     259This case is where we are iterating to enqueue a thread into a priority
     260based thread queue but the thread we are looking at gets unblocked when
     261we flash interrupts.  It is NOT the thread we are unblocking.
     262Forward Search case.
     263
     264NOTE: Do not remove this from explanations.
     265+++
     266
    308267threadqenqueuepriority.c:146
    309268Interrupt Synchronization
     
    312271we flash interrupts.  It is NOT the thread we are unblocking.
    313272Reverse Search case.
     273
     274NOTE: Do not remove this from explanations.
    314275+++
    315276
Note: See TracChangeset for help on using the changeset viewer.