I want to attach a process with ltrace command to trace one specific library calls. But when i used the below basic options, ltrace command throws error as below
bash-3.2$ **ltrace -l /path/libxml2.so.2.6.32 -p 26120**
failed to init breakpoints 26120
Cannot attach to pid 26120: Success
When I tried the same option with an executable ltrace is tracing the calls to that specific library (libxml2.so.2.6.32).
My server information:
2.6.18-348.6.1.el5 #1 SMP Fri Apr 26 09:21:26 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
ltrace vertion:
bash-3.2$ ltrace -V
ltrace version 0.5.
Copyright (C) 1997-2006 Juan Cespedes .
This is free software; see the GNU General Public Licence
version 2 or later for copying conditions. There is NO warranty.
I googled this error message but didn't get any useful information. From the error message I understood , the ltrace program is unable to set the breakpoint on libxml2 library. But I really don't understand why it is failing when ltrace is able to trace a sample program.
Has anyone faced this problem? Any help would be greatly appreciated.
Many Thanks,
Sakthivel
That's an ancient version of ltrace, with many known bugs. Please use latest version (0.7.3) from http://www.ltrace.org
Related
I'm trying to check the version of Make via command prompt and when I run make --version, the command just returns
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
?±?e?I?t???[?\?t?g?E?F?A?A?・. ???p??‘o?E?A?￠?A?I?\?[?X?d
?2???-???3?￠.
???A?≪?a“A’e?I?U“I?O?I“K?‡?≪?I”#‰??E?O?i?c?，, ?3?U?O?A?・.
This program built for i386-pc-mingw32
make: write error
What could be causing this?
Example
I have a gmake 4.0 from a MinGW installation, that shows no helping error messages.
For example I have this makefile:
# test.mk
all: somefile.c
Since I have no file named somefile.c present, it fails, but without any helpful message:
$ gmake -f test.mk
gmake: ***. Stop.
When I add the --debug flag I get some hints:
$ gmake -f test.mk --debug
GNU Make 4.0
Built for x86_64-w64-mingw32
Copyright (C) 1988-2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating goal targets....
File 'all' does not exist.
File 'somefile.c' does not exist.
Must remake target 'somefile.c'.
gmake: ***. Stop.
Expectation
For an older gmake 3.80 from another tool set, I get a helping message:
$ gmake-old -f test.mk
gmake-old: *** No rule to make target `somefile.c', needed by `all'. Stop.
Environment
I am running these command within a git-bash under Windows. I am getting a similar message, when calling gmake within windows cmd.
Question
Are there options for gmake or environment variables that I might set in order to get gmake 4.0 to provide helping messages like No rule to make target 'somefile.c', needed by 'all'?
Centos 6.7 machine. Have followed these instructions to install R and RStudio Server:
https://www.rstudio.com/products/rstudio/download-server/
add EPEL
install R
install RStudio Server
However, when trying to start up RStudio I see the following in /var/log/messages:
Nov 24 07:39:35 myserver rserver[14346]: ERROR R shared library (/usr/local/lib64/R/lib/libR.so) not found. If this is a custom build of R, was it built with the --enable-R-shlib option?; LOGGED FROM: int main(int, char* const*) /root/rstudio/src/cpp/server/ServerMain.cpp:402
Nov 24 07:39:35 myserver init: rstudio-server main process (14346) terminated with status 1
Nov 24 07:39:35 myserver init: rstudio-server respawning too fast, stopped
From a completely fresh install on another machine where these same installation steps work and RStudio fires up without errors, /usr/local/lib64/R/ doesn't even exist, so I'm puzzled why RStudio on the problematic machine is even looking there for the shared libraries...
Stumped! Your suggests appreciated!
Dan
When I had the same problem in the past I remember that i yes had the folder:
/usr/lib64/R/lib
with the needed libs, so i create a simbolic link:
ln -s /usr/lib64/R /usr/local/lib64/R
And it worked well, maybe your case is the same
I finally figured this out. The problem was caused by an old version of R in another location which was also in my PATH, so starting up RStudio Server was referencing libraries and executables that didn't work, or were incorrect.
My older version of R was in /usr/local/bin and was probably not installed with Yum. All good now!
In my case I had three R versions available in my system R2.15.1 and R3.1.0 the third one was installed using alternative option /usr/local/R/3.1.0. I just copied /usr/lib64/R/lib/libR.so to /usr/local/R/3.1.0/lib64/R/lib/ and it worked.
I'm on Mac OS X 10.10.
I notice that my hard-disk is filling up because every few minutes a new core dump file appears in /cores:
$ ls -alhtr /cores
total 3551488
-rw-r--r--# 1 saqib admin 6.0K Apr 24 12:38 .DS_Store
drwxr-xr-x 32 root admin 1.1K Aug 1 17:00 ../
-r-------- 1 saqib admin 578M Aug 1 22:36 core.35049
-r-------- 1 saqib admin 578M Aug 1 22:37 core.35202
drwxrwxr-t# 6 root admin 204B Aug 1 22:38 ./
-r-------- 1 saqib admin 578M Aug 1 22:38 core.35438
But I have no clue which processes are creating these core files. The numbers in the file names are supposed to represent the PIDs of the processes that created them. But of course those processes are now dead. So how can I figure out which process is creating these cores so that I can fix/remove it?
EDIT 1
Doing gdb -c on the core file doesn't give me the information I need:
$ gdb -c /cores/core.35438
GNU gdb (GDB) 7.8.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin14.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
"/cores/core.35438": no core file handler recognizes format
(gdb)
EDIT 2
file doesn't seem to work either:
$ file /cores/core.35049
/cores/core.35049: Mach-O core i386
EDIT 3
I opened the core file using an application called MachOView. You can see the screenshot of what it showed me. I still couldn't figure out which app created this core file.
Run the Console utility, found in /Applications/Utilities. Look under DIAGNOSTIC AND USAGE INFORMATION for User Diagnostic Reports and System Diagnostic Reports. There should be an entry for each recent crash, with the name of the program, date, time, and host name. You can click on each of these for additional information.
You can also just access the diagnostic reports directly in the file system. User Diagnostic Reports are in ~/Library/Logs/DiagnosticReports/ and System Diagnostic Reports are in /Library/Logs/DiagnosticReports/.
If the system have a gdb installed, you can use gdb -c .. command:
gdb -c core.35049
You will get the output like follow:
GNU gdb (Ubuntu 7.9-1ubuntu1) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
[New LWP 2905]
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
By reading that, you will see the core was generated by a.out program.
UPDATE
Using file, you can also get similar information:
$ file core
core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './a.out'
I just needed to do this on OS X 10.13 and using the image list command in lldb worked for me.
lldb -c /cores/core.45943
(lldb) target create "/cores/core.45943"
Core file '/cores/core.45943' (i386) was loaded
(lldb) image list
I'm installing Apache Spark which uses its own copy of SBT to set things up.
I'm using Linux Mint in a VirtualBox VM.
Here's a snippet from the error when I run sudo ./sbt/sbt compile from the Spark directory spark-0.9.0-incubating:
[error] (core/compile:compile) java.io.IOException: Cannot run program "javac": error=2, No such file or directory
[error] Total time: 181 s, completed Mar 9, 2014 12:48:03 PM
I can run java and javac from the command line just fine: e.g. javac -version gives javac 1.6.0_31
The correct jdk1.6.0_31/bin is in my PATH.
I read that the error might be due to the 64-bit JDK that I had installed, but I get the same error with the 32 bit JDK.
How can I sort out the issue?
edit: Using bash shell.
DISCLAIMER I'm mostly guessing now and still am unsure I should've responding here rather than adding a comment. Until it's clear, the DISCLAIMER remains.
When you execute java and javac from the command line, what user are you at that moment? I'm pretty sure your problems surface because the users you operate are different.
Please notice that you're executing sudo ./sbt/sbt compile as root (due to the way sudo works), but you say nothing about what user(s) you've been using to execute javac and java commands.
Add jdk1.6.0_31/bin to PATH for root and you'll be all set (as far as the configuration of Java's concerned).
I'd also recommend setting JAVA_HOME to point to jdk1.6.0_31 as it may help at times -- many applications are using it as the way to find the location of Java.
As a workaround, you may edit ./sbt/sbt and add PATH and JAVA_HOME appropriately.
You need to include the javac executable. To do this in Ubuntu please run the following command:
sudo apt-get install openjdk-7-jdk
It also places it within your path variable.