I've been going through intense program/package installation recently, so I can't tell for sure which of the newly installed programs (or old programs) caused the appearance of a core file in my home folder. It's a server, so I better find out any possible sources of instability on the machine.
You can simply use the file program to identify them:
E.g
# file /var/core/core
/var/core/core: ELF 64-bit MSB core file SPARCV9 Version 1, from 'crs_stat.bin'
Often using the file program on the core file will show the errant executable, as explained by #Benj in the accepted answer (code from Benj's answer):
# file /var/core/core
/var/core/core: ELF 64-bit MSB core file SPARCV9 Version 1, from 'crs_stat.bin'
However, sometimes you may get a complaint about "too many program header sections":
core.some-lib.nnnn.nnnn: ELF 64-bit LSB core file x86-64, version 1 (SYSV), too many program header sections (1850)
In this case, you can try some alternatives:
Tail the last several strings of the corefile (the app was about 25 back for me): strings core.some-lib.nnnn.nnnn | tail -50
Use gdb itself: gdb -c core.some-lib.nnnn.nnnn This will often tell you something like this: Core was generated by '/usr/local/bin/some-executable'
you can navigate to the directory where the core.pid is and run gdb core core.pid
Related
Basically I'm trying to run eclipse's 64bit linux installer on a 64 bit linux machine, but it's giving me an exec format error. All other solutions I've seen say it's usually an error with it not being the right processor speed.
My question is twofold. 1) What is going on here? 2) How do I properly download and install Eclipse?
I'm running linux through chromebook
Here is the output of a few command line statements
uname#loc:~/Desktop/eclipse-installer$ ./eclipse-inst
-bash: ./eclipse-inst: cannot execute binary file: Exec format error
uname#loc:~/Desktop/eclipse-installer$ file eclipse-inst
eclipse-inst: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=b621fbc20e80d7ac375ece11a5775fc6686b71c7, with debug_info, not stripped
uname#loc:~/Desktop/eclipse-installer$ uname -m
aarch64
To answer your first question I think this could help:
You are trying to execute a program designed to run on a "x86_64" based processor using a processor designed based on "aarch64" architecture. These are two distinct architectures although they both may be using 64-bits for addressing and so forth, but it's not the matter of the bits. They are two completely different CPU designs.
For your second question I can not help because I don't use Eclipse.
I've installed ccx (Calculix solver programm) to solve a physical problem. The preprocessor cgx works fine, but when I run ccx with an .inp file (abaqus) in terminal, there comes an error:
ccx: symbol lookup error: ccx: undefined symbol: _gfortran_internal_malloc
when I only run ccx without a flag or .inp file, the result is:
Usage: CalculiX.exe -i jobname
I have libgfortran3 installed on my ubuntu 14.04 computer (64 bit: x86_64) and link the "libgfortran.so.3.0.0" file in "/usr/lib/x86_64/" with a created reference object file "libgfortran.so.2" (calculix needs that file 'cause the application runs on 32 bit). Without that reference file ccx doesn't work completely and thats why I had to link it. I use Calculix 2.8p2.
If your application is 32 bit, it needs 32 bit libraries to work. What you've done is install 64 bit libraries and then symlinked them to where the 32 bit library should be. This satisfies that the library "exists" but it will be unusable for the 32 bit program.
My library locations will differ from yours, but observe that they are different:
64 bit libgfortran.so
$ file /usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/libgfortran.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/libgfortran.so.3.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
32 bit libgfortran.so
$ file /usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/32/libgfortran.so.3.0.0
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.2.0/32/libgfortran.so.3.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
Secondly, if your program needs libgfortran.so.2, then symlinking a version of libfortran.so.3 in its place will not work. The change in library version number is a good signal that they are not compatible and not interchangeable. You will need to find a package that provides the older library for i386 architecture. This might mean installing a package from an older version of ubuntu.
I have written a custom core-dump handling application for a project. I have changed '/proc/sys/kernel/core_pattern' to call my dump-handler and its invoked successfully.
Now the issue is saving the core-dump into a file that can be recognized by gdb. Currently my dump-handler read the dump from STDIN and save it into a file 'core.dump'. When I try to load this core dump into gdb it gives me error:
(gdb) ... is not a core dump: File format not recognized
When I run 'file' command on a standard core dump it give me following:
core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './dump_gen'
And for custom generated dump, 'file' gives following:
core.dump: data
Please can anyone help me how to write core-dump correctly so it can be used in gdb.
PS: I don't want to use standard core dump file.
I think you somehow don't write all the data to the core file.
Create a simple script, make it executable and set the core pattern to the script.
#!/bin/sh
cat > /tmp/core.$$
Now generate a core file (for example run sleep 1243 and press ctrl+\) and it should work.
I just tested it myself on my system and it works without a problem.
The first thing to check that comes to mind is the Elf header flag that indicates what kind of file it is. It has four values - shared object, unlinked object, executable and core dump. That's most likely what's causing gdb errors.
Also, try examining it with objdump - it can pull apart the entire ELF file for analysis what part of it is apparently not good.
You can find the ELF spec at https://refspecs.linuxbase.org/elf/elf.pdf
I am running red had linux 7.3 (old, I know), and for the past few months I've been learning assembly programming, writing small programs and compiling with nasm. For months, things have been going fine, and now for some unknown reason, I cannot execute any programs that I compile.
nasm file.s //used to work just fine, then I'd execute ./file
now, when I run ./file, first I get "permission denied", which never used to happen before. then, once i chmod +777 file, I get "cannot execute binary file".
I have NO IDEA why this is happening, but it is extremely frustrating since NOTHING I compile will run anymore.
Logging in as root doesn't change anything.
All suggestions are welcome, THANK YOU!!
nasm does not produce an executable, but just an object file (like gcc -c would). You still need to run the linker on it.
N.B.: “0777 is almost always wrong.”
Run the file command on your binaries and make sure they're identified correctly as executables.
Also try the ldd command. It will very likely fail for the exact same reason, but it's worth a shot.
This can happen if the file system you operate on is mounted with the noexec option. You could check that by doing mount | grep noexec and see if your current working directory suffers from that.
"Cannot execute binary file" is the strerror(3) message for the error code ENOEXEC. That has a very specific meaning: (quoting the manpage for execve(2))
[ENOEXEC] The new process file has the appropriate access
permission, but has an unrecognized format
(e.g., an invalid magic number in its header).
So what that means is, your nasm invocation is not producing an executable, but rather something else. As John Kugelman suggests, the file command will tell you what it is (user502515 is very likely to be right that it's an unlinked object file, but I have never used nasm myself so I don't know).
BTW, you'll do yourself a favor if you learn GAS/"AT&T" assembly syntax now, rather than when you need to rewrite your assembly code for an architecture that doesn't do Intel bizarro-world syntax. And I do hope you're using assembly only for inner-loop subroutines that actually need to be hand-optimized.
This just happened to me. After running
file <executable name>
it output <file name> ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
And the problem was that I was trying to run a 64 bit app on a 32 bit machine!
You may try looking into /var/log for some change in the system from this start to happen.
After a Xen guest domain hang, I took a dump using xm core-dump . Following the sparse documentation I found, I tried using the crash utility to analyze the dump.
Unfortunately, the kernel image (Debian lenny) is stripped, so I am forced to make use of the map file.
However,
crash
/boot/System.map-2.6.26-2-xen-amd64
vmlinux-2.6.26-2-xen-amd64
/mnt/my-core-file
(with vmlinux-2.6.26-2-xen-amd64 being the gunzip'ed vmlinuz image) fails:
crash: vmlinux-2.6.26-2-xen-amd64: no
debugging data available
Then I read that current Xen versions produce ELF-compatible dumps for guest domains. Indeed, this seems to be the case:
~$ sudo file my-core-dump
my-core-dump: ELF 64-bit LSB core file x86-64, version 1
However, gdb vmlinux-2.6.26-2-xen-amd64 my-core-dump fails, too:
...is not a core dump: File format not
recognized
Any hints?
Have you tried attaching to the domU console ?
xm create domU.conf -c
On the subject of the core-dump file, I found this:
http://lists.xensource.com/archives/html/xen-devel/2006-12/msg00456.html
I just want to check that you aren't under the impression that 'xm
dump-core' emits an Elf core file. It doesn't -- the format is custom and as
far as I know is only interpreted by a set of gdbserver patches that we ship
in our repository. Does the crash utility really support this special
format?
Edit: This might help to debug the core-dump: http://os-drive.com/files/docbook/xen-faq.html#setup_gdb