On 26/11/2014 10:02 am, Joel Sherrill wrote:
From: Josh Oguin
This was flagged by CodeSonar. It should be impossible to get an
incorrect baud number back but ensure this in debug mode. The _Assert()
keeps their scanner from evaluating for divide by 0 past this point.
---
c/src/libchip/serial
Hello Joel,
On 25/11/14 20:30, Joel Sherrill wrote:
Coverity Id 1255348 in fs-rtems.c can't be ignored on the grounds
the JFFS2 project will see it.
this is one-to-one copy from the eCos code. I don't know how and why it
works.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierst
Hello Joel,
I fixed it like this:
http://git.rtems.org/rtems/commit/?id=d6f0ca64a5932ee38fb5891dbce886e0b10f63e7
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@emb
On 25/11/14 23:25, Joel Sherrill wrote:
How long is this test supposed to run?
It takes 4:42 using sis on my computer which is a 2.9 Ghz i7 .
SIS is a slow simulator. On Qemu it runs much faster.
Is there anything to do? Split it?
Splitting it up doesn't reduce the overall test time. Th
On 26/11/14 00:02, Joel Sherrill wrote:
From: Josh Oguin
CodeSonar spotted that the return values were being ignored.
---
cpukit/libcsupport/src/sync.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/cpukit/libcsupport/src/sync.c b/cpukit/libcsupport/src/sync.c
ind
On 11/25/2014 4:54 PM, Joel Sherrill wrote:
> On 11/25/2014 4:49 PM, Jiri Gaisler wrote:
>> On 11/25/2014 11:42 PM, Jiri Gaisler wrote:
>>> spsem01.exe executes correctly on sis and real hardware, but does not
>>> terminate.
>>> The program hangs in the bsp_idle_tread() after executing the final
From: Josh Oguin
These were flagged by CodeSonar. The assignments on variable declaration
are overridden a few lines below and the other line later with name_size
is where name_size was not used after this assignment.
---
cpukit/libfs/src/dosfs/msdos_conv.c | 5 ++---
1 file changed, 2 insertion
From: Josh Oguin
This code is built without warnings and ignored by Coverity Scan.
CodeSonar found a wide range of issues including buffer overruns,
buffer underruns, questionable type conversions, leaks, etc. This
set of patches addresses all reported issues.
---
tools/build/binpatch.c| 144
From: Josh Oguin
CodeSonar spotted that the return values were being ignored.
---
cpukit/libcsupport/src/sync.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/cpukit/libcsupport/src/sync.c b/cpukit/libcsupport/src/sync.c
index b8e5059..0e935ce 100644
--- a/cpukit/libcs
From: Josh Oguin
CodeSonar flagged this as a case where the user could inject a format
string and cause issues. Since we were not printing anything but a
string, just switching to puts() rather than fprintf(stdout,...) was
sufficient to make this code safer.
---
cpukit/libmisc/monitor/mon-prmisc
From: Josh Oguin
---
cpukit/score/src/objectgetnameasstring.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/cpukit/score/src/objectgetnameasstring.c
b/cpukit/score/src/objectgetnameasstring.c
index 099d837..7505c02 100644
--- a/cpukit/score/src/objectgetnam
From: Josh Oguin
CodeSonar flagged this as a possible NULL deference. This should never
occur but adding the _Assert() ensures we are guarding against that.
---
cpukit/score/include/rtems/score/objectimpl.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/cpukit/score/include/rtems/scor
From: Josh Oguin
CodeSonar flagged this as a potential NULL deference. That should never
occur but adding the _Assert() ensures we are checking that.
---
cpukit/score/include/rtems/score/chainimpl.h | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/cpukit/score/inc
From: Josh Oguin
CodeSonar flagged this as an empty if body. Upon analysis, it turned
out to be an error that we think should never occur but if it did,
there is nothing we could do about it. It would likely just indicate
the thread was deleted before we got here. Adding the _Assert() at least
wi
From: Josh Oguin
CodeSonar flagged this as a case where the user could inject a format
string and cause issues. Since we were not printing anything but a
string, just switching to puts() rather than fprintf(stdout,...) was
sufficient to make this code safer.
snprintf() places a limit on the leng
From: Josh Oguin
CodeSonar flagged this as a possible dereference of a NULL pointer.
This should never occur so adding _Assert().
---
cpukit/libfs/src/imfs/imfs_handlers_link.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cpukit/libfs/src/imfs/imfs_handlers_link.c
b/cpukit/libfs/src/im
From: Josh Oguin
CodeSonar flagged the increment of this pointer as unneeded. The pointer
is not used past this point.
---
cpukit/libfs/src/dosfs/msdos_misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/libfs/src/dosfs/msdos_misc.c
b/cpukit/libfs/src/dosfs/msdos_m
From: Josh Oguin
CodeSonar flagged this as a case where the return value from fat_sync()
was not used. Now it is used to return pass/fail to the caller.
---
cpukit/libfs/src/dosfs/msdos_file.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/cpukit/libfs/src/dosfs/msdos_fi
From: Josh Oguin
This was flagged as an ignored return value by CodeSonar.
---
cpukit/libcsupport/src/sync.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cpukit/libcsupport/src/sync.c b/cpukit/libcsupport/src/sync.c
index 653a177..b8e5059 100644
--- a/cpukit/libcsupp
From: Josh Oguin
This was flagged as an empty for statement by CodeSonar but is actually
unreachable code that should be removed.
---
cpukit/libcsupport/src/newlibc_exit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/libcsupport/src/newlibc_exit.c
b/cpukit/libcsupp
From: Josh Oguin
This was flagged by CodeSonar.
---
cpukit/libcsupport/src/mount.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/cpukit/libcsupport/src/mount.c b/cpukit/libcsupport/src/mount.c
index d993686..0d66477 100644
--- a/cpukit/libcsupport/src/mount.c
+++ b/cpukit/libcsupport/src/mo
From: Josh Oguin
This was flagged by CodeSonar.
---
c/src/libchip/serial/z85c30.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/c/src/libchip/serial/z85c30.c b/c/src/libchip/serial/z85c30.c
index 1f43271..7c55a51 100644
--- a/c/src/libchip/serial/z85c30.c
+++ b/c/src/libchip/serial/z85c30.c
From: Josh Oguin
This was flagged by CodeSonar. It should be impossible to get an
incorrect baud number back but ensure this in debug mode. The _Assert()
keeps their scanner from evaluating for divide by 0 past this point.
---
c/src/libchip/serial/ns16550-context.c | 4
c/src/libchip/serial
From: Josh Oguin
This was flagged by CodeSonar.
---
c/src/libchip/display/disp_hcms29xx.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/c/src/libchip/display/disp_hcms29xx.c
b/c/src/libchip/display/disp_hcms29xx.c
index 50fce99..5730b36 100644
--- a/c/src/libchip/dis
From: Josh Oguin
---
c/src/lib/libbsp/shared/bspinit.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/c/src/lib/libbsp/shared/bspinit.c
b/c/src/lib/libbsp/shared/bspinit.c
index 86c950c..b524389 100644
--- a/c/src/lib/libbsp/shared/bspinit.c
+++ b
From: Josh Oguin
CodeSonar detects a possible NULL deference here. But it should never
occur in tested code. Memory for the API Mutexes is reserved by confdefs.h
and are all preallocated when the class of objects is initialized.
Allocating a single instance should never fail.
---
cpukit/score/sr
Hi
Josh O'guin and I have been using CodeSonar to evaluate RTEMS.
This is a first set of patches which clears up some of the reported
issues.
Most of the patches are small. However, the tools/ directory
is a single patch for all files. They are not compiled with
warnings and ignored by Coverit
From: Josh Oguin
Hi
Josh and I have been using CodeSonar to evaluate RTEMS. This
is a first set of patches which clears up some of the reported
issues.
Most of the patches are small. However, the tools/ directory
is a single patch for all files. They are not compiled with
warnings and ignore
On 11/25/2014 4:49 PM, Jiri Gaisler wrote:
>
> On 11/25/2014 11:42 PM, Jiri Gaisler wrote:
>> spsem01.exe executes correctly on sis and real hardware, but does not
>> terminate.
>> The program hangs in the bsp_idle_tread() after executing the final
>> rtems_test_exit(0).
>> Is this the intention
On 11/25/2014 4:42 PM, Jiri Gaisler wrote:
> spsem01.exe executes correctly on sis and real hardware, but does not
> terminate.
> The program hangs in the bsp_idle_tread() after executing the final
> rtems_test_exit(0).
> Is this the intention of the test?
It terminates very quickly on sis for m
On 11/25/2014 11:42 PM, Jiri Gaisler wrote:
>
> spsem01.exe executes correctly on sis and real hardware, but does not
> terminate.
> The program hangs in the bsp_idle_tread() after executing the final
> rtems_test_exit(0).
> Is this the intention of the test?
OK, I found a difference in the
spsem01.exe executes correctly on sis and real hardware, but does not terminate.
The program hangs in the bsp_idle_tread() after executing the final
rtems_test_exit(0).
Is this the intention of the test?
Jiri.
___
devel mailing list
devel@rtems.org
htt
Hi
How long is this test supposed to run?
It takes 4:42 using sis on my computer which is a 2.9 Ghz i7 .
Is there anything to do? Split it?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS:
Hi
There are two Coverity Issues with untar.c but this one seems
especially odd to me.
My reading of the following code is that if the creat() of the
filename in the tar image fails, then the code reads the contents
of the tar image and throws it away to skip it.
What would be wrong with replaci
On Tue, Nov 25, 2014 at 2:48 PM, Gedare Bloom wrote:
> Sebastian will have to comment, but it looks like the inner path is
> not expected to be taken the first time through, i.e. you might add:
> assert(root_i->i_count > 0);
>
P.S. the function has a FIXME at the top suggesting it should be done
a
Sebastian will have to comment, but it looks like the inner path is
not expected to be taken the first time through, i.e. you might add:
assert(root_i->i_count > 0);
-Gedare
On Tue, Nov 25, 2014 at 2:30 PM, Joel Sherrill
wrote:
> Hi
>
> Coverity Id 1255348 in fs-rtems.c can't be ignored on the g
Hi
Coverity Id 1255348 in fs-rtems.c can't be ignored on the grounds
the JFFS2 project will see it.
this->i_cache_prev->i_cache_next =
this->i_cache_next;
84jffs2_clear_inode(this);
85memset(this, 0x5a, sizeof(*this
On Tue, Nov 25, 2014 at 2:03 PM, Joel Sherrill
wrote:
> Hi
>
> These appear to be easy to address. I would appreciate someone
> addressing these:
>
> i2c/eeprom.c:
>
> 221
>
> 1. Condition address_bytes > 4, taking false branch
>
> 2. cond_at_most: Checking address_bytes > 4 implies that address_b
Hi all,
I came across an issue with alignment when I am porting RTEMS to Epiphany
now. The reference manual says that stores should be aligned according to
the store instruction type (half word, word, double word). For example strd
instruction should get an address aligned to 8 bytes. Although I s
Hi
These appear to be easy to address. I would appreciate someone
addressing these:
i2c/eeprom.c:
221
1. Condition address_bytes > 4, taking false branch
2. cond_at_most: Checking address_bytes > 4 implies
that address_bytes has the value which may be up to 4 on the false branch.
222 if
Hi
I took the time to look at the Coverity issues and break them
down by source area. A few important points first:
+ no issues in score, posix, rtems, or sapi. YEAH!!!
+ jffs2 issues are being ignored. Aside from being third party
code, there is a coverity annotation in the source so it is
Hi
It isn't too late to sign up to attend the Flight Software Workshop.
The talks are always very interesting and, personally, Ialways
enjoy attending.
http://flightsoftware.jhuapl.edu/
Registration information for this year and talks (videos and PDF)
from previous years are online at the above
This section can be use to provide a cache coherent memory area via
rtems_cache_coherent_add_area().
---
c/src/lib/libbsp/arm/altera-cyclone-v/Makefile.am | 2 -
.../arm/altera-cyclone-v/include/nocache-heap.h| 55 -
.../libbsp/arm/altera-cyclone-v/network/network.c | 14 +---
.
Add rtems_cache_coherent_free() and rtems_cache_coherent_add_area().
---
cpukit/libcsupport/Makefile.am | 1 +
cpukit/libcsupport/src/cachecoherentalloc.c | 122
cpukit/rtems/include/rtems/rtems/cache.h| 61 ++
testsuites/sptests/spcache
On November 25, 2014 8:54:24 AM CST, Gabriel Ibarra
wrote:
>Hi, I'm working with rtems task and I'm trying to pass a pointer object
>as argument of the task, using the RTEMS API.
>
>
>I saw that rtems_task_argument is defined as uintptr_t, so I assume
>that the way to do it, is just a cast. Is
Hi, I'm working with rtems task and I'm trying to pass a pointer object as
argument of the task, using the RTEMS API.
I saw that rtems_task_argument is defined as uintptr_t, so I assume that
the way to do it, is just a cast. Is it true?, or there is another way to
do it.
Also, I wonder why uintptr
46 matches
Mail list logo
