EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: vxWorks 5.2 kernel bug?
From: Benjamin Franksen <[email protected]>
To: EPICS Techtalk <[email protected]>
Date: Tue, 05 Aug 1997 19:43:12 +0200
Hi folks,

has anyone of you observed a problem with vxWorks 5.2 and the function
memShow()? The reason I ask is the following:

Today I found out that when I type 'memShow' on the command line, it
says:

-> memShow
  invalid block at 0x7fc000 deleted
value = -1 = 0xffffffff = _ibDebug + 0xff8887bb

Normally, this would indicate some error in the software, where a the
structural information about some dynamically allocated memory block is
overwritten accidentally. Now, the strange thing is that this happens
even if _no_ object file except the vxWorks kernel is loaded, and no
function is called prior to memShow except the vxWorks initialization
routines. Even stranger is that my colleagues swear that memShow worked
fine a few weeks (months?) ago. We could not however get rid of the
problem by reviving older kernel versions.

After memShow has deleted the invalid block channel access is badly
damaged, but the IOC database seems to work correctly.

The phenomena seems to happen on mv162-042 and mv162-532 boards,
although the address of the 'invalid block' of course depends on the
amount of memory on the board.

Two possible reasons for this behavior come to my mind:

First: memShow has an error and only _thinks_ (wrongly) that the memory
block is invalid. This seems a very minor chance, but would be a lucky
thing.

Second: Some vxWorks init routine actually overwrites memory that it
should not. I don't have any idea how to solve that (although Ralph had
the idea that possibly some 'start line' is too long). Furthermore it
cannot be ruled out, that this error leads somehow to IOC failures in a
production environment, which definitely cannot be tolerated.

If anybody has experienced something similar, or has a comment or
suggestion about what is wrong here, I'd be grateful.

	Ben
-- 
The Notorious Neb Nesknarf
// snail: BESSY II, Rudower Chaussee 5, D-12489 Berlin, Germany
// email: [email protected]
// phone/fax: +49(30)6392-4865 / 6392-4859

Navigate by Date:
Prev: R3.13.0.beta11 base build for HP port Johnny Tang
Next: acc? Thomas Hahn
Index: 1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: R3.13.0.beta11 base build for HP port Johnny Tang
Next: acc? Thomas Hahn
Index: 1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·