I installed node.js(0.9.4) via nvm, which according to changelog has systemtap support.
I installed systemtap on my Fedora linux distro.
$ sudo yum install systemtap
I used this gist from Ben Noordhuis.
$ stap -l 'process("node")'
produces nothing.
$ sudo stap gc.stp -c 'node test.js'
semantic error: while resolving probe point: identifier 'process' at gc.stp:7:7
source: probe process("node").mark("gc__start")
^
semantic error: no match
semantic error: while resolving probe point: identifier 'process' at :12:7
source: probe process("node").mark("gc__done")
I have no experience at all with systemtap, but like to toy with it? What is possible with it? Can I see how much memory is consumed by code(http://stackoverflow.com/questions/13126808/whats-the-node-js-memory-breakdown)?
Update to answer comment.
$ readelf -n node
readelf: Error: 'node': No such file
$ which node
~/nvm/v0.9.4/bin/node
$ readelf -n ~/nvm/v0.9.4/bin/node
Notes at offset 0x0000021c with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.6.32
Notes at offset 0x0000023c with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 294da933883eaeaf7e848073dc3db6bff6762fb4
$ uname -a
[alfred#alfred81-AMILO-Pi-2515 gc-stap]$ uname -a
Linux alfred81-AMILO-Pi-2515.lan 3.6.3-1.fc17.x86_64 #1 SMP Mon Oct 22 15:32:35 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
$ stap -V
Systemtap translator/driver (version 2.0/0.154, rpm 2.0-1.fc17)
Copyright (C) 2005-2012 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
enabled features: AVAHI LIBRPM LIBSQLITE3 NSS TR1_UNORDERED_MAP NLS
Your copy of node appears to be compiled without sys/sdt.h markers. If they were compiled in, readelf -n would show something like ...
stapsdt 0x00000040 NT_STAPSDT (SystemTap probe descriptors)
Provider: stap
Name: stap_system__spawn
Location: 0x000000000012e1b0, Base: 0x00000000001cb886, Semaphore: 0x0000000000000000
Arguments: -4#%ebx -4#%eax
Perhaps it was configured with --without-dtrace.
Related
When I try to execute a 32-bit file compiled with gcc -m32 main.c -o main on Windows Subsystem for Linux, I get the following error: bash: ./main: cannot execute binary file: Exec format error.
If I compile it without -m32 it runs.
Any solution for running 32-bit executable on WSL?
QEMU and binfmt support light the way :)
https://github.com/microsoft/wsl/issues/2468#issuecomment-374904520
After reading that the WSLInterop between WSL and Windows processes used binfmt, I was tinkering with QEMU to try some ARM development, and incidentally discovered how to get 32-bit support working.
Edit: requires "Fall Creators Update", 1709, build 16299 or newer
Install qemu and binfmt config:
sudo apt install qemu-user-static
sudo update-binfmts --install i386 /usr/bin/qemu-i386-static --magic '\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00' --mask '\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xf8\xff\xff\xff\xff\xff\xff\xff'
You'll need to reactivate binfmt support every time you start WSL:
sudo service binfmt-support start
Enable i386 architecture packages:
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install gcc:i386
Try it out:
$ file /usr/bin/gcc-5
/usr/bin/gcc-5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=2637bb7cb85f8f12b40f03cd015d404930c3c790, stripped
$ /usr/bin/gcc-5 --version
gcc-5 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc helloworld.c -o helloworld
$ ./helloworld
Hello, world!
$ file helloworld
helloworld: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3a0c7be5c6a8d45613e4ef2b7b3474df6224a5da, not stripped
And to prove it really was working, disable i386 support and try again:
$ sudo service binfmt-support stop
* Disabling additional executable binary formats binfmt-support [ OK ]
$ ./helloworld
-bash: ./helloworld: cannot execute binary file: Exec format error
32-bit ELF support isn't provided by WSL (yet). There doesn't seem to be any progress since the UserVoice was raised - you are out luck.
See UserVoice: Please add 32 bit ELF support to the kernel and Support for 32-bit i386 ELF binaries.
If possible, switch to a real Linux ;-)
Since this was originally posted, the support has been available on WSL2 which does support real Linux kernel! So that should be the preferred way.
As noted in the linked github issue, there's also qemu-user which can be used if WSL1 is still used.
WSL2 runs in a real virtual machine using a real Linux kernel, therefore it's actually possible to do anything a Linux VM can do, including running 32-bit code. Just install 32-bit libs by running
sudo dpkg --add-architecture i386
sudo apt-get update
For more information read
Announcing WSL 2
WSL 2 FAQ
One of our clients called us saying they had had a kernel crash and asked us to investigate. They are running SLES12 SP2.
I copied the vmcore file under /var/crash (11 Mb) out of production, onto another machine also running SLES12 SP2. I copied the image of the kernel /boot/vmlinux-4.4.120-92.70-default.gz too. I installed the kernel debuginfo package in this machine. However I'm unable to run the crash utility on it:
$ strings vmcore |grep "4\.4\."
4.4.120-92.70-default
OSRELEASE=4.4.120-92.70-default
BOOT_IMAGE=/boot/vmlinuz-4.4.120-92.70-default root=[…]
$ strings ~/vmlinux-4.4.120-92.70-default |grep "4\.4\."
Linux version 4.4.120-92.70-default (geeko#buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP Wed Mar 14 15:59:43 UTC 2018 (52a83de)
$ crash /usr/lib/debug/boot/vmlinux-4.4.120-92.70-default.debug ~/vmlinux-4.4.120-92.70-default vmcore
crash 7.1.5
[…]
GNU gdb (GDB) 7.6
[…]
This GDB was configured as "x86_64-unknown-linux-gnu"...
WARNING: could not find MAGIC_START!
WARNING: cannot read linux_banner string
crash: /usr/lib/debug/boot/vmlinux-4.4.120-92.70-default.debug and vmcore do not match!
Usage: […]
I think the strings invocations above prove that the kernel and the core do match, however I'm still getting that error. What can I do next?
Why can I not run lsb_release without -a parameter on ubuntu? Because When I run lsb_release command, I am taking message "No LSB modules are available".
Explanation: lsb_release command - prints you the linux distribution version on machine.
Solution: -v (version) is in default when no parameters are in. For watching linux distribution full information always use the -a flag or -r for release number.
examples:
$lsb_release -a
#output:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.5 LTS
Release: 18.04
Codename: bionic
$lsb_release -r
#output:
Release: 18.04
Flags are:
-v, --version
Show the version of the LSB against which your current installation is compliant. The version is expressed as a colon separated list of LSB module descriptions.
-i, --id
Display the distributor's ID.
-d, --description
Display a description of the currently installed distribution.
-r, --release
Display the release number of the currently installed distribution.
-c, --codename
Display the code name of the currently installed distribution.
-a, --all
Display all of the above information.
-s, --short
Use the short output format for any information displayed. This format omits the leading header(s).
-h, --help
Show summary of options.
From the man page for lsb_release:
If no options are given, the -v option is assumed.
The -v option:
-v, --version
Show the version of the LSB against which your current installa‐
tion is compliant. The version is expressed as a colon sepa‐
rated list of LSB module descriptions.
If you don't have any lsb modules installed you'll get the message you describe. The -a switch shows all information available.
(CentOS Linux release 7.3;cuda 9.1;GPU:Tesla P100-PCIE)
I've installed Matlab2018a on a server, but when I tried to do this:
vl_compilenn('enableGpu', true);
I encountered this:
vl_compilenn: CUDA: MEX config file:
'/data1/zhangdinghuai/gitrepo/explanatoryGraph/matconvnet-1.0-
beta24/matlab/src/config/mex_CUDA_glnxa64.xml'
Building with 'nvcc'.
nvcc fatal : Unsupported gpu architecture 'compute_20'
and
Building with 'nvcc'.
Error using mex
nvcc fatal : Unsupported gpu architecture 'compute_20'
Error in vl_compilenn>mex_compile (line 529)
mex(mopts{:}) ;
Error in vl_compilenn (line 487)
mex_compile(opts, srcs{i}, objfile, flags.mexcu) ;
I have searched similar questions but none of them works, can anyone give me a hand?
PS：more information about the server is listed below:
[zhangdinghuai#gpu01 2018a]$ lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-
noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages- 4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.3.1611 (Core)
Release: 7.3.1611
Codename: Core
[zhangdinghuai#gpu01 2018a]$ cat /etc/issue
\S
Kernel \r on an \m
[zhangdinghuai#gpu01 2018a]$ cat /proc/version
Linux version 3.10.0-514.26.1.el7.x86_64 (builder#kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Thu Jun 29 16:05:25 UTC 2017
In a similar thread here "nvcc fatal : Unsupported gpu architecture 'compute_20' while cuda 9.1+caffe+openCV 3.4.0 is installed" or at Askububtu , it was recommended to edit the makefile.config and to comment out the -gencode arch=compute_20.
Can you also share the exact kernel version you are using, the exact PCI device with PCI ID and driver versions if there are any. This might give better insight into your environment as well could help to answer further questions.
My solution was modifying the file matconvnet/matlab/src/config/mex_CUDA_glnxa64.xml.
Change the line
`NVCCFLAGS="-D_FORCE_INLINES -gencode=arch=compute_20,code=sm_20 -gencode=arch=compute_30,code=\"sm_30,compute_30\" $NVCC_FLAGS"`
into
`NVCCFLAGS="-D_FORCE_INLINES -gencode=arch=compute_20,code=sm_20 -gencode=arch=compute_30,code=\"sm_30,compute_30\" $NVCC_FLAGS"`
I am getting "E: 4.0 is not a supported Linux release" when I try and run ManualExamples on my Linux machine.
Terminal Output
pin/source/tools/ManualExamples$ ../../../pin -t obj-intel64/inscount0.so -- /bin/ls
E: 4.0 is not a supported linux release
Does pin not support latest linux kernel?
Thanks! Manish
Pin 3.0 is now available, and is compatible with Linux Kernels 4.0 or higher.
However, chances are your existing Pintool (i.e. Pin 2.x compatible) won't work with Pin 3.0 since it forces you to use PinCRT and doesn't let you link your tool with outside libraries.
Still, there is a workaround for using Pin 2.x on kernels 4.0 or higher. Just use -injection child or -injection parent with your Pintool. For some reason Pin doesn't seem to care which kernel version you are running in these cases.
pin_kit$ uname -a
Linux 4.8.0-28-generic #30-Ubuntu SMP Fri Nov 11 14:03:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
pin_kit$ ./pin -t source/tools/ManualExamples/obj-intel64/inscount0.so -- /bin/ls
E:4.8 is not a supported linux release
pin_kit$ ./pin -injection child -t source/tools/ManualExamples/obj-intel64/inscount0.so -- /bin/ls
doc extras ia32 inscount.out intel64 LICENSE pin pin.log pin.sh README redist.txt source
pin_kit$ ./pin -injection parent -t source/tools/ManualExamples/obj-intel64/inscount0.so -- /bin/ls
doc extras ia32 inscount.out intel64 LICENSE pin pin.log pin.sh README redist.txt source
There is not yet a Pin release available that supports Linux kernels 4.0 or higher.
You could try DynamoRIO instead:
$ cd DynamoRIO-Linux-6.1.0-2
$ bin64/drrun -c samples/bin64/libinscount.so -- /bin/ls
Client inscount is running
ACKNOWLEDGEMENTS bin64 docs drmemory ext lib32 License.txt README tools
bin32 cmake drcov.out dynamorio include lib64 logs samples
Instrumentation results: 506331 instructions executed
Use the -ifeellucky option. It works for me in 4.5 kernel.