Trying to decr ref count of Tcl_Obj allocated in another thread - tcl

I compiled the sourceforge tcl executable, it passes all the tests supplied, and it runs with the same segfault I see in my downloaded executable, 8.6.9. I'm running on Ubuntu 16.04 (for legacy reasons) on an AMD processor. ( I have run on ubuntu 18.04 on my laptop, it has the same failure. )
So, next I recompiled with "--enable-symbols=mem" turned on to see if a memory leak is causing the segfault, and now it fails immediately with:
Trying to decr ref count of Tcl_Obj allocated in another thread
./runMeg.sh: line 3: 29972 Aborted (core dumped) ../source/main_megatron.
I'm not seeing any answer on what to do with this response, can someone advise on what this means I need to fix?
All my threads are of the form:
set graphDisplayThread [ thread::create {
after [expr {int(1000) }]
.....
puts "...Initialized graphDisplayUpdate_02 ID $c update."
thread::wait
}]
and:
thread::send $::graphDisplayThread {
incr b
graphDisplayUpdate .c
}
All shared variables are referenced AFTER mutex is captured, and through TSV variables. There are 5 threads in the application, which has no C-code in it at all. Around 2000 lines of code, in total.
The app runs thousands of cycles and then segfaults at random points with a prior ActiveState 8.6.9 pre-compiled version. So, now I'm trying to isolate the failure point with compiled SourceForge 8.6.9 memory checks as a first step, but the issue above is the first one I encounter - and it occurs immediately after starting.
Update (5/16/19 8:28 EST): New Detail to answer comments below.... This application has no C-code in it, and the Tcl_Obj error ONLY appears in the sourceForge-based, 8.6.9 compiles (2) I did myself, not the ActiveState 8.6.9 pre-built download. And the error in the sourceForge code occurs in both the twin "MEM_DEBUG" and NO-"MEM_DEBUG" builds I made in tandem and tested. Both passed all install tests.
To summarize:
sourceForge 8.6.9 compile w/MEM_DEBUG option: Tcl_Obj Abort error
sourceForge 8.6.9 compile w/o MEM_DEBUG option: Tcl_Obj Abort error
ActiveState 8.6.9 build: does not Abort, random seg fault
Why should I trust the sourceForge build I made myself, more than the ActiveState pre-built executable which does not exhibit the problem? And if we do trust the sourceForge compiled version, how do I isolate where the TclObject error is created by the offending TCL code?
Update 5/16/19#13:34EST: The same segfault appears with ActiveState 8.6.9 on Ubuntu 18.04. Haven't checked my builds of SourceForge yet to see how they behave.

By methodically hacking out code blocks and watching to see if the Tcl_Obj error dissappeared or not, I found 2 errors:
I had re-declared my mutex and cond variables more than once. Now it is declared once and referenced in all other places.
A code remnant removing a TSV was found in a place I no longer wanted it.
This also fixed the segfault.
Thanks for all the help and hints, mrcalvin.

Related

Why am I getting this cuda out of memory error on my new computer and not on the old one?

