source: rtems-testing/rtems-coverage/Explanations.txt @ da21ccf

4.11
Last change on this file since da21ccf was da21ccf, checked in by Joel Sherrill <joel.sherrill@…>, on Jul 20, 2009 at 3:44:02 PM

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

  • Explanations.txt: Remove explanations for cases covered by recent test additions.
  • Property mode set to 100644
File size: 9.9 KB
Line 
1
2cancelrun.c:44
3Simple Test Case
4This is simply an untested normal use of pthread cancellation handlers.
5+++
6
7setcancelstate.c:53
8Simple Test Case
9This 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
13Simple Test Case
14Really setcancelstate.c:65 and setcanceltype.c:65. Apparently we don't
15hit the end of this if which sets cancel = true.
16
17Could possibly share cancellation evaluatation code with setcanceltype.c
18and setcancelstate.c.
19+++
20
21/opt/rtems-4.10/lib/gcc/sparc-rtems4.10/4.4.0/../../../../sparc-rtems4.10/include/pthread.h:281
22Simple Test Case
23Really setcancelstate.c:65 and setcanceltype.c:65. Apparently we don't
24hit the end of this if which sets cancel = true.
25
26Could possibly share cancellation evaluatation code with setcanceltype.c
27and setcancelstate.c.
28+++
29
30setcancelstate.c:69
31Simple Test Case
32This is actually two cases because of how the exit code it generated.
33
34One is really line 69.  We do not hit the cancellation requested but
35deferred case where we will need to run the handners.
36
37The other is a branch from line 50 for !oldstate.
38
39Could possibly share cancellation evaluatation code with setcanceltype.c.
40+++
41
42setcanceltype.c:53
43Simple Test Case
44This is a missing error case.
45+++
46
47setcanceltype.c:68
48Simple Test Case
49This is actually two cases because of how the exit code it generated.
50
51One is really line 68.  We do not hit the cancellation requested but
52deferred case where we will need to run the handners.
53
54The other is a branch from line 50 for !oldtype.
55
56Could possibly share cancellation evaluatation code with setcanceltype.c.
57+++
58
59condwaitsupp.c:59
60Simple Test Case
61This code is either easy or impossible to hit.  The condition variable is
62associated with a mutex but it is not the one we are specifying.  Probably
63will require having two threads wait on the same condition variable but
64each uses a different mutex.
65+++
66
67keycreate.c:80
68Simple Test Case
69Run out of memory while allocating key memory.
70+++
71
72keycreate.c:82
73Simple Test Case
74Run out of memory while allocating key memory.
75+++
76
77keyrundestructors.c:62
78Simple Test Case
79Restructure the code into 3 separate tests with continues and see which
80cases are really not hit. Then trigger the cases.
81+++
82
83keyrundestructors.c:64
84Simple Test Case
85Probably Iterating over a NULL value.
86+++
87
88mqueuecreatesupp.c:101
89Simple Test Case
90This is running out of message queues.
91+++
92
93mqueue.inl:60
94Simple Test Case
95Really two cases.
96
97mqueuecreatesupp.c:119 is running out of memory allocating the name.
98
99mqueuecreatesupp.c:142 is failing the core message queue initialize.
100Probably running out of memory while allocating the buffer memory.
101+++
102
103mqueuedeletesupp.c:57
104Simple Test Case
105This is a case of deleting a named message queue.
106+++
107
108mqueuetimedreceive.c:71
109Simple Test Case or Restructure switch to if
110Given that this is 3 instructions, it is probably a missed test case.
111+++
112
113mqueuetimedsend.c:71
114Simple Test Case or Restructure switch to if
115Given that this is 3 instructions, it is probably a missed test case.
116+++
117
118psignal.c:148
119?
120This appears to be a case of not exercising the loop fully.
121+++
122
123mutexinit.c:165
124Simple Test Case
125This code is not initializing a specific type of mutex -- probably recursive.
126+++
127
128mutextimedlock.c:59
129Simple Test Case (or Restructure)
130Looks like another undertested timeout path.
131+++
132
133pthread.c:83
134Simple Test Case
135This is a case of the sporadic scheduling budget being less than one clock
136tick in length.
137+++
138
139pthread.c:97
140Simple Test Case
141This is a case of the sporadic scheduling replinish period being less
142than one clock tick in length.
143+++
144
145pthread.c:129
146Simple Test Case
147This is a case of attempting to change the priority of a thread
148holding resources at the end of the sporadic server period.
149+++
150
151pthread.c:130
152Simple Test Case
153It looks like we don't have a good sporadic server test.  This is
154the normal case of changin priority.
155+++
156
157eventsurrender.c:81
158Interrupt Synchronization
159This is executed when events are sent to the currently executing thread
160while it is in the process of blocking.  I think sp39 or sp41 relates to
161this but may not be hitting the correct combination of timed out or Any/All.
162
163NOTE: This is hit sometimes so maybe the tests need tuning a bit.
164+++
165
166eventsurrender.c:82
167Interrupt Synchronization
168This is somehow related to eventsurrender.c:81 but the range is
169disconnected and I do not see why with certainty.  This could be
170when a timeout occurs while we are blocking on an event receive.
171+++
172
173eventtimeout.c:78
174Interrupt Synchronization
175This is a timeout while blocking waiting for an event receive with timeout.
176+++
177
178ratemonperiod.c:310
179Interrupt Synchronization
180period must expire while attempting to block
181+++
182
183watchdog.inl:129
184Interrupt Synchronization
185
186period expires while blocking (ratemontimeout.c:66)
187+++
188
189timerreset.c:60
190Simple Test Case
191new error case
192+++
193
194timerserverfireafter.c:80
195Interrupt Synchronization
196timer must be inserted by an ISR while we are inserting it
197+++
198
199coremutex.inl:171
200Simple Test Case
201pri ceiling, acquire when pri = ceiling
202+++
203
204coremutexsurrender.c:188
205Simple Test Case
206There must not be a test of a priority ceiling mutex getting released
207which results in a thread being unblocked and the UNBLOCKED thread's
208priority being elevated.
209+++
210
211debug.c:63
212Simple Test Case
213need a test
214+++
215
216heapresizeblock.c:158
217Simple Test Case
218looks like shrink block but so small the unused area gets freed
219+++
220
221heapallocatealigned.c:223
222Simple Test Case
223This looks like a case where the allocate aligned simply fails to get any
224memory.
225+++
226
227heapgetinfo.c:70
228Simple Test Case
229The heap is corrupted.  The block's size does not match the next block's
230previous size backwards link.  This may make sense to add to the
231Heap Walk test.
232+++
233
234heapresizeblock.c:144
235Simple Test Case
236Shrink a heap block with the resize.  The block after this one in memory
237must be free so the memory free by the shrinking will be merged with that
238already free block.
239+++
240
241heapwalk.c:144
242Test Case
243We are not hitting the case for having an error at this place.  I would have
244thought that making do_dump 0 and running all the cases is enough.  Maybe the
245test does not do what I think and this is why this case is missed.
246+++
247
248regionresizesegment.c:83
249Simple Test Case
250Apparently we do not have a test case where there is memory freed by the
251resize effort is sufficient to result in needing to look to see if we
252can unblock any tasks.
253+++
254
255ioregisterdriver.c:61
256Simple Test Case
257documented (not implemented) in sp40.  Fill up the driver table and
258register another driver.
259+++
260
261ioregisterdriver.c:71
262Simple Test Case
263documented (not implemented) in sp40.  Fill up the driver table and
264register another driver.  All of the cases in this file are probably
265related and will take attention when working on them to be sure I
266have explained them correctly.  The assembly is just hard to follow.
267+++
268
269ioregisterdriver.c:84
270Simple Test Case
271if reachable
272+++
273
274timerfireafter.c:76
275Interrupt Synchronization
276timer must be inserted or state altered by ISR
277+++
278
279thread.inl:230
280SHOULD BE COVERED
281sp39 should cover this .. timeout while blocking (eventtimeout.c:71)
282+++
283
284threadinitialize.c:91
285Simple Test Case
286This is for the case where the application uses the POSIX
287thread stack address attribute.
288
289NOTE: Code Should be Configured on POSIX
290+++
291
292threadinitialize.c:148
293Medium Test Case
294The allocation of the user extension data area must fail.  The failure should
295occur during the create case of an Floating Point enabled task.
296
297Since the stack is allocated first, it should be possible to have a test
298with a fair (16-32?) number of user extensions configured and then
299create a thread with increasingly larger stack until this case is hit.
300+++
301
302iterateoverthreads.c:42
303Simple Test Case
304Need to call iterate over threads in a test where there is an API configured
305which does not have threads.  Should be easy to add to sp54.
306+++
307
308threadqenqueuepriority.c:146
309Interrupt Synchronization
310This case is where we are iterating to enqueue a thread into a priority
311based thread queue but the thread we are looking at gets unblocked when
312we flash interrupts.  It is NOT the thread we are unblocking.
313Reverse Search case.
314+++
315
316chain.inl:300
317Simple Test Case or Minor Code Rework
318This inlined case appears multiple times.
319
320_POSIX_signals_Clear_signals:71 chain get when empty
321_Watchdog_Adjust_to_chain may also have one.
322
323This is actually part of multiple paths and it appears to be
324dead because there is an explicit check for the chain being empty on the
325loop but a call to _Chain_Get_unprotected also checks for empty.  So we never
326get a case there _Chain_Get_unprotected returns NULL.  Can usually be
327addressed by reworking the loop in some way.
328+++
329
330threadqprocesstimeout.c:46
331Interrupt Synchronization
332This is processing a timeout on a thread that times out while it is in the
333process of blocking on a thread queue.
334+++
335
336threadqprocesstimeout.c:54
337Interrupt Synchronization
338This is the return code from threadqprocesstimeout.c:46.  Perhaps
339restructuring this code will make it easier to combine these.  Hit the
340normal path first and return.  Then fall into the unusual synchronization
341path.
342+++
343
344watchdoginsert.c:52
345Interrupt Synchronization
346This is when a higher priority interrupt inserts a timer while a lower
347priority interrupt is inserting one.
348+++
349
350watchdogremove.c:41
351Interrupt Synchronization
352Remove a watchdog while it is being inserted.
353+++
354
355watchdogremove.c:64
356Interrupt Synchronization
357Remove a watchdog while it is being removed.
358+++
359
360killinfo.c:152
361Simple Test Case
362Yet another path through here.
363+++
364
365killinfo.c:212
366Simple Test Case
367Multiple threads interested but find high priority one first.
368+++
369
370killinfo.c:247
371Simple Test Case
372Yet another path through here.
373+++
374
375killinfo.c:339
376Simple Test Case
377This is an error case where we can't allocate another signinfo structure.
378+++
379
380timerinserthelper.c:45
381Interrupt Synchronization
382We just removed the timer but the watchdog timer is being inserted by
383a higher priority interrupt.  We may be able to get this to happen
384with Classic API Timers.  But that is unclear.
385+++
Note: See TracBrowser for help on using the repository browser.