TWS API Linux - Segmentation fault - __bid64_to_string - c++

Question

Running Cpp sample client out of the box.
I receive a segmentation fault.
0x00005555555efba6 in __bid64_to_string ()
Have sourced this function to client file to Decimal.h
extern "C" void __bid64_to_string(char*, Decimal, unsigned int*);
This may have something to do with the floating point library that the API documentation mentions: Intel® Decimal Floating-Point Math Library
https://interactivebrokers.github.io/tws-api/introduction.html
I have checked if this is installed on my ubuntu version, using WSL Ubuntu 20.04.05
libintelrdfpmath-dev/now 2.0u2-4 amd64 [installed,local]
root#flare9x:~# dpkg -s libintelrdfpmath-dev
Package: libintelrdfpmath-dev
Status: install ok installed
Priority: optional
Section: libdevel
Installed-Size: 72286
Maintainer: Ubuntu Developers <ubuntu-devel-discuss#lists.ubuntu.com>
Architecture: amd64
Source: intelrdfpmath
Version: 2.0u2-4
Description: Intel Decimal Floating-Point Math Library
Software implementation of the IEEE 754-2008 Decimal Floating-Point
Arithmetic specification, aimed at financial applications, especially
in cases where legal requirements make it necessary to use decimal, and
not binary floating-point arithmetic (as computation performed with
binary floating-point operations may introduce small, but unacceptable
errors).
Original-Maintainer: Christian Stalp <chris#chrishell.de>
Homepage: https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library
Looking at the makefile:
CXXFLAGS=-pthread -Wall -Wno-switch -Wpedantic -Wno-unused-function -std=c++11
ROOT_DIR=../../../source/cppclient
BASE_SRC_DIR=${ROOT_DIR}/client
INCLUDES=-I${BASE_SRC_DIR} -I${ROOT_DIR}
SHARED_LIB_DIRS=${BASE_SRC_DIR}
SHARD_LIBS=libTwsSocketClient.so
TARGET=TestCppClient
$(TARGET)Static:
$(CXX) $(CXXFLAGS) $(INCLUDES) $(BASE_SRC_DIR)/*.cpp ./*.cpp $(BASE_SRC_DIR)/lib/libbid.a -o$(TARGET)Static
$(TARGET):
$(CXX) $(CXXFLAGS) $(INCLUDES) ./*.cpp $(BASE_SRC_DIR)/lib/libbid.so $(SHARED_LIB_DIRS)/$(SHARD_LIBS) -o$(TARGET)
clean:
rm -f $(TARGET) $(TARGET)Static *.o
The interesting part - I can compile the exact same code on Windows, VScode in win32.
I have tried to enforce 32bit with gcc. adding -m32.
When doing this compiler shows numerous complaints:
1974 | printf("Soft dollar tiers (%lu):", tiers.size());
| ~~^ ~~~~~~~~~~~~
| | |
| | std::vector<SoftDollarTier>::size_type {aka unsigned int}
| long unsigned int
| %u
I commented out these functions which include %lu as do not need them in main application.
Compile again, this time we have errors with the librarys that are packaged with the TWS API - the Intel decimal floating point math library, these libs come with the original TWS installation and locate:
/source/cppclient/client/lib/libbid.a
/usr/bin/ld: i386:x86-64 architecture of input file `../../../source/cppclient/client/lib/libbid.a(bid64_string.o)' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `../../../source/cppclient/client/lib/libbid.a(bid128_2_str_tables.o)' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `../../../source/cppclient/client/lib/libbid.a(bid_decimal_data.o)' is incompatible with i386 output
win32 runs this just fine vscode.
running with ```gcc -m64``
Obtain seg fault again:
Thread 1 "TestCppClientSt" received signal SIGSEGV, Segmentation fault.
0x00005555555efba6 in __bid64_to_string ()
(gdb) bt
#0 0x00005555555efba6 in __bid64_to_string ()
#1 0x00007fffffffd940 in ?? ()
#2 0x00007fffffffd940 in ?? ()
#3 0x00007fffffffd940 in ?? ()
#4 0x00007fffffffd941 in ?? ()
#5 0x00007fffffffd940 in ?? ()
#6 0x00007fffffffd820 in ?? ()
#7 0x000055555555d5ff in std::iterator_traits<char*>::difference_type std::distance<char*>(char*, char*) ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Not sure what it could be at this point - WSL and running ubuntu on windows - that process manages memory? is ubuntu clashing with windows.
At this point - what else can I check / troubleshoot?
Thanks

Answer 1

Ok finally got it working by locating where the intel floating point math library was located, named: libintelrdfpmath-dev, this was in contrast to using the library that comes with the TWS API as is, located at directory: ~/IBJts/source/cppclient/client/lib/libbid.a
:
root#Ubuntu-22:/bin# dpkg -L libintelrdfpmath-dev
/.
/usr
/usr/include
/usr/include/bid_conf.h
/usr/include/bid_functions.h
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libbidgcc000.a
/usr/lib/x86_64-linux-gnu/libbidgcc000b.a
/usr/lib/x86_64-linux-gnu/libbidgcc001.a
/usr/lib/x86_64-linux-gnu/libbidgcc001b.a
/usr/lib/x86_64-linux-gnu/libbidgcc010.a
/usr/lib/x86_64-linux-gnu/libbidgcc010b.a
/usr/lib/x86_64-linux-gnu/libbidgcc011.a
/usr/lib/x86_64-linux-gnu/libbidgcc011b.a
/usr/lib/x86_64-linux-gnu/libbidgcc100.a
/usr/lib/x86_64-linux-gnu/libbidgcc100b.a
/usr/lib/x86_64-linux-gnu/libbidgcc101.a
/usr/lib/x86_64-linux-gnu/libbidgcc101b.a
/usr/lib/x86_64-linux-gnu/libbidgcc110.a
/usr/lib/x86_64-linux-gnu/libbidgcc110b.a
/usr/lib/x86_64-linux-gnu/libbidgcc111.a
/usr/lib/x86_64-linux-gnu/libbidgcc111b.a
/usr/share
/usr/share/doc
/usr/share/doc/libintelrdfpmath-dev
/usr/share/doc/libintelrdfpmath-dev/README.gz
/usr/share/doc/libintelrdfpmath-dev/changelog.Debian.gz
/usr/share/doc/libintelrdfpmath-dev/copyright
I edited the makefile to include the path to this library, now which one?
I added
/usr/lib/x86_64-linux-gnu/libbidgcc000.a to my make file.
My makefile looks like:
CXX=g++
CXXFLAGS=-pthread -Wall -Wno-switch -Wpedantic -Wno-unused-function -std=c++11
ROOT_DIR=../../../source/cppclient
BASE_SRC_DIR=${ROOT_DIR}/client
INCLUDES=-I${BASE_SRC_DIR} -I${ROOT_DIR}
SHARED_LIB_DIRS=${BASE_SRC_DIR}
SHARD_LIBS=libTwsSocketClient.so
TARGET=TestCppClient
$(TARGET)Static:
$(CXX) $(CXXFLAGS) $(INCLUDES) $(BASE_SRC_DIR)/*.cpp ./*.cpp /usr/lib/x86_64-linux-gnu/libbidgcc000.a -o$(TARGET)Static
$(TARGET):
$(CXX) $(CXXFLAGS) $(INCLUDES) ./*.cpp $(BASE_SRC_DIR)/lib/libbid.so $(SHARED_LIB_DIRS)/$(SHARD_LIBS) -o$(TARGET)
clean:
rm -f $(TARGET) $(TARGET)Static *.o
requested real time bars, decimal places looks as intended and most of all no segmentation fault.
RealTimeBars. 3001 - Time: 1673241105, Open: 0.87948, High: 0.87951, Low: 0.87947, Close: 0.87951, Volume: -1, Count: -1, WAP: -1
hopefully this solves others issues with this.