I have 32 bit C application(running on 64 bit system) leaking memory.
Do debug it I have downloaded valgrind 3.8.1 from http://valgrind.org/downloads/.
Did ./configure, make and make install to install valgrind.
But valgrind builds only 64 bit memcheck-amd64-linux binary.
32 bit memcheck is not getting built.
As a result I get below errors
# valgrind --tool=memcheck --time-stamp=yes -v --track-origins=yes --leak-check=yes /home/test_code32 --error-limit=no
valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory
Stracing valgrind gives me:
execve("/usr/local/lib/valgrind/memcheck-x86-linux", ["valgrind", "--tool=memcheck", "--time-stamp=yes", "-v", "--track-origins=yes", "--leak-check=yes", "/home/test_code32", "--error-limit=no"], [/* 60 vars */]) = -1 ENOENT (No such file or directory)
write(2, "valgrind: failed to start tool '"..., 94valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory
) = 94
I checked the ./configure output and it says:
checking for 32 bit build support... no
I am using gcc (SUSE Linux) 4.3.4.
Any idea how to get valgrind build 32 bit memcheck on 64 bit machine?
I have resolved the issue.
I installed 32-bit gcc support and then again built valgrind and it created the 32 bit memcheck.
I had the same issue, and resolved it by setting an environment variable:
export VALGRIND_LIB=/YourValgrindInstallDirectory/lib/valgrind
which is the direcory where valgrind missing lib is.
Try re-running your configure script with the --enable-only32bit option:
./configure --enable-only32bit
I installed the 32bit version of valgrind and it seems that it works now. The information about installing the 32bit version I took it from here
Related
I have installed msys2 and mingw64 and I am using it for programming purposes. I used Pacman to install GCCc which comes with GDB. I am having difficulty running GDB. I get the following error in two programs I am running:
(gdb) run
Starting program: C:\Users\Nick\Desktop\hwselector.exe
warning: cYgFFFFFFFF 18023CC60 0
[New Thread 18816.0x3cc0]
[New Thread 18816.0x4284]
[New Thread 18816.0x4d98]
Number of Problems: warning: cYgstd 0xffffcb90 d 3
[Thread 18816.0x3cc0 exited with code 0]
[Thread 18816.0x4e88 exited with code 0]
[Thread 18816.0x4d98 exited with code 0]
[Inferior 1 (process 18816) exited normally]
I do not know GDB internals enough to fix this problem. Does anyone know why this is happening? I am running Windows 7 Professional 64-bit edition. GDB and GCC are their respective 64 bit versions (I assume) and the latest version of MSYS64
If you used pacman -S gcc or similar to install gcc, that is not the right gcc to use. Better delete it and use pacboy -S gcc.
Also, gcc does not come with gdb. Make sure you install it separately (pacboy -S gdb), I believe you may accidentally be using a cygwin gdb.
Open your executable with DependancyWalker (http://www.dependencywalker.com/) for the same version (x86 / x64) and check if there are any missing dependancy DLLs.
In many cases where GDB couldn't give me information, DependancyWalker helped me in detecting the fact that DLLs were missing, or even loaded from the wrong location.
I scp'd a Unix executable file into my work computer and am receiving an error when trying to run it. If I type in:
./cmpDNA 4 5 0.3 > results/results4_5_0.3.txt &
where cmpDNA is my program, 4 5 0.3 are input parameters and results/results4_5_0.3.txt is my output file, this is the error I receive:
-bash: ./cmpDNA: cannot execute binary file
I compiled in on my OS X computer using g++ and made sure to include my -m32 for a 32 bit build as the target computer is 32-bit Ubuntu. Typing:
file cmpDNA
gets:
cmpDNA: Mach-O executable i386
So I'm not sure why it won't execute. I've been looking for awhile but I can't find any answers that solve my problem. All users have executable permissions as well. Here were all of my compile options if that helps:
g++ -Wall -std=gnu++0x -o cmpDNA -m32 files.cpp
Thanks!
Can not compile on OS X without using a cross compiler and run on Ubuntu. Here is the answer that I found:
Compiling C Program on OS X to Run on Ubuntu
I am installing Valgrind but encounter some problems. The info of my platform:
Linux xx-ThinkPad-X61 3.2.0-39-generic-pae #62-Ubuntu SMP Wed Feb 27 22:25:11 UTC 2013 i686 i686 i386 GNU/Linux
I follows the installation instruction of the README file in the valgrind folder.
./configure ->make -> sudo make install.
I can't understand the following reminder in the README file, I just overlooked it.
Important! Do not move the valgrind installation into a place
different from that specified by --prefix at build time. This will
cause things to break in subtle ways, mostly when Valgrind handles
fork/exec calls.
after typing "valgrind ls -l", error appears:
xx#xx-ThinkPad-X61:~/Downloads/valgrind-3.8.1$ valgrind ls -l
==7674== Memcheck, a memory error detector
==7674== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==7674== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==7674== Command: ls -l
==7674==
valgrind: Fatal error at startup: a function redirection
valgrind: which is mandatory for this platform-tool combination
valgrind: cannot be set up. Details of the redirection are:
valgrind:
valgrind: A must-be-redirected function
valgrind: whose name matches the pattern: strlen
valgrind: in an object with soname matching: ld-linux.so.2
valgrind: was not found whilst processing
valgrind: symbols from the object with soname: ld-linux.so.2
valgrind:
valgrind: Possible fixes: (1, short term): install glibc's debuginfo
valgrind: package on this machine. (2, longer term): ask the packagers
valgrind: for your Linux distribution to please in future ship a non-
valgrind: stripped ld.so (or whatever the dynamic linker .so is called)
valgrind: that exports the above-named function using the standard
valgrind: calling conventions for this platform. The package you need
valgrind: to install for fix (1) is called
valgrind:
valgrind: On Debian, Ubuntu: libc6-dbg
valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo
valgrind:
valgrind: Cannot continue -- exiting now. Sorry.
Could someone give some suggestions?
thanks!
I also faced this error, but finally resolved in below manner.
I am having 64 bit Ubuntu 14.04, and my executable is 32 bit. When I run my 32 bit executable with valgrind I got this same error. This error was not resolved even after installing libc6-dbg (using command apt-get install libc6-dbg).
Later I found like whatever libc6-dbg present in my machine was 64 bit and valgrind requires a 32 bit libc6-dbg to run my 32 bit executable. After installing 32 bit libc6-dbg (using the command apt-get install libc6-dbg:i386) it started working.
Valgrind indicates it cannot work because it is missing the libc debug info,
and it indicates which package has to be installed to solve that.
In your case (Ubuntu), you must install
libc6-dbg
apt install -y libc6-dbg
It worked for me. (Note: without :i386.)
A hunch is that Valgrind might have upgraded to 64-bit since the answer
by rashok was written.
I'm setting up a new build server. I can't get the project to build because of this error running 32 bit msbuild:
(Build target) ->
ASPNETCOMPILER : error ASPCONFIG: Could not load file or assembly 'System.Data' or one of its dependencies. An attempt was made to load a program with an incorrect format. [c:\code\Mobile.metaproj]
The 32 bit msbuild calls:
c:\code>C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /Mobile -p Mobile\ -f -d PrecompiledWeb\Mobile\
I found one way around it by using the 64 bit version:
E:\code>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_compiler.exe -v /Mobile -p Mobile\ -f -d PrecompiledWeb\Mobile\
Using the 64 bit version of msbuild the mobile site builds fine but then silver light project will not build.
It's a catch 22!!!
How do I tell the 32 bit msbuild to call the 64 bit aspnet_compiler?
How to I correct the 32 bit aspnet_compiler?
How can I install X-Sendfile apache module so that MAMP can use it?
I have followed these instructions to install X-Sendfile, but it didn't work (it seems like it just installed it for the default apache installation). I also tried to manually copy /usr/libexec/apache2/mod_xsendfile.so to /Applications/MAMP/Library/modules/, but that produced the following error when restarting Apache:
Cannot load /Applications/MAMP/Library/modules/mod_xsendfile.so into server: cannot create object file image or add library
naabster's answer is correct if your MAMP binary is built for the same architecture as your kernel. The problem you're having might be that MAMP is not built using the same architecture -- I have Lion running here (10.7.3) with XAMPP 1.7.3 and I just ran across the same issue you were having.
Here's how I figured out what was wrong on my system, and how I fixed it. If your issue is the same as mine, then you should be able to follow along and verify as you go.
First, here's the output of 'uname -a' to show you that what I'm running:
Darwin Tads-Mac-Pro.local 11.3.0 Darwin Kernel Version 11.3.0:
Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
Here are the steps I took to track down the problem and fix it:
Figure out what attributes the other (working) modules had that my freshly-built xsendfile module was missing. I picked mod_headers.so as an example. The command to find that info is 'file [filename]'. I'm running this from a terminal cd'd to the /Applications/XAMPP/xamppfiles/modules directory:
file mod_headers.so
mod_headers.so: Mach-O universal binary with 2 architectures
mod_headers.so (for architecture i386): Mach-O bundle i386
mod_headers.so (for architecture ppc): Mach-O bundle ppc
As you can see, XAMPP kindly provides a universal binary that supports i386 and ppc architectures. However, because the Lion kernel is running x86_64, everything I build using apxs unless I tell it to otherwise will be x86_64.
Check the mach-o bundle type and architecture(s) supported by the module that was built with the recommended apxs build command ('sudo apxs -cia mod_xsendfile.c'). Because we're passing '-i' the apxs will install the .so into the default apache modules dir ... /usr/libexec/apache2...
file /usr/libexec/apache2/mod_xsendfile.so
/usr/libexec/apache2/mod_xsendfile.so: Mach-O 64-bit bundle x86_64
Just to double-check that this is the problem you can also look at the httpd (apache) binary:
file /Applications/XAMPP/xamppfiles/bin/httpd
/Applications/XAMPP/xamppfiles/bin/httpd: Mach-O universal binary with 2 architectures
/Applications/XAMPP/xamppfiles/bin/httpd (for architecture i386): Mach-O executable i386
/Applications/XAMPP/xamppfiles/bin/httpd (for architecture ppc): Mach-O executable ppc
Well now, that certainly will not work with an apache instance built without an x86_64 image. Trust, but verify, eh!
Now that I'm certain I understand the issue, let's re-build the .so with the proper architecture forced on the apxs command line. To do that I'm just adding two new params, Wl (linker flags) and Wc (compiler flags). The -i means 'install' (move .so into the modules directory) and the -a means 'activate' (add or re-enable LoadModule line in the httpd.conf)
sudo apxs -cia -Wl,"-arch i386" -Wc,"-arch i386" mod_xsendfile.c
re-check that our new .so supports an architecture that matches the Apache installed (i386, not x86_64)
file /Applications/XAMPP/xamppfiles/modules/mod_xsendfile.so
/Applications/XAMPP/xamppfiles/modules/mod_xsendfile.so: Mach-O bundle i386
Awesome. Now then, copy this turkey into the XAMPP install dir:
sudo cp /usr/libexec/apache2/mod_xsendfile.so /Applications/XAMPP/xamppfiles/modules/
And add the LoadModule line to the /Applications/XAMPP/xamppfiles/etc/httpd.conf.
LoadModule xsendfile_module modules/mod_xsendfile.so
You should be able to fire up the server using either the UI or the apachectl script found in the xamppfiles/bin directory.
Hope that helps you.
Also, I did a pretty decent due-diligence search and found just about squat looking for 'XAMPP X-SendFile cannot create object' in the Goog. What I did find was your question here, once I eliminated the 'XAMPP' since I was searching for 'XAMPP', not 'MAMP'
I started out with the 'x'AMP stack something like 10 years back using LAMPP, then WAMPP but the ApacheFriends guys call theirs XAMPP now for all of the platforms they support. I prefer using theirs since I know if I have to set up on a Windows server I can just download the same package that I use now but for Windows and I can expect to find all of the same servers installed without (too many) surprises.
So, just to be (very) thorough, the other way to discover these types of problems more easily is via Console.app. Open that up, filter on org.apache.httpd and you should see something similar to this:
httpd: Syntax error on line 117 of /private/etc/apache2/httpd.conf: Cannot load
/usr/libexec/apache2/mod_xsendfile.so into server:
dlopen(/usr/libexec/apache2/mod_xsendfile.so, 10): no suitable image found.
Did find:\n\t/usr/libexec/apache2/mod_xsendfile.so: mach-o, but wrong architecture
You can also get that from a command line when you start the apache server manually:
sudo apachectl -E /tmp/foo.txt -k start; tail -f /tmp/foo.txt
This worked for me:
Install mod_xsendfile according to this for the default OsX Apache server.
copy /usr/libexec/apache2/mod_xsendfile.so to /Applications/MAMP/Library/modules/
Edit the Mamp httpd.conf file and add this line: LoadModule xsendfile_module modules/mod_xsendfile.so
Restart Mamp