source: rtems-testing/rtems-coverage/Explanations.txt @ 66887d4

4.11
Last change on this file since 66887d4 was 66887d4, checked in by Joel Sherrill <joel.sherrill@…>, on Jul 6, 2009 at 10:00:22 PM

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

  • Explanations.txt: Clean up mutexget.c and corresponding explanations.
  • Property mode set to 100644
File size: 14.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
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
134mutexsetprioceiling.c:59
135Probably Simple Test Case
136This appears to be missing not passing in a bad id.
137+++
138
139mutextimedlock.c:59
140Simple Test Case (or Restructure)
141Looks like another undertested timeout path.
142+++
143
144mutexget.c:69
145Simple Test Case
146This is using the automatic initializer PASS and FAIL from anything
147but pthread_mutex_lock.
148+++
149
150mutexget.c:83
151Simple Test Case
152This is using the automatic initializer PASS and FAIL from
153pthread_mutex_lock.
154+++
155
156pthread.c:83
157Simple Test Case
158This is a case of the sporadic scheduling budget being less than one clock
159tick in length.
160+++
161
162pthread.c:97
163Simple Test Case
164This is a case of the sporadic scheduling replinish period being less
165than one clock tick in length.
166+++
167
168pthread.c:129
169Simple Test Case
170This is a case of attempting to change the priority of a thread
171holding resources at the end of the sporadic server period.
172+++
173
174pthread.c:130
175Simple Test Case
176It looks like we don't have a good sporadic server test.  This is
177the normal case of changin priority.
178+++
179
180eventsurrender.c:81
181Interrupt Synchronization
182This is executed when events are sent to the currently executing thread
183while it is in the process of blocking.  I think sp39 or sp41 relates to
184this but may not be hitting the correct combination of timed out or Any/All.
185
186NOTE: This is hit sometimes so maybe the tests need tuning a bit.
187+++
188
189eventsurrender.c:82
190Interrupt Synchronization
191This is somehow related to eventsurrender.c:81 but the range is
192disconnected and I do not see why with certainty.  This could be
193when a timeout occurs while we are blocking on an event receive.
194+++
195
196eventtimeout.c:78
197Interrupt Synchronization
198This is a timeout while blocking waiting for an event receive with timeout.
199+++
200
201ratemontimeout.c:61
202Simple Test Case
203period times out but thread is blocked on another period?
204+++
205
206ratemonperiod.c:310
207Interrupt Synchronization
208period must expire while attempting to block
209+++
210
211watchdog.inl:129
212Interrupt Synchronization
213
214period expires while blocking (ratemontimeout.c:66)
215+++
216
217timerreset.c:60
218Simple Test Case
219new error case
220+++
221
222timerserverfireafter.c:80
223Interrupt Synchronization
224timer must be inserted by an ISR while we are inserting it
225+++
226
227semcreate.c:163
228Simple Test Case
229need to create a semaphore that is RTEMS_PRIORITY_CEILING
230+++
231
232coremutex.inl:171
233Simple Test Case
234pri ceiling, acquire when pri = ceiling
235+++
236
237corespinlockwait.c:69
238Simple Test Case
239The spinlock is not available and the caller is not willing to wait.
240Requires a test of pthread_spin_trylock.
241+++
242
243corespinlockrelease.c:59
244Simple Test Case
245Attempt to release a locked spinlock from a thread that is not the one
246which locked it.
247+++
248
249coremutexsurrender.c:88
250Simple Test Case or Code Restructuring
251This is a switch which has two cases marked as not able to be hit. This
252documentation needs to be verified and if true, restructured to represent
253this.  The cases that are not executed need to be turned into a
254conditionalized debug assertion.
255+++
256
257coremutexsurrender.c:178
258Simple Test Case
259I have trouble believing there is no simple priority ceiling mutex test
260which locks raises priority and then releases and lowers priority but this
261case sure looks like that.  Or it is a case where the thread's priority
262is equal to the ceiling and the branch is taken.  Hard to read SPARC assembly.
263I am leaning to the equal case.
264+++
265
266semflush.c:82
267Simple Test Case
268need to flush a NOT counting semaphore
269+++
270
271debug.c:63
272Simple Test Case
273need a test
274+++
275
276heapresizeblock.c:158
277Simple Test Case
278looks like shrink block but so small the unused area gets freed
279+++
280
281objectshrinkinformation.c:101
282Talk To Chris
283This code needs to be explained by Chris and possibly restructured.
284I think this is possibly dead code where a branch case cannot actually
285be taken because it is redundant.  But more than than that, I am not
286100% sure the code is correct. I am unsure how the loop ensures that
287all objects within an allocation block are verified as being free.
288+++
289
290objectidtoname.c:78
291Simple Test Case
292I find it hard to believe that this is not already covered but the code
293appears to be the exit path for the successful lookup of an id to return
294the object's name. Verify the lack of a test case and add one.  If there
295is a test case that would appear to cover this, investigate.
296+++
297
298objectgetinfo.c:36
299Dead Code?
300This appears to be a case where a number which should be unsigned
301(and maybe isn't) is being checked for being negative.  The method
302being called probably should be changed to return an unsigned int
303and the < 0 comparison removed.
304+++
305
306pheapgetinfo.c:40
307Simple Test Case
308This appears to be the exit path for all errors in this routine.  Obviously
309there are no tests for errors.
310+++
311
312heapallocatealigned.c:223
313Simple Test Case
314This looks like a case where the allocate aligned simply fails to get any
315memory.
316+++
317
318heapgetinfo.c:70
319Simple Test Case
320The heap is corrupted.  The block's size does not match the next block's
321previous size backwards link.  This may make sense to add to the
322Heap Walk test.
323+++
324
325heapresizeblock.c:144
326Simple Test Case
327Shrink a heap block with the resize.  The block after this one in memory
328must be free so the memory free by the shrinking will be merged with that
329already free block.
330+++
331
332heapwalk.c:144
333Test Case
334We are not hitting the case for having an error at this place.  I would have
335thought that making do_dump 0 and running all the cases is enough.  Maybe the
336test does not do what I think and this is why this case is missed.
337+++
338
339regionresizesegment.c:83
340Simple Test Case
341Apparently we do not have a test case where there is memory freed by the
342resize effort is sufficient to result in needing to look to see if we
343can unblock any tasks.
344+++
345
346ioregisterdriver.c:61
347Simple Test Case
348documented (not implemented) in sp40.  Fill up the driver table and
349register another driver.
350+++
351
352ioregisterdriver.c:71
353Simple Test Case
354documented (not implemented) in sp40.  Fill up the driver table and
355register another driver.  All of the cases in this file are probably
356related and will take attention when working on them to be sure I
357have explained them correctly.  The assembly is just hard to follow.
358+++
359
360ioregisterdriver.c:84
361Simple Test Case
362if reachable
363+++
364
365dpmemcreate.c:87
366Simple Test Case
367need invalid address of return id
368+++
369
370timerfireafter.c:76
371Interrupt Synchronization
372timer must be inserted or state altered by ISR
373+++
374
375thread.inl:230
376SHOULD BE COVERED
377sp39 should cover this .. timeout while blocking (eventtimeout.c:71)
378+++
379
380thread.inl:47
381Simple Test Case
382(sys state trickery) shutdown while in shutdown state
383+++
384
385threadget.c:88
386Simple Test Case
387This will require adding a POSIX test where only Classic API tasks are
388configured and what should be the valid Id of a POSIX thread is passed
389to any thread/task routine.
390+++
391
392threadinitialize.c:91
393Simple Test Case
394This is for the case where the application uses the POSIX
395thread stack address attribute.
396
397NOTE: Code Should be Configured on POSIX
398+++
399
400threadinitialize.c:148
401Medium Test Case
402The allocation of the user extension data area must fail.  The failure should
403occur during the create case of an Floating Point enabled task.
404
405Since the stack is allocated first, it should be possible to have a test
406with a fair (16-32?) number of user extensions configured and then
407create a thread with increasingly larger stack until this case is hit.
408+++
409
410threadinitialize.c:188
411Simple Test Case
412There must not be a thread/task created
413with THREAD_CPU_BUDGET_ALGORITHM_EXHAUST_TIMESLICE.
414+++
415
416threadinitialize.c:233
417Simple Test Case
418Add case with user extension which fails to allocate memory on create
419+++
420
421iterateoverthreads.c:42
422Simple Test Case
423Need to call iterate over threads in a test where there is an API configured
424which does not have threads.  Should be easy to add to sp54.
425+++
426
427threadqenqueuepriority.c:92
428Interrupt Synchronization
429This case is where we are iterating to enqueue a thread into a priority
430based thread queue but the thread we are looking at gets unblocked when
431we flash interrupts.
432+++
433
434threadqenqueuepriority.c:131
435Simple Test Case
436I think! this is a case where we enqueue by priority with a thread
437priority that requires searching from last to first.  But there is
438already a thread priority on the chain.  This priority will go before
439any in the set.  So we search backwards and insert at the head.
440+++
441
442threadreset.c:63
443Simple Test Case
444This is a case where a task is restarted with its per task watchdog
445timer active. This probably can be hit by having a task do a long
446wake after and another thread restart it.
447+++
448
449corebarrierwait.c:64
450Simple Test Case
451This looks like a simple test case of being a automatically released
452barrier and being the Nth task to block so tripping the automatic release.
453+++
454
455chain.inl:300
456Simple Test Case or Minor Code Rework
457This inlined case appears multiple times.
458
459_POSIX_signals_Clear_signals:71 chain get when empty
460
461This is actually part of _Watchdog_Adjust_to_chain and it appears to be
462dead because there is an explicit check for the chain being empty on the
463loop but the _Chain_Get_unprotected also checks for empty.  So we never
464get a case there _Chain_Get_unprotected returns NULL.  May be able to
465rework the loop to repeated call get until it gets a NULL.
466+++
467
468threadqenqueuepriority.c:139
469Interrupt Synchronization
470restart insertion search
471+++
472
473threadqenqueuepriority.c:189
474Simple Test Case
475need sp41 test cases with priority semaphore
476+++
477
478threadqextractfifo.c:55
479Simple Test Case
480extract thread that isn't blocked on thread queue.  Probably requires
481bypassing APIs and going to SuperCode directly. Hard if API not bypassed.
482+++
483
484threadqextractpriority.c:64
485Simple Test Case
486extract thread that isn't blocked on thread queue.  Probably requires
487bypassing APIs and going to SuperCode directly. Hard if API not bypassed.
488+++
489
490threadqfirstpriority.c:51
491Simple Test Case
492Ask for first priority on a thread queue with no tasks.  May require
493bypassing APIs and going to SuperCode directly. Hard if API not bypassed.
494+++
495
496threadqprocesstimeout.c:46
497Interrupt Synchronization
498This is processing a timeout on a thread that times out while it is in the
499process of blocking on a thread queue.
500+++
501
502threadqprocesstimeout.c:54
503Interrupt Synchronization
504This is the return code from threadqprocesstimeout.c:46.  Perhaps
505restructuring this code will make it easier to combine these.  Hit the
506normal path first and return.  Then fall into the unusual synchronization
507path.
508+++
509
510timespecdivide.c:44
511Simple Test Case
512Will probably have to bypass the APIs but this is a divide by zero case.
513+++
514
515watchdogadjusttochain.c:42
516Simple Test Case?
517I think this is a case where there are multiple items on the chain which
518are at the same time (0 delta).
519+++
520
521watchdoginsert.c:52
522Interrupt Synchronization
523This is when a higher priority interrupt inserts a timer while a lower
524priority interrupt is inserting one.
525+++
526
527watchdogremove.c:41
528Interrupt Synchronization
529Remove a watchdog while it is being inserted.
530+++
531
532watchdogremove.c:64
533Interrupt Synchronization
534Remove a watchdog while it is being removed.
535+++
536
537userextremoveset.c:34
538Simple Test Case
539Remove a user extension set with a context switch extension.  Add to
540existing extension test.
541+++
542
543userextthreadcreate.c:43
544Simple Test Case
545Task create user extension fails.
546+++
547
548killinfo.c:152
549Simple Test Case
550Yet another path through here.
551+++
552
553killinfo.c:212
554Simple Test Case
555Multiple threads interested but find high priority one first.
556+++
557
558killinfo.c:247
559Simple Test Case
560Yet another path through here.
561+++
562
563killinfo.c:339
564Simple Test Case
565This is an error case where we can't allocate another signinfo structure.
566+++
567
568timerinserthelper.c:45
569Interrupt Synchronization
570We just removed the timer but the watchdog timer is being inserted by
571a higher priority interrupt.  We may be able to get this to happen
572with Classic API Timers.  But that is unclear.
573+++
Note: See TracBrowser for help on using the repository browser.