I'm currently trying to extract SIFT Features with the following package:
https://github.com/Celebrandil/CudaSift
It comes with a CMakeLists.txt, which I modified, here it is:
cmake_minimum_required(VERSION 2.6)
project(cudaSift)
set(cudaSift_VERSION_MAJOR 2)
set(cudaSift_VERSION_MINOR 0)
set(cudaSift_VERSION_PATCH 0)
set(CPACK_PACKAGE_VERSION_MAJOR "${cudaSift_VERSION_MAJOR}")
set(CPACK_PACKAGE_VERSION_MINOR "${cudaSift_VERSION_MINOR}")
set(CPACK_PACKAGE_VERSION_PATCH "${cudaSift_VERSION_PATCH}")
set(CPACK_GENERATOR "ZIP")
include(CPack)
find_package(OpenCV REQUIRED)
find_package(CUDA)
if (NOT CUDA_FOUND)
message(STATUS "CUDA not found. Project will not be built.")
endif(NOT CUDA_FOUND)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O2 -msse2 ")
list(APPEND CUDA_NVCC_FLAGS "-lineinfo;-ccbin;/usr/bin/gcc-7;--compiler-options;-O2;-D_FORCE_INLINES;-DVERBOSE_NOT; -arch=sm_75")
cuda_add_library(cudaSift SHARED
src/cudaImage.cu
src/cudaSiftH.cu
src/matching.cu
src/geomFuncs.cpp
src/mainSift.cpp
)
target_link_libraries(cudaSift ${CUDA_cudadevrt_LIBRARY} ${OpenCV_LIBS})
set(PUBLIC_HEADERS include/cudaImage.h include/cudaSift.h)
set_target_properties(cudaSift PROPERTIES PUBLIC_HEADER
"${PUBLIC_HEADERS}"
)
include(GNUInstallDirs)
install(TARGETS cudaSift
LIBRARY DESTINATION "${CMAKE_INSTALL_LIBDIR}"
PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}
)
configure_file(cudaSift.pc.in cudaSift.pc #ONLY)
install(FILES ${CMAKE_BINARY_DIR}/cudaSift.pc DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/pkgconfig)
My GPU is a GeForce RTX 2060, driver version 430.5, and after running:
mkdir build && cd build
cmake ..
sudo make -j
sudo make install
sudo ldconfig
-in order to build the package, I try to run my code and get the following error:
safeCall() Runtime API error in file </path/to/CudaSift/src/cudaImage.cu>, line 24 : out of memory.
Precisions:
I run the exact same code on another computer which has a GeForce GTX 1050, only changing in CMakeLists.txt -arch=sm_75 to arch=sm_61 and it executes just fine.
From previous questions, I think this is a compilation problem, linked to the arch=sm_** value, but I changed it and it still doesn't work.
The objects i'm passing to my GPU are images, which I'm sure aren't too big, since it works on my other computer which GPU has less memory
UPDATE:
I found the problem, the package was actually compiled properly.
Actually A tensorflow model was loaded in the code, but after deleting it, the error didn't happen again.
I don't know why though, maybe it reserved a lot of GPU memory ?

FirebaseCore 3.4.7 Module inside Google Drive pod corrupts workspace

I called today pod update and only FirebaseCore was updated from version 3.4.6 to 3.4.7. After that I am getting following error, no matter how many times I clean all the workspace, checkout again, etc. each time I get this new version I end up with the following errors while compiling:
duplicate symbol _GSDK_NSClassFromString in:
.../Pods/FirebaseCore/Frameworks/FirebaseCore.framework/FirebaseCore(overload_9ea29fd47bf44ee000bc4282b65dac06.o)
...Pods/GoogleSymbolUtilities/Frameworks/frameworks/GoogleSymbolUtilities.framework/GoogleSymbolUtilities(overload.o)
duplicate symbol _GSDK_objc_getClass in:
...Pods/FirebaseCore/Frameworks/FirebaseCore.framework/FirebaseCore(overload_9ea29fd47bf44ee000bc4282b65dac06.o)
...Pods/GoogleSymbolUtilities/Frameworks/frameworks/GoogleSymbolUtilities.framework/GoogleSymbolUtilities(overload.o)
duplicate symbol _GSDK_objc_getProtocol in:
...Pods/FirebaseCore/Frameworks/FirebaseCore.framework/FirebaseCore(overload_9ea29fd47bf44ee000bc4282b65dac06.o)
...Pods/GoogleSymbolUtilities/Frameworks/frameworks/GoogleSymbolUtilities.framework/GoogleSymbolUtilities(overload.o)
duplicate symbol _GSDK_objc_lookUpClass in:
...Pods/FirebaseCore/Frameworks/FirebaseCore.framework/FirebaseCore(overload_9ea29fd47bf44ee000bc4282b65dac06.o)
..Pods/GoogleSymbolUtilities/Frameworks/frameworks/GoogleSymbolUtilities.framework/GoogleSymbolUtilities(overload.o)
ld: 4 duplicate symbols for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Solved removing -all_load from Other Linker Flags under Build Settings
I came to this question trying to integrate AdMob in a Kivy app for iOS. Removing -all_load from Other Linker Flags , as suggested by David, does allow app to compile without errors, but app will subsequently crash when Kivy instantiates your app.
The solution for my case was to use -force_load path_to_archive for each archive library in kivy-ios/dist/lib/
Hopefully this saves someone else a bit of searching!

gdb: unknown target exception

When trying to run a program using gdb I get
[New Thread 4612.0x158c]
[New Thread 4612.0x1cb8]
[New Thread 4612.0x11e8]
[New Thread 4612.0x1190]
gdb: unknown target exception 0x406d1388 at 0x746623d2
Program received signal ?, Unknown signal.
0x746623d2 in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
I researched this and found three possible causes: (1) path environment variable not set, (2) drive not mapped, and (3) using the wrong version of gdb (32-bit or 64-bit). So I added C:\cygwin\bin to the path environment variable, typed mount and got
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
When I type show configuration get
This GDB was configured as follows:
configure --host=i686-pc-cygwin --target=i686-pc-cygwin
--with-auto-load-dir=$debugdir:$datadir/auto-load
--with-auto-load-safe-path=$debugdir:$datadir/auto-load
--with-expat
--with-gdb-datadir=/usr/share/gdb (relocatable)
--with-jit-reader-dir=/usr/lib/gdb (relocatable)
--without-libunwind-ia64
--with-lzma
--with-python=/usr (relocatable)
--without-guile
--with-separate-debug-dir=/usr/lib/debug (relocatable)
--without-babeltrace
and my computer is 32 bits, so it appears to be the correct version.
gdb itself seems to work, e.g. I can type watch followed by an address and it will set a watchpoint; gcc and g++ work fine, and the program I am debugging will start if I run it from the command line but not from gdb.
What other things should I check?
This is a special technical exception that communicates thread name to supporting debugger (Delphi RAD Studio, Visual Mess etc.). It is convenient to look at the thread list in the debugger and understand what is going on by looking at names. Threads throw this exception and instantly catch it, doing nothing in the handler. Until recent SetThreadName introduction, it was the only common way to set thread name. SetThreadName is Unicode, but SetThreadName not widely supported yet, so many libraries use supported method. It can be IME, OLE, whatever spawns threads.
I guess, gdb is aware of neither method. Just ignore this exception.
I had the same problem. I am also using x86 with eclipse mars.2 on a Vista, and by default, gdb 7.10 was downloaded by setup. I also tried all you have tried to no avail.
Lastly, I noticed the link below and upgraded gdb to 7.11 and the problem was fixed.
https://cygwin.com/ml/cygwin/2016-10/msg00243.html

Failed to build libmysql on windows using vc2008

I want to build libmysql.dll, so I got source code mysql-connector-c-6.1.6-src.zip from http://dev.mysql.com/downloads/connector/c/.
Then cmake-gui.exe to configure and generate vc 2008 sln, leave all settings default.
Then got errors and warnings when building, like this:
mysql-connector-c-6.1.6-src\include\thr_cond.h(109) : error C2065: “ETIMEDOUT”: 未声明的标识符(an unspecified identifier)
mysql-connector-c-6.1.6-src\include\thr_rwlock.h(80) : warning C4013: “TryAcquireSRWLockShared” 未定义(not defined)
mysql-connector-c-6.1.6-src\include\thr_rwlock.h(102) : warning C4013: “TryAcquireSRWLockExclusive” 未定义(not defined)
I searched the source, and find ETIMEDOUT is defined in my_pthread.h, so I include this header in thr_cond.h, but still error.
And TryAcquireSRWLockShared and TryAcquireSRWLockExclusive seem only supported on Win7 and later !
Do I have done something wrong?
How can I build libmysql?
Any help will be appreciated.
Download the previous version (6.0.2), it doesn's use the TryAcquireSRWLockShared() API function.
With a few minor tweeks, it compiles clean with MSVC 2008.
Here are the modifications (based on the extracted zip file root):
Replace line 306 of include/config-win.h with:
// avoid annoying warning
#ifndef HAVE_COMPRESS
# define HAVE_COMPRESS
#endif
Comment lines 350-367 of CMakeLists.txt (CPack instructions cause CMake to fail)
Follow instructions in BUILD.win

MIPS GCC compiling wrong MIPS release?

I'm looking to plunge into the realm of router hacking. Currently, I'm just trying to get a simple hello world to run on my router, a F7D7302 v1, running dd-wrt. cpuinfo reveals a BCM4716, and "MIPS 74K V4.0" as the cpu 'model.'
I downloaded CodeSourcery's MIPS cross-compiler. It was pretty simple to get a compiled executable from that point on. I transferred the file, chmod +x'd the file, and it didn't run.
I decided to do a big of snooping and ran 'file' on the router's busybox executable:
[root#LIENUX bin]# file /tmp/busybox
/tmp/busybox: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared libs), corrupted section header size
And running 'file' on my hello world:
[root#LIENUX bin]# file test
test: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked (uses shared libs), for GNU/Linux 2.6.16, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, not stripped
Running test on the router with static libraries caused a 100% CPU hang; running with dynamic libraries caused a 'not found' error. All appropriate permissions were set.
Anyone know what I am doing wrong?