TensorFlow core debug; missing debug symbols - tensorflow

I'm trying to learn TensorFlow's internals by stepping from its CIFAR-10 model training's python code into its core C++ code.
Using Eclipse+PyDev for step by step debugging of the python code works great, but I can't find how to step into the C++ code of the TensorFlow core.
I tried using Eclipse CDT to build the C++ code in a separate project, and attach the debugger to the python process running cifar10_train.py as described here, but the symbols are never loaded and (obviously) deferred breakpoints are never hit.
Background and setup:
I'm running on Ubuntu 14.04 LTS, installed the TensorFlow code from sources as described here and my CDT project uses a Makefile containing
bazel build -c dbg //tensorflow/cc:tutorials_example_trainer.

TensorFlow loads a library called _pywrap_tensorflow.so that includes its C API (as defined in tensorflow/tensorflow/core/client/tensor_c_api.cc ).
In my case the library loaded during runtime was located in
~/tensorflow/local/lib/python2.7/site-packages/tensorflow/python/_pywrap_tensorflow.so
but the library that was built from the local source code was located in ~/.cache/bazel/_bazel_<username>/dbb3c677efbf9967e464a5c6a1e69337/tensorflow/bazel-out/local_linux-dbg/bin/tensorflow/python/_pywrap_tensorflow.so.
Copying the locally built library over the loaded library, and attaching to the python process as defined in the question solved the problem.

Related

Cannot disable CUDA build and the process stops

Trying to build ArrayFire examples, everything goes well until I get to the CUDA ones. They are supposed to be skipped, since I have an AMD processor/GPU. However, during the build process, the CUDA section is built anyway, failing for obvious reasons, interrupting the rest of the process.
I could manually change the CMakeLists.txt files. However, is there a higher level way to let the build system (cmake) know that I do not have a CUDA compatible GPU?
It looks like the ArrayFire_CUDA_FOUND and CUDA_FOUND macros are erroneously defined on my system.
The ArrayFire CMake build provides a flag to disable the CUDA backend. Simply set AF_BUILD_CUDA to NO via -DAF_BUILD_CUDA=NO at the command line to disable CUDA.

Add the tensorflow lite static library to the buildroot cross compiler

I work on a Buildroot Embedded Linux System and I have to code Machine Learning Inference using the Tensorflow lite C++ static library. I have already built it following the tensorflow tutorial and I have got my libtensorflow-lite.a file ready to go.
But now, I don't really know how to add this static library to the cross compiler on buildroot. The buildroot user manual doesn't seem to talk about it.
I don't know if I have to create a ".mk" file or a "Config.in" file as a package or not.
Can someone help me ?

How to build TensorFlow C++ library on Windows XP 32-bit

