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

4.11
Last change on this file since a431462 was a431462, checked in by Joel Sherrill <joel.sherrill@…>, on Jul 9, 2009 at 8:15:19 PM

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

  • Explanations.txt: Added sp59 to test path through _Thread_queue_First_priority where the task's priority was in the bottom 1/4 of the range.
  • Property mode set to 100644
File size: 11.4 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
67condget.c:44
68Simple Test Case
69I think this is running out of condition variables while using automatic
70allocation.
71+++
72
73keycreate.c:80
74Simple Test Case
75Run out of memory while allocating key memory.
76+++
77
78keycreate.c:82
79Simple Test Case
80Run out of memory while allocating key memory.
81+++
82
83keyrundestructors.c:62
84Simple Test Case
85Restructure the code into 3 separate tests with continues and see which
86cases are really not hit. Then trigger the cases.
87+++
88
89keyrundestructors.c:64
90Simple Test Case
91Probably Iterating over a NULL value.
92+++
93
94mqueuecreatesupp.c:101
95Simple Test Case
96This is running out of message queues.
97+++
98
99mqueue.inl:60
100Simple Test Case
101Really two cases.
102
103mqueuecreatesupp.c:119 is running out of memory allocating the name.
104
105mqueuecreatesupp.c:142 is failing the core message queue initialize.
106Probably running out of memory while allocating the buffer memory.
107+++
108
109mqueuedeletesupp.c:57
110Simple Test Case
111This is a case of deleting a named message queue.
112+++
113
114mqueuetimedreceive.c:71
115Simple Test Case or Restructure switch to if
116Given that this is 3 instructions, it is probably a missed test case.
117+++
118
119mqueuetimedsend.c:71
120Simple Test Case or Restructure switch to if
121Given that this is 3 instructions, it is probably a missed test case.
122+++
123
124psignal.c:148
125?
126This appears to be a case of not exercising the loop fully.
127+++
128
129mutexinit.c:165
130Simple Test Case
131This code is not initializing a specific type of mutex -- probably recursive.
132+++
133
134mutextimedlock.c:59
135Simple Test Case (or Restructure)
136Looks like another undertested timeout path.
137+++
138
139pthread.c:83
140Simple Test Case
141This is a case of the sporadic scheduling budget being less than one clock
142tick in length.
143+++
144
145pthread.c:97
146Simple Test Case
147This is a case of the sporadic scheduling replinish period being less
148than one clock tick in length.
149+++
150
151pthread.c:129
152Simple Test Case
153This is a case of attempting to change the priority of a thread
154holding resources at the end of the sporadic server period.
155+++
156
157pthread.c:130
158Simple Test Case
159It looks like we don't have a good sporadic server test.  This is
160the normal case of changin priority.
161+++
162
163eventsurrender.c:81
164Interrupt Synchronization
165This is executed when events are sent to the currently executing thread
166while it is in the process of blocking.  I think sp39 or sp41 relates to
167this but may not be hitting the correct combination of timed out or Any/All.
168
169NOTE: This is hit sometimes so maybe the tests need tuning a bit.
170+++
171
172eventsurrender.c:82
173Interrupt Synchronization
174This is somehow related to eventsurrender.c:81 but the range is
175disconnected and I do not see why with certainty.  This could be
176when a timeout occurs while we are blocking on an event receive.
177+++
178
179eventtimeout.c:78
180Interrupt Synchronization
181This is a timeout while blocking waiting for an event receive with timeout.
182+++
183
184ratemontimeout.c:61
185Simple Test Case
186period times out but thread is blocked on another period?
187+++
188
189ratemonperiod.c:310
190Interrupt Synchronization
191period must expire while attempting to block
192+++
193
194watchdog.inl:129
195Interrupt Synchronization
196
197period expires while blocking (ratemontimeout.c:66)
198+++
199
200timerreset.c:60
201Simple Test Case
202new error case
203+++
204
205timerserverfireafter.c:80
206Interrupt Synchronization
207timer must be inserted by an ISR while we are inserting it
208+++
209
210coremutex.inl:171
211Simple Test Case
212pri ceiling, acquire when pri = ceiling
213+++
214
215coremutexsurrender.c:188
216Simple Test Case
217There must not be a test of a priority ceiling mutex getting released
218which results in a thread being unblocked and the UNBLOCKED thread's
219priority being elevated.
220+++
221
222corespinlockwait.c:69
223Simple Test Case
224The spinlock is not available and the caller is not willing to wait.
225Requires a test of pthread_spin_trylock.
226+++
227
228corespinlockrelease.c:59
229Simple Test Case
230Attempt to release a locked spinlock from a thread that is not the one
231which locked it.
232+++
233
234debug.c:63
235Simple Test Case
236need a test
237+++
238
239heapresizeblock.c:158
240Simple Test Case
241looks like shrink block but so small the unused area gets freed
242+++
243
244heapallocatealigned.c:223
245Simple Test Case
246This looks like a case where the allocate aligned simply fails to get any
247memory.
248+++
249
250heapgetinfo.c:70
251Simple Test Case
252The heap is corrupted.  The block's size does not match the next block's
253previous size backwards link.  This may make sense to add to the
254Heap Walk test.
255+++
256
257heapresizeblock.c:144
258Simple Test Case
259Shrink a heap block with the resize.  The block after this one in memory
260must be free so the memory free by the shrinking will be merged with that
261already free block.
262+++
263
264heapwalk.c:144
265Test Case
266We are not hitting the case for having an error at this place.  I would have
267thought that making do_dump 0 and running all the cases is enough.  Maybe the
268test does not do what I think and this is why this case is missed.
269+++
270
271regionresizesegment.c:83
272Simple Test Case
273Apparently we do not have a test case where there is memory freed by the
274resize effort is sufficient to result in needing to look to see if we
275can unblock any tasks.
276+++
277
278ioregisterdriver.c:61
279Simple Test Case
280documented (not implemented) in sp40.  Fill up the driver table and
281register another driver.
282+++
283
284ioregisterdriver.c:71
285Simple Test Case
286documented (not implemented) in sp40.  Fill up the driver table and
287register another driver.  All of the cases in this file are probably
288related and will take attention when working on them to be sure I
289have explained them correctly.  The assembly is just hard to follow.
290+++
291
292ioregisterdriver.c:84
293Simple Test Case
294if reachable
295+++
296
297dpmemcreate.c:87
298Simple Test Case
299need invalid address of return id
300+++
301
302timerfireafter.c:76
303Interrupt Synchronization
304timer must be inserted or state altered by ISR
305+++
306
307thread.inl:230
308SHOULD BE COVERED
309sp39 should cover this .. timeout while blocking (eventtimeout.c:71)
310+++
311
312thread.inl:47
313Simple Test Case
314(sys state trickery) shutdown while in shutdown state
315+++
316
317threadinitialize.c:91
318Simple Test Case
319This is for the case where the application uses the POSIX
320thread stack address attribute.
321
322NOTE: Code Should be Configured on POSIX
323+++
324
325threadinitialize.c:148
326Medium Test Case
327The allocation of the user extension data area must fail.  The failure should
328occur during the create case of an Floating Point enabled task.
329
330Since the stack is allocated first, it should be possible to have a test
331with a fair (16-32?) number of user extensions configured and then
332create a thread with increasingly larger stack until this case is hit.
333+++
334
335threadinitialize.c:188
336Simple Test Case
337There must not be a thread/task created
338with THREAD_CPU_BUDGET_ALGORITHM_EXHAUST_TIMESLICE.
339+++
340
341iterateoverthreads.c:42
342Simple Test Case
343Need to call iterate over threads in a test where there is an API configured
344which does not have threads.  Should be easy to add to sp54.
345+++
346
347threadqenqueuepriority.c:92
348Interrupt Synchronization
349This case is where we are iterating to enqueue a thread into a priority
350based thread queue but the thread we are looking at gets unblocked when
351we flash interrupts.
352+++
353
354threadqenqueuepriority.c:131
355Simple Test Case
356I think! this is a case where we enqueue by priority with a thread
357priority that requires searching from last to first.  But there is
358already a thread priority on the chain.  This priority will go before
359any in the set.  So we search backwards and insert at the head.
360+++
361
362corebarrierwait.c:64
363Simple Test Case
364This looks like a simple test case of being a automatically released
365barrier and being the Nth task to block so tripping the automatic release.
366+++
367
368chain.inl:300
369Simple Test Case or Minor Code Rework
370This inlined case appears multiple times.
371
372_POSIX_signals_Clear_signals:71 chain get when empty
373
374This is actually part of _Watchdog_Adjust_to_chain and it appears to be
375dead because there is an explicit check for the chain being empty on the
376loop but the _Chain_Get_unprotected also checks for empty.  So we never
377get a case there _Chain_Get_unprotected returns NULL.  May be able to
378rework the loop to repeated call get until it gets a NULL.
379+++
380
381threadqenqueuepriority.c:139
382Interrupt Synchronization
383restart insertion search
384+++
385
386threadqenqueuepriority.c:189
387Simple Test Case
388need sp41 test cases with priority semaphore
389+++
390
391threadqprocesstimeout.c:46
392Interrupt Synchronization
393This is processing a timeout on a thread that times out while it is in the
394process of blocking on a thread queue.
395+++
396
397threadqprocesstimeout.c:54
398Interrupt Synchronization
399This is the return code from threadqprocesstimeout.c:46.  Perhaps
400restructuring this code will make it easier to combine these.  Hit the
401normal path first and return.  Then fall into the unusual synchronization
402path.
403+++
404
405watchdogadjusttochain.c:42
406Simple Test Case?
407I think this is a case where there are multiple items on the chain which
408are at the same time (0 delta).
409+++
410
411watchdoginsert.c:52
412Interrupt Synchronization
413This is when a higher priority interrupt inserts a timer while a lower
414priority interrupt is inserting one.
415+++
416
417watchdogremove.c:41
418Interrupt Synchronization
419Remove a watchdog while it is being inserted.
420+++
421
422watchdogremove.c:64
423Interrupt Synchronization
424Remove a watchdog while it is being removed.
425+++
426
427killinfo.c:152
428Simple Test Case
429Yet another path through here.
430+++
431
432killinfo.c:212
433Simple Test Case
434Multiple threads interested but find high priority one first.
435+++
436
437killinfo.c:247
438Simple Test Case
439Yet another path through here.
440+++
441
442killinfo.c:339
443Simple Test Case
444This is an error case where we can't allocate another signinfo structure.
445+++
446
447timerinserthelper.c:45
448Interrupt Synchronization
449We just removed the timer but the watchdog timer is being inserted by
450a higher priority interrupt.  We may be able to get this to happen
451with Classic API Timers.  But that is unclear.
452+++
Note: See TracBrowser for help on using the repository browser.