kdb+ interface to c causes segmentation violation when creating a symbol

[guy pitman]

I have a simple program to create a symbol to pass to kdb+ from c

#include k.h

class makeKDBObj

 {

  public:

    

      K getkobj();

 };     

K getkobj(){

   K T2=0;

   S metx= ss((char*)"metx");

  return T2;

 }

I have compiled this with a link to c.o

makeKDBObj: makeKDBObj.cpp $(HEADERS)

$(CXX) makeKDBObj.cpp c.o $(CXXFLAGS) $(ROOTFLAGS) -o makeKDBObj

where CXXFLAGS :=-std=c++0x -O3 -pedantic -Wall -Wno-long-long

ROOTFLAGS := $(shell root-config --cflags --libs --ldflags)

I get a segmentation fault, which appears to be happening on S metx= ss((char*)"metx");

===========================================================

There was a crash.

This is the entire stack trace of all threads:

===========================================================

#0  0x0000003768e99dd5 in waitpid () from /lib64/libc.so.6

#1  0x0000003768e3c4a1 in do_system () from /lib64/libc.so.6

#2  0x00002ab4dfe399ad in TUnixSystem::StackTrace() ()

   from /home/Root/root/lib/libCore.so

#3  0x00002ab4dfe3c003 in TUnixSystem::DispatchSignals(ESignals) ()

   from /home/Root/root/lib/libCore.so

#4  <signal handler called>

#5  0x0000000000404130 in sn ()

#6  0x00000000004028de in main ()

===========================================================

The lines below might hint at the cause of the crash.

If they do not help you then please submit a bug report at

http://root.cern.ch/bugs. Please post the ENTIRE stack trace

from above as an attachment in addition to anything else

that might help us fixing this issue.

===========================================================

#5  0x0000000000404130 in sn ()

#6  0x00000000004028de in main ()

===========================================================

Has anyone got any suggestions?

Many thanks

[Charles Skelton]

Hi Guy,

From

http://code.kx.com/wiki/Cookbook/InterfacingWithC

Note you must call khpu before generating any K data, and the very first call to khpu must not be concurrent to other khpu calls. To initialise memory without making a connection, use khp("",-1);

Maybe that's your issue?

Regards,
Charlie

--
You received this message because you are subscribed to the Google Groups "Kdb+ Personal Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to personal-kdbpl...@googlegroups.com.
To post to this group, send email to personal...@googlegroups.com.
Visit this group at http://groups.google.com/group/personal-kdbplus.
For more options, visit https://groups.google.com/d/optout.

[guy pitman]

Hi Charlie,

This is a c++ process which is reading some data and trying to produce kdb+ tables. I want to create a .so file so that I can call a function called getkobj which is written in c++ returning kdb+ tables or dictionaries.  I want to do this using the call  in q

getkdbobj:(`$"/home/Models/Code/makeKDBObj") 2:(`getkobj;1)

to instantiate a q function getkdbobj - there is no kdb+ server involved- kdb+ is the client.

Actually I have now worked around this crash by creating a dictionary with integer keys instead of a table, and this runs through without crashing (as a c++ program , not a dll).

Now I want to turn this into a dll and am having some problems with this. I am posting a separate issue about this.  If you have any further ideas on this one , I would be grateful for your help.

Regards

Guy

[Charles Skelton]

based on your compile line, it looked like you were creating a standalone application, linking with c.o.

In such a scenario, you must initialize the memory area used for the heap and for symbol interning before making any other calls to the kdb+ api - you do this via khp("",-1). Otherwise the call to ss would use uninitialized memory, and hence crash.

If you are creating a shared library to load into kdb+, the memory areas are already initialized by kdb+ so there is then no need to call khp("",-1), and you should also NOT link with c.o as the kdb+ api is exposed within kdb+ itself - linking with c.o in this case can result is not necessary, incorrect and will result in errors or a crash.

[guy pitman]

Hi Charlie,

You say I should not link with c.o.  I am using c.o so that I can access the k methods through k.h to generate kdb objects in c++ as per the InterfacingwithC wiki.

How then can I call the c++ function getkobj unless I create a .so file built with c.o?

Thanks and Regards

Guy 

[Charles Skelton (Kx)]

http://code.kx.com/wiki/Cookbook/ExtendingWithC

--

[guy pitman]

It looks like ExtendingWithC takes k objects in as arguments to c functions, and returns the results back to kdb+

I want to read files with C and convert them to kdb objects and return them to C.  For this I need c.o to turn the c objects to k objects.  

Maybe it is not possible to do this which is a pity because I think kdb+ would be well received by the physics community if one could get the data into kdb+

Regards

Guy

[Charles Skelton]

So if you are creating code which is not loaded into kdb+, then you should link with c.o, AND initialize the memory with

khp("",-1);

And make sure KXVER is defined before including k.h. i.e.

#define KXVER 3

#include"k.h"

What you are asking is possible and is a standard application of the api for e.g. feedhandlers.

So back to your original post, did you try initializing the memory with

khp("",-1);

?

[guy pitman]

Thanks for your feedback- I have been away for 3 weeks, so just got back to this

I have now included these statements.  - I am no longer getting segmentation violations.

However the other 2 issues that I posted previously still remain.( a kdb error on passing back the dictionary from C++

{$[(::)~x;"";`/:$[10h=@r:@[S[(."\\c")-2 1;0j];x;::];,-3!x;r]]}

'nyi

and also the values in the kdb array are not being converted correctly from double.

Thanks and Regards