I'm getting strange results with GStreamer 1.20.3 compiled from sources.
Target platform is RHEL8 with GCC12 (official Docker image was used as the base one).
Python 3.8, Meson and Ninja were installed so compilation/linking passes without any errors.
But when I'm trying to check if all is Ok, I see this:
# ./gst-inspect-1.0
staticelements: bin: Generic bin
staticelements: pipeline: Pipeline object
Total count: 4 plugins (1 blacklist entry not shown), 2 features
So the tool does not see any plugins.
GStreamer is compiled like this (I plan to use static library):
...
ENV INSTALL_DIR_GSTREAMER=/app/install/gstreamer
RUN meson setup --prefix=$INSTALL_DIR_GSTREAMER --default-library=static ./build
RUN ninja -C ./build
RUN ninja -C ./build install
...
I saved full log and see only one fatal in it. Not sure that it's a reason of the problem but still:
#29 345.7 Cloning into 'pygobject'...
#29 349.9 HEAD is now at 63825d8e release
#29 350.0 Cloning into 'gobject-introspection'...
#29 351.0 warning: Could not find remote branch master to clone.
#29 351.0 fatal: Remote branch master not found in upstream origin
On checking https://gitlab.gnome.org/GNOME/gobject-introspection I found the main branch which is probably just the new name of master.
But this error is strange enough because I found only one dependency on gobject-introspection in pango and in the .wrap file the branch name for gobject-introspection is specified properly as revision=main.
Also I tried to stream WAV file from Docker with gst-launch-1.0 and it also fails with unable to create pipeline and multifile plugin not found.
On checking configuration summary in the log I see all base, good, bad plugins:
...
#29 356.1 gst-plugins-good 1.20.3
#29 356.1
#29 356.1 Plugins: alpha, alphacolor, apetag, audiofx, audioparsers, auparse,
#29 356.1 autodetect, avi, cutter, navigationtest, debug, deinterlace, dtmf,
#29 356.1 effectv, equalizer, flv, flxdec, goom, goom2k1, icydemux,
#29 356.1 id3demux, imagefreeze, interleave, isomp4, alaw, mulaw, level,
#29 356.1 matroska, monoscope, multifile, multipart, replaygain, rtp,
#29 356.1 rtpmanager, rtsp, shapewipe, smpte, spectrum, udp, videobox,
#29 367.6 videocrop, videofilter, videomixer, wavenc, wavparse, y4menc,
#29 367.6 ossaudio, oss4, video4linux2, ximagesrc, cairo, jpeg, lame, dv,
#29 367.6 png, soup
...
So there are 2 main questions:
How to fix the gobject-introspection problem (I suspect somewhere in the sub-project there's a .wrap file with revision=master, but where it is)?
What else to check to understand why GStreamer tools are not working?
Any help is appreciated.
Related
For example, take the following minimal example:
#include <cstdio>
#include <stdexcept>
int main(int argc, char* argv[]){
#ifdef __GLIBCPP__
std::printf("GLIBCPP: %d\n",__GLIBCPP__);
#endif
#ifdef __GLIBCXX__
std::printf("GLIBCXX: %d\n",__GLIBCXX__);
#endif
throw std::runtime_error("Were are libstdc++.so.6 debug symbols?");
return 0;
}
When running it inside my gdb, it does not show the debug symbols for libstdc++.so.6:
$ g++ -o testmain test.cpp -ggdb --std=c++98 && gdb ./testmain
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
...
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./testmain...
(gdb) r
Starting program: /home/user/Downloads/testmain
GLIBCXX: 20200408
terminate called after throwing an instance of 'std::runtime_error'
what(): Were are libstdc++.so.6 debug symbols?
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt f
#0 __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0, 0, 0, 0, 0, 0, 0, 0, 29295, 0, 0, 0, 0, 0, 0, 0}}
pid = <optimized out>
tid = <optimized out>
ret = <optimized out>
#1 0x00007ffff7be1859 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = ... <stderr>}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00007ffff7e67951 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#3 0x00007ffff7e7347c in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#4 0x00007ffff7e734e7 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#5 0x00007ffff7e73799 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#6 0x000055555555524a in main (argc=1, argv=0x7fffffffdef8) at test.cpp:11
No locals.
(gdb)
It just shows No symbol table info available for the libstdc++.so.6 frames.
How can I show the symbols for the libstdc++.so.6?
Searching on this list https://packages.ubuntu.com/search?keywords=libstdc%2B%2B6, I already tried installing the following packages, but none of them fixed the problem:
libgcc-10-dev:amd64 <none> 10.2.0-5ubuntu1~20.0
libstdc++-10-dev:amd64 <none> 10.2.0-5ubuntu1~20.0
libstdc++6-10-dbg:amd64 <none> 10.2.0-5ubuntu1~20.0
libc6-amd64-cross:all <none> 2.31-0ubuntu7cross
linux-libc-dev-amd64-cross:all <none> 5.4.0-21.25cross
libc6-dev-amd64-cross:all <none> 2.31-0ubuntu7cross
libstdc++6-amd64-cross:all <none> 10.2.0-5ubuntu1~20.04cross
libgcc-10-dev-amd64-cross:all <none> 10.2.0-5ubuntu1~20.04cross
libstdc++-10-dev-amd64-cross:all <none> 10.2.0-5ubuntu1~20.04cross
libstdc++6-10-dbg-amd64-cross:all <none> 10.2.0-5ubuntu1~20.04cross
libx32stdc++6-10-dbg:amd64 <none> 10.2.0-5ubuntu1~20.0
Related questions:
How do you find what version of libstdc++ library is installed on your linux machine?
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.1 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.1 LTS"
VERSION_ID="20.04"
Update 1
$ dpkg --list | grep libstdc++6
ii libstdc++6:amd64 10.2.0-5ubuntu1~20.04 amd64 GNU Standard C++ Library v3
ii libstdc++6-10-dbg-amd64-cross 10.2.0-5ubuntu1~20.04cross1 all GNU Standard C++ Library v3 (debug build) (amd64)
ii libstdc++6-7-dbg:amd64 7.5.0-6ubuntu2 amd64 GNU Standard C++ Library v3 (debug build)
ii libstdc++6-amd64-cross 10.2.0-5ubuntu1~20.04cross1 all GNU Standard C++ Library v3 (amd64)
Update 2
$ dpkg --list | grep libstdc++6
ii libstdc++6:amd64 10.2.0-5ubuntu1~20.04 amd64 GNU Standard C++ Library v3
ii libstdc++6-10-dbg:amd64 10.2.0-5ubuntu1~20.04 amd64 GNU Standard C++ Library v3 (debug build)
ii libstdc++6-10-dbg-amd64-cross 10.2.0-5ubuntu1~20.04cross1 all GNU Standard C++ Library v3 (debug build) (amd64)
ii libstdc++6-amd64-cross 10.2.0-5ubuntu1~20.04cross1 all GNU Standard C++ Library v3 (amd64)
Background Story:
Days ago, I was also curious about the same question as yours. But that's on CentOS.
What can I do differently after I install those missing debug info packages for gdb?
You can check the question to see what I learnt during searching, I solve your question with those prior knowledge.
In short, for the same thing, in CentOS the difficulties come down to installing the debug info packages. Because the gdb in CentOS tells what exact version of some debug info files you need to install and it gives the full command.
debuginfo-install glibc-2.17-307.el7.1.x86_64 libgcc-4.8.5-44.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64
But this command just can't work and you need to manually add some package sources to install that .
However, as soon as you succeed installing the debug info packages, everything else is set up nicely, even the source files! You can s step into e.g. abort() and list around the source code!
In Ubuntu:
You have to find the exact version of your libstdc++.so.xxx and install the corresponding debug info files.
No libarary(e.g. libstdc++) source files will be installed and set up after install the corresponding debug info files packages. But you can manually do it with set substitute-path.
Answer Part:
I made my gdb work under Ubuntu 18.04.5 LTS. I think that may applies to yours too.
I assume you know this https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html .
So firstly I ldd my.a.out.
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fbfa6f84000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbfa697b000)
...
In my Ubuntu, reading debug symbol for libc.so.6 is successful. So I want to check both .so files' .gnu_debuglink section.
libc.so.6 is a link to libc-2.27.so
so I read the above section with readelf -x.gnu_debuglink libc-2.27.so and gives me:
Hex dump of section '.gnu_debuglink':
0x00000000 6c696263 2d322e32 372e736f 00000000 libc-2.27.so....
0x00000010 32e033a0 2.3.
This means its debug info file's name is libc-2.27.so, which exists in /usr/lib/debug/lib/x86_64-linux-gnu directory.
Now check libstdc++.so.6, which is a link to libstdc++.so.6.0.25 in my machine.
readelf -x.gnu_debuglink libstdc++.so.6.0.25 gives:
Hex dump of section '.gnu_debuglink':
0x00000000 31313961 34346139 39373538 31313436 119a44a997581146
0x00000010 32306338 65396438 65323433 64373039 20c8e9d8e243d709
0x00000020 34663737 66362e64 65627567 00000000 4f77f6.debug....
0x00000030 30573da0 0W=.
This 119a44a99758114620c8e9d8e243d7094f77f6.debug is a build-id debug file.
Learnt from your question and comments below, I do dpkg --list | grep libstdc++ and shows
ii libstdc++-7-dev:amd64 7.5.0-3ubuntu1~18.04 amd64 GNU Standard C++ Library v3 (development files)
ii libstdc++-8-dev:amd64 8.4.0-1ubuntu1~18.04 amd64 GNU Standard C++ Library v3 (development files)
ii libstdc++6:amd64 8.4.0-1ubuntu1~18.04 amd64 GNU Standard C++ Library v3
ii libstdc++6:i386 8.4.0-1ubuntu1~18.04 i386 GNU Standard C++ Library v3
So I sudo apt install libstdc++6-8-dbg.
Then I used dpgk-query -L libstdc++6-8-dbg to see what files are installed with this packages.
tianhe#tianhe-windy:/lib/x86_64-linux-gnu$ dpkg -L libstdc++6-8-dbg
/.
/usr
/usr/lib
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/f2
/usr/lib/debug/.build-id/f2/119a44a99758114620c8e9d8e243d7094f77f6.debug
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/debug
/usr/lib/x86_64-linux-gnu/debug/libstdc++.a
/usr/lib/x86_64-linux-gnu/debug/libstdc++.so.6.0.25
/usr/lib/x86_64-linux-gnu/debug/libstdc++fs.a
/usr/share
/usr/share/doc
/usr/share/gdb
/usr/share/gdb/auto-load
/usr/share/gdb/auto-load/usr
/usr/share/gdb/auto-load/usr/lib
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/debug
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/debug/libstdc++.so.6.0.25-gdb.py
/usr/lib/x86_64-linux-gnu/debug/libstdc++.so
/usr/lib/x86_64-linux-gnu/debug/libstdc++.so.6
/usr/share/doc/libstdc++6-8-dbg
And I think I got the debug files when I saw this line:
/usr/lib/debug/.build-id/f2/119a44a99758114620c8e9d8e243d7094f77f6.debug.
Then I open gdb again and it works. I can now s step into string s = "hello";.
So try check what I describe above see if they match.
I followed these instructions https://www.hiroom2.com/ubuntu-2004-dbgsym-en/.
Adding the debug symbols repo:
#!/bin/sh -e
U=http://ddebs.ubuntu.com
C=$(lsb_release -cs)
cat <<EOF | sudo tee /etc/apt/sources.list.d/ddebs.list
deb ${U} ${C} main restricted universe multiverse
#deb ${U} ${C}-security main restricted universe multiverse
deb ${U} ${C}-updates main restricted universe multiverse
deb ${U} ${C}-proposed main restricted universe multiverse
EOF
wget -O - http://ddebs.ubuntu.com/dbgsym-release-key.asc | \
sudo apt-key add -
sudo apt update -y
Then install symbols for libstdc++6
sudo apt-get install libstdc++6-dbgsym
In addtion to #Rick's answer.
In ubuntu 20.04+, you need to install libstdc++6-dbgsym, and before this you need to add debug symbol repo to apt.
To get the source code, you should run apt source libstdc++6, then run ./debian/rules patch as described in debian/README.source.
(Personally I feel installing debug info and source code in ubuntu is much more complex than centOS. I suggest you to use centOS if you just want to have a look into libstdc++'s source code.
I am working with DPDK version 18.11.8 stable on Linux, using a gcc x64 build.
At runtime I get a segmentation fault. Running gdb on the core dump gives this backtrace:
#0 0x0000000000f65680 in rte_eth_devices ()
#1 0x000000000048a03a in rte_eth_rx_burst (nb_pkts=7,
rx_pkts=0x7fab40620480, queue_id=0, port_id=<optimized out>)
at
/opt/dpdk/dpdk-18.08/x86_64-native-linuxapp-gcc/include/rte_ethdev.h:3825
#2 Socket_poll (ucRxPortId=<optimized out>, ucRxQueId=ucRxQueId at entry=0
'\000', uiMaxNumOfRxFrm=uiMaxNumOfRxFrm at entry=7,
pISocketListener=pISocketListener at entry=0xf635d0 <FH_gtFrontHaulObj+16>)
at /data/<snip>/SocketClass.c:2188
#3 0x000000000048b941 in FH_perform (args_ptr=<optimized out>) at
/data/<snip>/FrontHaul.c:281
#4 0x00000000005788e4 in eal_thread_loop ()
#5 0x00007fab419fae65 in start_thread () from /lib64/libpthread.so.0
#6 0x00007fab4172388d in clone () from /lib64/libc.so.6
So it seems that rte_eth_rx_burst() calls rte_eth_devices () and that function crashes, presumably because of an illegal memory access. Possibly a hugepages problem?
I want to enable more debug info in DPDK. I am building DPDK using:
usertools/dpdk-setup.sh
Am I correct in thinking that the build commands in that script use make and I should modify the appropriate:
config/defconfig_*
file (defconfig_x86_64-native-linuxapp-gcc in my case) ?
If so, would these values be appropriate?
CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=y
RTE_LOG_LEVEL=RTE_LOG_DEBUG
RTE_LIBRTE_ETHDEV_DEBUG=y
(not sure whether all values should be prefixed by 'CONFIG_'?)
I tried building DPDK using:
$ export EXTRA_CFLAGS='-O0 -g'
$ make install T=x86_64-native-linuxapp-gcc
but that gave no extra info in the backtrace.
EDIT: error is identified update is Fixed and running without crashing now
using chat room dpdk-debug, we were able to rebuild the libraries and application with proper CFLAGS. Using gdb have identified the probable cause is in rte_eth_rx_burst not being passed with pointer array for mbuf.
Based on the GDB details for frame 1, it looks the application is not build with the EXTRA_CFLAGS (assuming you are using DPDK example Makefile). The right way to build an DPDK application for debugging is to follow the steps as
cd [dpdk target folder]
make clean
make EXTRA_CFLAGS='-O0 -ggdb'
cd [application folder]
make EXTRA_CFLAGS='-O0 -ggdb'
then use GDB in TUI or non-TUI mode to analyze the error.
note:
one of the most common mistakes I commit in rx_burst, is passing *mbuf_array instead of **mbuf_array as the argument.
if custom Makefile is used for the application, pass the EXTRA_CFLAGS as CFLAGS+="-O0 -ggdb"
On running
flutter build appbundle I am getting the following error:
Gradle build failed to produce an Android bundle package.
When running in verbose mode this is what I additionally get:
#0 throwToolExit (package:flutter_tools/src/base/common.dart:24:3)
#1 _buildGradleProjectV2 (package:flutter_tools/src/android/gradle.dart:585:7)
<asynchronous suspension>
#2 buildGradleProject (package:flutter_tools/src/android/gradle.dart:331:14)
<asynchronous suspension>
#3 buildAppBundle (package:flutter_tools/src/android/app_bundle.dart:43:10)
<asynchronous suspension>
#4 BuildAppBundleCommand.runCommand (package:flutter_tools/src/commands/build_appbundle.dart:43:11)
<asynchronous suspension>
#5 FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:545:18)
#6 _asyncThenWrapperHelper.<anonymous closure> (dart:async/runtime/libasync_patch.dart:77:64)
#7 _rootRunUnary (dart:async/zone.dart:1132:38)
#8 _CustomZone.runUnary (dart:async/zone.dart:1029:19)
#9 _FutureListener.handleValue (dart:async/future_impl.dart:126:18)
#10 Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:639:45)
#11 Future._propagateToListeners (dart:async/future_impl.dart:668:32)
#12 Future._complete (dart:async/future_impl.dart:473:7)
#13 _SyncCompleter.complete (dart:async/future_impl.dart:51:12)
#14 _AsyncAwaitCompleter.complete.<anonymous closure> (dart:async/runtime/libasync_patch.dart:33:20)
#15 _rootRun (dart:async/zone.dart:1124:13)
#16 _CustomZone.run (dart:async/zone.dart:1021:19)
#17 _CustomZone.bindCallback.<anonymous closure> (dart:async/zone.dart:947:23)
#18 _microtaskLoop (dart:async/schedule_microtask.dart:41:21)
#19 _startMicrotaskLoop (dart:async/schedule_microtask.dart:50:5)
#20 _runPendingImmediateCallback (dart:isolate/runtime/libisolate_patch.dart:115:13)
#21 _RawReceivePortImpl._handleMessage (dart:isolate/runtime/libisolate_patch.dart:172:5)
I am on Flutter stable channel v1.2.1.
I can build an apk without a problem though.
I can also build an appbundle from another Flutter project.
Based on the error messages above how would you start to find the issue?
What might be the problem here?
I have similar issue with the same error messages.
(Build Release APK successfully but failed to build app bundle)
The solution that works for me is to upgrade the Android Gradle Version.
Below are the config that works for me (You may upgrade to the latest version also):
/android/gradle/wrapper/gradle-wrapper.properties:
distributionUrl=https\://services.gradle.org/distributions/gradle-4.10.2-all.zip
/android/build.gradle:
buildscript {
repositories {
google()
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:3.2.1'
}
}
I commented list of APIs in app.gradle and then it works:
android {
splits {
abi {
//include "x86", "x86_64", "armeabi", "armeabi-v7a", "arm64-v8a"
}
}
}
There is a multitude of reasons for which you might encounter a frustrating problem like Gradle build failed to produce an Android bundle package.
As of #Tam Tam Tam's answer, first try to update your gradle and android gradle plugin to a latest version.
If that does not fix your problem, then try to disable all the different architectures and set universalApk to false in your android/app/build.grade in splits section. Put something like this:
splits {
abi {
enable true
reset()
// include 'x86', 'armeabi-v7a', 'x86_64'
universalApk false
}
}
This suggestion was provided here:
https://github.com/flutter/flutter/issues/27462#issuecomment-507229131
It happens because gradle generates the apk following a convention, eg, app-<architecture-name>.apk, which is not understandable by flutter, it expects apk names in another format, eg, simply app.apk. Disabling all different architectures name bring them to a common understanding :)
If that is also not work, then try to remember if you change your package name com.example.packagename to something your own personal like com.mywebsite.packagename. If you have done it, then you probably changed it everywhere needed, for example, in build.gradles and AndroidManifest.xml but you might forgot to change it in your java (or kotlin class).
To make your new package name works, you also have to change the package name in src/main/java/com/mywebsite/packagename/MainActivity.java (in case of kotlin, it's src/main/kotlin/com/mywebsite/packagename/MainActivity.kt)
I hope this helps.
Here is my senario:
I'm using a remote machine from CI to sign apk with release sign config.
So I removed buildTypes.release.signConfig in build.gradle like this:
buildTypes {
release {
// signingConfig signingConfigs.release
minifyEnabled true
useProguard true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
This makes the name of the output apk change to app-release-unsigned.apk but flutter expects app-release.apk, which leads to Gradle build failed to produce an Android bundle package.
After adding signingConfig signingConfigs.release back the problem was solved.
I lost some part of the config of the default project.gradle
rootProject.buildDir = '../build'
subprojects {
project.buildDir = "${rootProject.buildDir}/${project.name}"
}
subprojects {
project.evaluationDependsOn(':app')
}
For me, migrating to AndroidX fixed everything:
https://flutter.dev/docs/development/packages-and-plugins/androidx-compatibility
For me, I had signingConfig signingConfigs.debug line missing in my release config of app's build.gradle file. But error I was getting is the same "Gradle build failed to produce an Android bundle package".
android {
...
buildTypes {
release {
signingConfig signingConfigs.debug
...
}
}
}
For me changing my gradle version as following line solved the issue. (I was using a higher version)
android/build.gradle
dependencies {
classpath 'com.android.tools.build:gradle:3.3.0'
}
In my case, I added flavor to my project and forgot to add flavor name to Run/Debug Configuration.
I have seen similar questions, but none of them seem to work for me. I am using the hello-world example code as a basis:
v8::V8::InitializeICUDefaultLocation(argv[0]);
v8::V8::InitializeExternalStartupData(argv[0]);
std::unique_ptr<v8::Platform> platform = v8::platform::NewDefaultPlatform();
v8::V8::InitializePlatform(platform.get());
v8::V8::Initialize();
// Create a new Isolate and make it the current one.
v8::Isolate::CreateParams create_params;
create_params.array_buffer_allocator =
v8::ArrayBuffer::Allocator::NewDefaultAllocator();
v8::Isolate* isolate = v8::Isolate::New(create_params);
The segfault happens in the last line above. I link against libv8_monolith. I get the following abort:
Thread 1 "hiram-renderer-" received signal SIGSEGV, Segmentation fault.
__GI___libc_free (warning: Could not find DWO CU obj/v8_initializers/interpreter-generator.dwo(0x41869846475c35aa) referenced by CU at offset 0x18018ec [in module /home/csnelson/meps/projects/mf/renderer-hiram/.build/renderer-hiram/linux/amd64/debug/engine/hiram-renderer-engine-test]
mem=0x400000000000000) at malloc.c:3085
3085 malloc.c: No such file or directory.
(gdb) bt
#0 __GI___libc_free (mem=0x400000000000000) at malloc.c:3085
#1 0x00000000023510e8 in v8::internal::interpreter::GenerateBytecodeHandler(v8::internal::Isolate*, v8::internal::interpreter::Bytecode, v8::internal::interpreter::OperandScale, int, v8::internal::AssemblerOptions const&) () at ../../src/interpreter/interpreter-generator.cc:3304
warning: Could not find DWO CU obj/v8_initializers/setup-builtins-internal.dwo(0x2e9f81fe7c4f3a21) referenced by CU at offset 0x18010a8 [in module /home/csnelson/meps/projects/mf/renderer-hiram/.build/renderer-hiram/linux/amd64/debug/engine/hiram-renderer-engine-test]
#2 0x0000000001f648b3 in v8::internal::(anonymous namespace)::GenerateBytecodeHandler(v8::internal::Isolate*, int, char const*, v8::internal::interpreter::OperandScale, v8::internal::interpreter::Bytecode) () at ../../src/builtins/setup-builtins-internal.cc:284
#3 0x0000000001f55960 in v8::internal::SetupIsolateDelegate::SetupBuiltinsInternal(v8::internal::Isolate*) ()
at ../../src/builtins/setup-builtins-internal.cc:348
warning: Could not find DWO CU obj/v8_init/setup-isolate-full.dwo(0xe7b834785ad1ac3a) referenced by CU at offset 0x1801028 [in module /home/csnelson/meps/projects/mf/renderer-hiram/.build/renderer-hiram/linux/amd64/debug/engine/hiram-renderer-engine-test]
#4 0x0000000001f401c7 in SetupBuiltins () at ../../src/setup-isolate-full.cc:18
warning: Could not find DWO CU obj/v8_base/isolate.dwo(0xe943b1082c1ddbf9) referenced by CU at offset 0xd9abfc [in module /home/csnelson/meps/projects/mf/renderer-hiram/.build/renderer-hiram/linux/amd64/debug/engine/hiram-renderer-engine-test]
#5 0x00000000019665b3 in Init () at ../../src/isolate.cc:3363
#6 0x0000000001965cdd in v8::internal::Isolate::InitWithoutSnapshot() () at ../../src/isolate.cc:3254
warning: Could not find DWO CU obj/v8_base/api.dwo(0xbdbb31bc688b926c) referenced by CU at offset 0x1d5b0a [in module /home/csnelson/meps/projects/mf/renderer-hiram/.build/renderer-hiram/linux/amd64/debug/engine/hiram-renderer-engine-test]
#7 0x0000000001235bd7 in Initialize () at ../../src/api.cc:8205
#8 0x000000000123612f in New () at ../../src/api.cc:8217
#9 0x0000000001119b11 in main (argc=1, argv=0x7fffffffe3b8) at ../../../../../engine/test/main.cpp:28
Any help would be appreciated. I've tried a number of things, compiling with snapshots enabled and disabled and so on. Nothing seems to make any difference.
As it turns out, I was building against v8 head. I don't know if head is broken or not, since d8 and all of the test programs worked fine. However, when I compiled a minimal program taking the v8 hello world source almost verbatim the initialize hung indefinitely.
Finally, I discovered that I needed to do a full checkout of the source. Previously I was doing:
fetch --no-history v8
However, when I did a checkout of the branch:
git checkout branch-heads/7.2
And then ran:
gclient sync
It would always fail. Now I run:
fetch v8
git checkout branch-heads/7.2
gclient sync
Then I configure my build and compile. The resulting libv8_monolith.a works with both my minimal test harness and the more complete app I am trying to embed in.
There very well may be an interaction with a later v8 and something in my larger app. However, for now things are working so I hope that it's just a bug in head that is misbehaving with my environment.
I am trying to install caffe following this tutorial
Basically I have the following error when I type the last make command:
me#dl-01:/home/me/caffe-master$ make runtest
.build_release/tools/caffe
caffe: command line brew
usage: caffe command args
commands:
train train or finetune a model
test score a model
device_query show GPU diagnostic information
time benchmark model execution time
Flags from tools/caffe.cpp:
-gpu (Run in GPU mode on given device ID.) type: int32 default: -1
-iterations (The number of iterations to run.) type: int32 default: 50
-model (The model definition protocol buffer text file..) type: string
default: ""
-snapshot (Optional; the snapshot solver state to resume training.)
type: string default: ""
-solver (The solver definition protocol buffer text file.) type: string
default: ""
-weights (Optional; the pretrained weights to initialize finetuning. Cannot
be set simultaneously with snapshot.) type: string default: ""
.build_release/test/test_all.testbin 0 --gtest_shuffle
ERROR: something wrong with flag 'flagfile' in file '/root/glog-0.3.3/gflags-master/src/gflags.cc'. One possibility: file '/root/glog-0.3.3/gflags-master/src/gflags.cc' is being linked both statically and dynamically into this executable.
make: *** [runtest] Error 1
I don't understand how to solve this error. Did anybody find this error before? how can I solve it?
Whether or not you've already solved this somewhere else, I'm posting the answer here in-case others run into the same problem.
Primarily, this problem seems to have come about because we don't always read things properly and blindly follow all instructions thinking they all apply to our case. hint: they don't.
In the installation instructions for Caffe (presuming Ubuntu instructions), there is a section which states:
Everything is packaged in 14.04.
sudo apt-get install libgflags-dev libgoogle-glog-dev liblmdb-dev protobuf-compiler
Blindly ignoring the next title, which states clearly:
Remaining dependencies, 12.04
we go on to install these dependencies, building and installing as required, resulting in the unfortunate side-effect of having 2 versions of libgflags, one dynamic (in /usr/lib[/x86_x64] and one static in /usr/local/lib
Resolution
Promise ourselves failthfully we'll read instructions properly next time around.
Uninstall libgflags
sudo apt-get remove -y libgflags
Delete make install versions
sudo rm -f /usr/local/lib/libgflags.a /usr/local/lib/libgflags_nothreads.a
sudo rm -rf /usr/local/include/gflags
Clean Caffe build
cd <path>/<to>/caffe
make clean
Re-install libgflags package
sudo apt-get install -y libgflags-dev
Rebuild Caffe
make all
make test
make runtest
Et Voila. All tests should now run and you're ready to rock the deep-learning boat.
I've worked out a way to debug this issue analytically. In my case, I was cross-compiling for an older ABI, so apt-get wasn't an option and I was compiling all dependencies manually.
First let's take a look at what this issue actually is. In the Google GFlags library, flags are declared through global objects. When the global object's constructor is run, it calls into the GFlags library to register that command line flag. If the global constructor gets run multiple times (due to multiple versions of the library containing it being loaded into memory), then the GFlags register method dies with an error.
What does GLog have to do with this? Well, GLog uses GFlags, and it has globally declared flag objects. Even if GFlags is linked correctly, if the GLog library gets loaded multiple times, you get an error pointing to logging.cc in GLog.
Sounds like quite a mess, huh. Even if GLog and GFlags are linked as shared in most cases, if another library links to a static version or some other version, kaboom.
Luckily, we can debug this issue using GDB and other tools, if you're willing to delve through some tricky symbol analysis.
First, you'll want to run GDB on the Python interpreter when it tries to import caffe:
gdb --args python -c 'import caffe'
Now, run the program once through so that GDB can pick up all the libraries it imports:
(gdb) r
Now, we can set a breakpoint on the place in the function (FlagRegistry::RegisterFlag()) that prints the error message, and run it again. Note that this line number is from my version of GFlags (2.2.2), you may have to look at the source code of your GFlags version and get the line number.
(gdb) break gflags.c:728
(gdb) r
Hopefully, GDB should then break on the first instance of the error (if not, check that gflags has been built with debugging symbols).
Look at the backtrace:
(gdb) bt
#0 google::(anonymous namespace)::FlagRegistry::RegisterFlag (this=0xa33b30, flag=0x1249d20) at dev/gflags-2.2.2/src/gflags.cc:728
#1 0x00007ffff0f3247a in _GLOBAL__sub_I_logging.cc () from prefix/lib/libcaffe2.so
#2 0x00007ffff7de76ca in call_init (l=<optimized out>, argc=argc#entry=3, argv=argv#entry=0x7fffffffdb08, env=env#entry=0x7fffffffdb28) at dl-init.c:72
#3 0x00007ffff7de77db in call_init (env=0x7fffffffdb28, argv=0x7fffffffdb08, argc=3, l=<optimized out>) at dl-init.c:30
#4 _dl_init (main_map=main_map#entry=0xd9c2a0, argc=3, argv=0x7fffffffdb08, env=0x7fffffffdb28) at dl-init.c:120
#5 0x00007ffff7dec8f2 in dl_open_worker (a=a#entry=0x7fffffffcf70) at dl-open.c:575
#6 0x00007ffff7de7574 in _dl_catch_error (objname=objname#entry=0x7fffffffcf60, errstring=errstring#entry=0x7fffffffcf68, mallocedp=mallocedp#entry=0x7fffffffcf5f,
operate=operate#entry=0x7ffff7dec4e0 <dl_open_worker>, args=args#entry=0x7fffffffcf70) at dl-error.c:187
#7 0x00007ffff7debdb9 in _dl_open (file=0x9aee70 "prefix/lib/python2.7/site-packages/caffe2/python/caffe2_pybind11_state.so", mode=-2147483646,
caller_dlopen=0x51bb39 <_PyImport_GetDynLoadFunc+233>, nsid=-2, argc=<optimized out>, argv=<optimized out>, env=0x7fffffffdb28) at dl-open.c:660
#8 0x00007ffff75ecf09 in dlopen_doit (a=a#entry=0x7fffffffd1a0) at dlopen.c:66
#9 0x00007ffff7de7574 in _dl_catch_error (objname=0xabf9f0, errstring=0xabf9f8, mallocedp=0xabf9e8, operate=0x7ffff75eceb0 <dlopen_doit>, args=0x7fffffffd1a0) at dl-error.c:187
#10 0x00007ffff75ed571 in _dlerror_run (operate=operate#entry=0x7ffff75eceb0 <dlopen_doit>, args=args#entry=0x7fffffffd1a0) at dlerror.c:163
#11 0x00007ffff75ecfa1 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87
#12 0x000000000051bb39 in _PyImport_GetDynLoadFunc ()
<snip>
Well that's a lot to deal with, but let's focus on the line that's actually important:
#1 0x00007ffff0f3247a in _GLOBAL__sub_I_logging.cc () from prefix/lib/libcaffe2.so
This is the call to the constructor for the global variables in logging.cc (which is part of GLog). As you can see, this call is in libcaffe2.so, meaning that GLog has been statically linked to libcaffe2.so [I was using caffe2, but this procedure should be the same for both].
You can then set a breakpoint on google::(anonymous namespace)::FlagRegistry::RegisterFlag and rerun the program from the start. Look at each call to RegisterFlag(), and figure out where this particular flag was registered the first time. If the library providing the flag is a shared library, then it should only ever get registered from that .so file, and nowhere else.
To confirm the diagnosis, you can use
nm <library> | grep _GLOBAL__sub_I_logging.cc
to check for that init function in a library file. Once you've found your culprit, you'll need to rebuild it so that it doesn't link to GFlags/GLog statically.
I also had two libraries installed, a shared .so library and a static .a library. I removed them all as well as the /usr/local/include/glog folder.
The .so file I had brought over when I (cross) compiled the system, while the .a was from a native and up-to-date build.
Ultimately it came down to building glog (natively) in such a way that it provided the .so files.
I started with a clean download:
git clone git://github.com/google/glog
Then I edited CMakeLists.txt.
Where it says:
add_library (glog
${GLOG_SRCS}
)
I changed it to:
add_library (glog SHARED
${GLOG_SRCS}
)
Next you should be able to follow the other instructions. For my particular case I had to use slightly different instructions, not saying you have to do this. For me it was:
mkdir build
cd build
export CXXFLAGS="-fPIC"
cmake ..
make
sudo make install
This gave me the .so files and put them in the right place. Then I started over with caffe and it fixed the error for me.