I'm attempting to build TensorFlow's C++ library for Windows XP. While I've been able to build and use it on Windows 10, 32-bit XP isn't working. The background: I'm working on a COM module that calls fuctions from tensorflow.dll. My build environment:
Visual Studio 2017 15.7
CMake 3.11.1
TensorFlow 1.8
Windows 10
The sequence I use to build tensorflow.dll is:
Open "x64_x86 Cross Tools Command Prompt for VS 2017"
Try to force the use of functions availablbe in Win XP: set CXXFLAGS=/D_WINVER=0x0501 /D_WIN32_WINNT=0x0501
Add Git to path: set PATH=%PATH%;C:\Program Files (x86)\Git\bin
Fix CMake file for converting *.proto files to *.pb.h files as described here.
Configure CMake: cmake .. -A Win32 -T v141_xp,host=x64 -DCMAKE_SYSTEM_VERSION=7.0 -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=C:\Users\williams\AppData\Local\Continuum\Anaconda3\envs\tensorflow\python.exe -Dtensorflow_BUILD_SHARED_LIB=ON -Dtensorflow_BUILD_PYTHON_BINDINGS=OFF -Dtensorflow_WIN_CPU_SIMD_OPTIONS="/arch:IA32"
Build: cmake --build . --target tensorflow --config Release -- /fileLogger /m:1 /p:CL_MPCount=1
The last step also involves some manual labour as the build process doesn't copy .lib files from the 3rd part dependencies to where they are needed. For whatever reason, a bunch of INSTALL projects never get run so I had to do that manually each time the build would fail while looking for a missing lib file. Once that was done, the build completed successfully.
Next I copy my COM module (a DLL) and the TensorFlow DLL over to a Windows XP virtual machine for testing and try to register the COM module, but get an error LoadLibrary("MyDLL.dll") - The specified procedure could not be found. I don't know what procedure it is looking for, so the best I can offer is that Dependency Walker highlights WS2_32.DLL and tells me it can't find inet_ntop and inet_pton.
Any suggestions on how to build TensorFlow so that it doesn't use these two functions?
P.S. suggestions of "Stop using XP, its old and no longer supported" don't help here. Upgrading to Windows 10 is an absolute last resort because of the disruption it would cause at the facility where this software will be tested.
Edit 1:
These two functions inet_pton and inet_ntop were only used in one file that forms part of Google Cloud Storage support in TensorFlow. The build process generated a tensorflow_static.lib in addition to tensorflow.dll. Linking against the static version and adding a few dependencies that aren't included in tensorflow_static.lib got rid of the code using inet_* functions.
My COM module still isn't working on Windows XP though because the file tensorflow\core\platform\windows\env.cc uses functions like CloseThreadpoolWork, submit SubmitThreadpoolWork, etc. that were only introduced in Windows Vista. It looks like I'll have to replace them with something else, as I don't see an alternative implementation in TensorFlow.
Additionally, I found that tensorflow\contrib\cmake\CMakeLists.txt forces _WIN32_WINNT=0x0A00 and that CXXFLAGS is the wrong environment variable to use. Changing it to CMAKE_CXX_FLAGS at least gets my macro definitions included, FWIW.
It is almost impossible to port tensorflow to windows xp, because:
TF's platform depedent code requires some Windows APIs later than winxp such as Thread Pool API. This would possibly bypassed by using third party thread pool libs.
The nsync, protobuf and eigen, which are core parts of TF, use C++11 thread_local, which makes them unable to run-time load as dll, see https://learn.microsoft.com/en-us/cpp/parallel/thread-local-storage-tls?view=vs-2017 for details. This later feature can theoretically be replaced by old windows TLS API, which requires many modifications on TF's core framework.
Anyway, if you really need the xp support, good luck with that.
In the end I gave up on this as simply being impossible. Even replacing the thread pool functions with something from Boost didn't help. If someone else manages to get this working, I'll gladly accept that as the answer, but so far this looks impossible.

Creating a build environment to build Tensorflow apps with cmake

I am wondering if there is a definitive recipe for using cmake to build tensorflow and tensor for apps. I followed the instructions at https://github.com/cjweeks/tensorflow-cmake without much success and ended up having to build Eigen and Protobuf by hand and then copy relevant headers files into the the header file tree created by the Bazel build of Tensorflow.
I just built TF with CMake, VS2017, and CUDA 9.2, but had to make two manual changes:
Patch Half.h in Eigen
Change CUDA version from "9.0" to "9.2" in the main CMakeLists.txt.
Build has to be single threaded, otherwise VS runs out of heap (on my 16GB laptop). It takes a while and one project fails, but builds enough libraries to run all the examples I wanted.
Another problem with CMake build, vs. Bazel, is that the former rebuilds a bunch of projects (involving protobuf generated files) even when nothing there changes. Bazel is smarter and only compiles the changed code, then statically links all object files into a single executable, which is still faster than CMake build.

Cinnamon and QxtGlobalShortcut

I have a Qt5 Application, in which I have defined a QxtGlobalShortcut object. This program works as expected in KDE4 or Plasma5. However, when I run this application in Cinnamon, the global keybindings do not work.
Another application written in Qt4 which contains QxtGlobalShortcut object works properly in both KDE/Plasma and Cinnamon.
Any ideas as to what the problem could be?
I'm using debian testing.
Qt4 Version: 4.8.7
Qt5 Version: 5.6.1
QxtGlobalShortcut class is compiled from source. The same source is being used in both Qt4 and Qt5.
I had same issues. Sometimes global shortcut events are not caught if the application has no windows. Workaround is to create invisible dummy window.
Since Qxt in no longer maintained, I've created repository with some additional fixes (pull requests are welcome). This can be built as separate library.