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?
Related
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 ?
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.
The instructions to javapackager just above Example 2-1 in the Java SE Deployment Guide/Self-Contained Application Packaging state that a jar file is required in the -deploy command.
If I use a modular jar, I get this error message:
Exception: java.lang.Exception: Error: Modules are not allowed in srcfiles: [dist\tcdmod.jar].
If I use the equivalent non-modular jar, the resulting package includes the complete runtime. But I want to use the reduced runtime I made with jlink that is in the /dist folder.
Can the javapackager command deploy with a jlink-generated runtime?
How?
The section titled "Customization of the JRE" makes no mention of the javapackager command.
The following section "Packaging for Modular Applications" has a following line:
Use the Java Packager tool to package modular applications as well as non-modular applications.
Is the Java Packager tool distinct from javapackager? There are no examples using javapackager in this section.
Here is the javapacker command that I used:
javapackager -deploy -native -outdir packages -outfile ToneCircleDrone -srcdir dist -srcfiles tcdplain.jar -appclass com.adonax.tanpura.TCDLaunch -name "ToneCircleDrone" -title "ToneCircleDrone test"
The instructions in the javapackager documentation make no mention of the scenario where a jlink runtime is used. There is a Bundler argument -Bruntime but it is only used to point to an installed runtime other than the system default, AFAIK.
The javapackager provided with JDK 9 and up uses jlink to generate the jre image:
For self-contained applications, the Java Packager for JDK 9 packages
applications with a JDK 9 runtime image generated by the jlink tool. To
package a JDK 8 or JDK 7 JRE with your application, use the JDK 8 Java
Packager.
https://docs.oracle.com/javase/9/tools/javapackager.htm#JSWOR719
You can even pass arguments to jlink using -BjlinkOptions=<options>
Additionally, -Bruntime is only valid for packages deployed using -deploy -native jnlp
For compiling a modular application, instead of -srcdir, use --module-path <dir>, and then specify the main module using -m <module name>.
EDIT: While there is no documentation on -BjlinkOptions, it is present in the javapackager source
jdk.packager/jdk.packager.internal.legacy.JLinkBundlerHelper
https://github.com/teamfx/openjfx-10-dev-rt/blob/bf971fe212e9bd14b164e4c1058bc307734e11b1/modules/jdk.packager/src/main/java/jdk/packager/internal/legacy/JLinkBundlerHelper.java#L96
Example Usage: -BjlinkOptions=compress=2 will make javapackager run jlink with the --compress=2 flag, generating the JRE image with Zip Level compression.
Aditionally, running javapackager with the flag -Bverbose=true will show you exactly which arguments are being passed to jlink with a line in the output something like this:
userArguments = {strip-debug=1 compress=2}
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
I'm trying to connect to MySQL using MATLAB R2009b 64 bit and the mysql.cpp file found on the FEX and here. I followed all the steps to compile listed in the second link. After entering the following:
mex -I"C:\mysql\include" -DWIN32 mysql.cpp "C:\mysql\lib\opt\libmySQL.lib"
the mysql.mexw64 file is created in my working directory. However, when I go to test it, I get the following error:
>> mysql('status')
??? Invalid MEX-file 'C:\[path]\mysql.mexw64': C:\[path]\mysql.mexw64 is not a valid Win32 application.
I tried switching out the -DWIN32 with -DWIN64, but that just threw all sorts of errors. Anyone have a suggestion as to why this isn't working?
I'm using MATLAB R2009b 64 bit on Windows 7 64 bit.
libmysql.dll is a 32-bit library. Matlab 64-bit wants mex-files to be compiled in 64-bit mode. Unless you can recompile the library, you won't be able to get the mex-file to work, I'm afraid.