Alter the scidb source code 15.7 doesn't work


#1

Hi, there!
When I modify the source code “src\array\MemArray.cpp” and the function “MemArray::pinChunk(LruMemChunk& chunk)”. I modify all of “_sDebug” change from false to true.
include\array\TileIteratorAdaptors.h

static const bool _sDebug = true;

src\array\MemArray.cpp

const bool _sDebug = true;

src\array\MemChunk.cpp

const bool _sDebug = true;

And I add

LOG4CXX_TRACE(logger, "*********Test output*******");

The code is here:

 void MemArray::pinChunk(LruMemChunk& chunk)
{    
 static const bool _sDebug = true;
       if (_sDebug) {
             LOG4CXX_TRACE(logger, "PIN: chunk="<<(void*)&chunk
                            << ",  accessCount is " << chunk._accessCount
                            << "Array="<<(void*)this << ",  name '" << chunk.arrayDesc->getName());
          }
     LOG4CXX_TRACE(logger, "*********Test output*******");
 }

I recompilation the source code with

./run.py -h # to learn its usage.
./run.py setup -f  # to configure build directories and cmake infrastructure
./run.py make -j4 
./run.py install
./deployment/deploy.sh build_fast /tmp/packages

Recompilation is 100% and no error. When I debug with GDB, run these query

iquery -aq "create array foo<val:double> [x=1:10,10,0]"
iquery -q " insert into foo '[(1)(2)(3)(4)(5)(6)(7)(8)(9)(10)]'"

GDB has a warning

Source file is more recent than executable 

1. But I have already recompilated the source code, I don’t know why the warning happened?

(gdb) p _sDebug
$4 = false

2.The variable " _sDebug" is still false.

**3. And "LOG4CXX_TRACE(logger, "Test output")" "Test output " doesn’t output in “scidb.log”.

gcc version 4.4.7 20120313 (Red Hat 4.4.7-16)
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6)

I don’t know why. Please help me.


#2

Try running cleanup before setup:

./run.py cleanup

#3

When installed from binary packages, SciDB doesn’t use run.py but instead is started and managed with /opt/scidb//bin/scidb.py . The run.py script places compiled binaries in a stage/build/ subdirectory, and when you use “./run.py install” you are installing into stage/install/ . Your note doesn’t say you ran “./run.py start”, so I wonder… could it be that the executable from the binary packages, and not the one you built, is the one actually running? That would explain the Gdb message.


#4

Hi, rares
I tried ./run.py cleanup, but it doesn’t work. Thank you.