Debugging a custom operator


#1

Hi,

I’m building a custom operator and I got core dumped when I try to run it (I see that in scidb-stderr.log file)
However, I can’t find the core file so I don’t know how to debug it.

Please help me out!


#2

Hi,

Yeah I get into that situation often :smile:

  1. check what “ulimit -c” is set to. Set it to unlimited unless it’s already there. If it wasn’t at unlimited before, restart scidb from the same session.
  2. core file should go into scidb’s instance path - i.e. scidbdata/000/0/… right next to where scidb.log et. al. live

Other considerations:

  1. it helps to attach a debugger to scidb right as it’s running and then run the query that makes it crash. That will allow you to examine the execution state.
  2. it also helps to build scidb and plugin with debug flags. For scidb, use cmake -DCMAKE_BUILD_TYPE=Debug or RelWithDebInfo

#3

Thank you for your response! I got the core file now and found where the crash happened.

I’d like to debug my operator furthermore.
I found scidb.debug file so I think I can use gdb to debug scidb.
However, I’m quite new for everything here. Would you please help me find how I can run and debug my operator using gdb?

Thank you in advance!
MJ


#4

Yes GDB is the standard way.
Make sure scidb is in PATH.
Do ps axf | grep -i scidb to find the pid of the scidb process. When running with watchdog, make sure you use the right pid - the pid of the child.
Use sudo gdb scidb PID to connect gdb to scidb.
… and you should be good to go.


#5

I tried to run gdb PID but I still have no idea about how I debug the source code for my operator. (Sorry I’m really new to GDB and also SciDB) Would you please show me how little more specific? It will be really great if you show some example for any operator of SciDB.

Thanks again!
MJ


#6

Hi,

I did find how to do myself. Yay!
In GDB, I did set a breakpoint in my code then I can find the stack trace, etc.

Thanks!
MJ


#7

Glad you found it. Unfortunately I’m a bit pressed for time at the moment. If I may make a quick recommendation - there is another tool called “DDD” or “Data Display Debugger”. It sits on top of gdb and presents a much more humane interface with windows and buttons. That’s what I started using a few years ago before I “graduated” to gdb.

Best of luck!


#8

GDB is quite satisfiable for my use for now (with little help from printf… :wink: ). However, I appreciate your recommending those tools and I’ll make sure to try them!

Thank you so much for all your assistance!

-MJ


#9

As an additional thought …

We’ve built the lib4cxx logger utility into SciDB. Rather than printf() (which sends its output who knows where, and gets seriously unmanageable as you begin to work with parallelism) try using the LOG4CXX_* macros. For examples, use something like "grep LOG4CXX_DEBUG find . -name '*.cpp' -print" in the source tree.

Logged messages are dumped into the scidb.log file, located in the base-path directory. Lots and lots of useful information about SciDB’s running state in there. . .