segmentation fault (core dumped) in /usr/include/eigen3/Eigen/src/Core/util/Memory.h - dump

Testing extract_indices.cpp and project_inliers.cpp, both failed with the ERROR: segmentation fault (core dumped).
➜ Tests ./extract_indices
PointCloud before filtering: 460400 data points.
PointCloud after filtering: 41049 data points.
PointCloud representing the planar component: 20161 data points.
[1] 428791 segmentation fault (core dumped) ./extract_indices
➜ Tests ./project_inliers
Cloud before projection:
0.179143 0.111469 0.878188
-0.913136 0.692691 -0.437776
0.859634 0.288651 0.0754952
-0.590425 0.924363 0.76998
0.0400138 0.698133 -0.778793
[1] 428828 segmentation fault (core dumped) ./project_inliers
As investigated, core dump happened in Eigen: /usr/include/eigen3/Eigen/src/Core/util/Memory.h
/** \internal Frees memory allocated with handmade_aligned_malloc */
inline void handmade_aligned_free(void *ptr)
{
if (ptr) std::free(*(reinterpret_cast<void**>(ptr) - 1));
}
My ENV:
➜ Tests lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.4 LTS
Release: 20.04
Codename: focal
➜ Tests gcc --version
gcc (GCC) 10.3.1 20210627
Copyright (C) 2020 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.
➜ Tests g++ --version
g++ (GCC) 10.3.1 20210627
Copyright (C) 2020 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.
Can anybody give me a hand?
Cheers

Related

Issue debugging a 32-bits assembly Hello world with GDB on a Raspberry Pi running a 64 bit version of Linux

I am trying to setup my Raspberry Pi so I can start learning ARM, and have issues debugging 32-bits ARM files. First, some informations maybe useful to my problem:
$ uname -a
Linux raspberrypi 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
I can write a hello world program (in assembly) for ARM64, compile it using as and ld, then execute it and debug it with gdb without any issue. For 32 bits ARM, after installing the package binutils-arm-linux-gnueabihf, I can compile my files using arm-linux-gnueabihf-as/ld and execute them without issue. However, I have problems debugging them with gdb.
My version of gdb is :
$ gdb -v
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
and I am using the GEF extension. The file command for the 32-bits file gives:
$ file helloworld
helloworld: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
After typing gdb helloworld, I can run it using the r command and it does print Hello world, but I can't debug it step by step: setting a breakpoint to the entry point (in my case, 0x10074 - obtained with info file -, which does not seem standard) makes the program run indefinitely, as if it was in an infinite loop, and stopping it with CTRL+C gives me:
$sp : 0x798fdfb4
$lr : 0xc6ac9670
$pc : 0x20
$cpsr: [negative ZERO CARRY OVERFLOW INTERRUPT FAST thumb]
────────────────────────────────────────────────────────────────────────────────────────── stack ────
[!] Unmapped address: '0x55798fdfb4'
─────────────────────────────────────────────────────────────────────────────────── code:arm:ARM ────
[!] Cannot disassemble from $PC
[!] Cannot access memory at address 0x20
──────────────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "helloworld", stopped 0x20 in ?? (), reason: SIGINT
I am not sure what is going on. The address in Unmapped address: '0x55798fdfb4' looks like a standard .text address under PIE + ASLR, but I don't know why there would be mapping issues. How could I fix this ?
This answer is more an answer to the question: "How can I learn 32 bit assembly language on my raspberry Pi" than a direct answer to yours:
If your goal is to learn Aarch32 T32 or A32 assembly language on your raspberry Pi, I would strongly suggest to do so on a 32 bit distribution - I am not sure at this stage that you can debug a user mode Aarch32 program on an Aarch64 Linux system using an Aarch64 multiarch GDB or an Aarch32 version of GDB, my own attempts having been unsuccessful, and having not found to this day examples of how exactly to do this.
Another pro of this approach is that you will be able to concentrate on learning 32 bit Arm, and not asking yourself if your programs are not working because of a bug, or because off a potential problem/bug in the tools you are running on your Aarch64 system - my two cents.
If you have a spare 8GiB micro-SD card, you can install a 32 bit version of Ubuntu Server 22.04 from here.
One installed, here is what I am getting on my system:
cat /sys/firmware/devicetree/base/model
Raspberry Pi 3 Model B Rev 1.2
uname -a
Linux ubuntu 5.15.0-1005-raspi #5-Ubuntu SMP PREEMPT Mon Apr 4 12:25:49 UTC 2022 armv7l armv7l armv7l GNU/Linux
Install gcc and gdb:
sudo-apt -get install gcc gdb
Create hello-world.s, adapted from this example:
.arch armv7a
.file "hello-world.s"
.text
.global main
.syntax unified
.thumb
.thumb_func
.type main, %function
main:
mov r0, #1 # 1 = stdout
ldr r1, =hello_world # str pointer
mov r2, #13 # str len
mov r7, #4 # linux write syscall
svc 0 # software interrupt call write
exit:
mov r0, #0 # return code
mov r7, #1 # linux exit syscall
svc 0 # software interrupt call exit
.data
hello_world:
.ascii "Hello World!\n"
.end
as -g -o hello-world.o hello-world.s
gcc -g -o hello-world hello-world.o
./hello-world
Hello World!
GDB debug session:
gdb ./hello-world
GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
Copyright (C) 2022 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 "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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"...
Reading symbols from ./hello-world...
(gdb) b main
Breakpoint 1 at 0x4e0: file hello-world.s, line 10.
(gdb) run
Starting program: /home/ubuntu/hello-world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Breakpoint 1, main () at hello-world.s:10
10 mov r0, #1 # 1 = stdout
(gdb) step
11 ldr r1, =hello_world # str pointer
(gdb)
12 mov r2, #13 # str len
(gdb)
13 mov r7, #4 # linux write syscall
(gdb)
14 svc 0 # software interrupt call write
(gdb)
Hello World!
exit () at hello-world.s:16
16 mov r0, #0 # return code
(gdb)
17 mov r7, #1 # linux exit syscall
(gdb)
18 svc 0 # software interrupt call exit
(gdb)
[Inferior 1 (process 3043) exited normally]
(gdb) quit

Can't run mongodb community 5.0 on arch linux

I can't run use mongodb on my arch linux.
package installed: mongodb-bin
error when use mongo: illegal hardware instruction (core dumped) mongo
My processor: AMD Athlon(tm) II X2 270
From the
release notes:
MongoDB 5.0 requires AMD Bulldozer or later.
How to check:
cat /proc/cpuinfo | grep -i avx
(Advanced Vector Extention(avx) needed for 5.0)

Redirect stderr to file on network driver is very slow since VC++ 2015 / 14.0

We experience a strange performance issue when using Visual C++ 2013 (also known as Visual C++ 12.0) compared to more recent versions like Visual C++ 2015 (also known as Visual C++ 14.0):
The same C code is much slower when writing to stderr and redirecting this stream to a file on a network drive (Server is Linux Debian 8 / Samba).
C:\tmp> myprog.exe 2>X:\devel\fgl\tests\zz
When redirecting to a file on the local disk, or when redirecting to nul, the execution is fast.
We have also tested with VC++ 2017 / 15.0, same problem.
The reason seams to be the /MD option (link with MSVCRT.LIB), I could reproduce with a simple program:
#include <stdio.h>
int main(int argc, char **argv)
{
int n;
system("echo %TIME%");
for (n=0; n<200; n++) {
fprintf(stderr,"aaaaaaaaaaaaaaaaaaaaaaaaaaaa %d\n", n);
}
system("echo %TIME%");
return 0;
}
Then compile with and without /MD option:
C:\tmp>cl /O1 myprog.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25507.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
myprog.c
Microsoft (R) Incremental Linker Version 14.11.25507.1
Copyright (C) Microsoft Corporation. All rights reserved.
/out:myprog.exe
myprog.obj
C:\tmp>myprog.exe 2>X:\devel\fgl\tests\zz
9:32:27.96
9:32:27.97
C:\tmp>cl /O1 /MD myprog.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25507.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
myprog.c
Microsoft (R) Incremental Linker Version 14.11.25507.1
Copyright (C) Microsoft Corporation. All rights reserved.
/out:myprog.exe
myprog.obj
C:\tmp>myprog.exe 2>X:\devel\fgl\tests\zz
9:32:37.15
9:32:40.12
C:\tmp>myprog.exe 2>c:\tmp\zz
9:32:47.15
9:32:47.20
Is there any known issue related to stderr / network drives with VC++?
Notes:
No problem when writing to stdout
No problem when using /MDd option (MSVCRTD.lib)
No problem with Visual C++ 2013 (Visual C++ 12.0, cl version 18.00.40629)
Thanks for reading!
Er, we have been experiencing the same issue with our C++ code so I added my comment using C++, initially. Sorry about that.
For C, the same "remedy" would look like this:
char buf[4096];
setvbuf(stderr, _IOLBF/*or _IOFBF*/, buf, sizeof(buf));
Initial response:
Try this at the beginning of your program:
static char buf[16384];
cerr.rdbuf()->pubsetbuf(buf, sizeof(buf));
cerr.unsetf(std::ios_base::unitbuf);
You can decrease the buffer size (to 4096 or less) and still see the speed boost -- the thing is that cerr is completely unbuffered by default, and having unitbuf set on it causes even more slowdown by implicit flush operations injected after each output to the stream.

Cannot install Perl module due to missing cc1 compiler on Ubuntu 14.04

I am trying to install Moose using cpanm on Ubuntu 14.04, but I get an error saying:
Running Makefile.PL
Configuring Moose-2.1210 ... cc: error trying to exec 'cc1': execvp: No such file or directory
This distribution requires a working compiler at Makefile.PL line 52.
N/A
! Configure failed for Moose-2.1210. See /home/hakon/.cpanm/work/1407056127.30229/build.log for details.
I have installed gcc compiler version 4.8.2. :
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.8/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
Here is more output (the whole output is available here):
$ cpanm -v Moose
cpanm (App::cpanminus) 1.7004 on perl 5.018002 built for i686-linux-gnu-thread-multi-64int
Work directory is /home/hakon/.cpanm/work/1407056507.30283
You have make /usr/bin/make
You have LWP 6.05
You have /bin/tar: tar (GNU tar) 1.27.1
Copyright (C) 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.
Written by John Gilmore and Jay Fenlason.
You have /usr/bin/unzip
Checking if you have ExtUtils::MakeMaker 6.31 ... Yes (6.66)
Checking if you have ExtUtils::Install 1.46 ... Yes (1.59)
Searching Moose on cpanmetadb ...
Unpacking Moose-2.1210.tar.gz
--> Working on Moose
Fetching http://www.cpan.org/authors/id/E/ET/ETHER/Moose-2.1210.tar.gz ... OK
Moose-2.1210/
Moose-2.1210/author/
Moose-2.1210/benchmarks/
Moose-2.1210/bin/
Moose-2.1210/Changes
Moose-2.1210/Changes.Class-MOP
Moose-2.1210/dist.ini
Moose-2.1210/doc/
Moose-2.1210/inc/
Moose-2.1210/lib/
Moose-2.1210/LICENSE
Moose-2.1210/Makefile.PL
Moose-2.1210/MANIFEST
Moose-2.1210/META.json
Moose-2.1210/META.yml
Moose-2.1210/mop.c
Moose-2.1210/mop.h
...
<cut>
...
Moose-2.1210/benchmarks/cmop/run_yml.pl
Moose-2.1210/benchmarks/cmop/lib/Bench/
Moose-2.1210/benchmarks/cmop/lib/MOP/
Moose-2.1210/benchmarks/cmop/lib/Plain/
Moose-2.1210/benchmarks/cmop/lib/Plain/Point.pm
Moose-2.1210/benchmarks/cmop/lib/Plain/Point3D.pm
Moose-2.1210/benchmarks/cmop/lib/MOP/Immutable/
Moose-2.1210/benchmarks/cmop/lib/MOP/Installed/
Moose-2.1210/benchmarks/cmop/lib/MOP/Point.pm
Moose-2.1210/benchmarks/cmop/lib/MOP/Point3D.pm
Moose-2.1210/benchmarks/cmop/lib/MOP/Installed/Point.pm
Moose-2.1210/benchmarks/cmop/lib/MOP/Installed/Point3D.pm
Moose-2.1210/benchmarks/cmop/lib/MOP/Immutable/Point.pm
Moose-2.1210/benchmarks/cmop/lib/MOP/Immutable/Point3D.pm
Moose-2.1210/benchmarks/cmop/lib/Bench/Accessor.pm
Moose-2.1210/benchmarks/cmop/lib/Bench/Construct.pm
Moose-2.1210/benchmarks/cmop/lib/Bench/Run.pm
Moose-2.1210/author/docGenerator.pl
Moose-2.1210/author/extract-inline-tests
Moose-2.1210/author/find-dupe-test-numbers
Entering Moose-2.1210
Checking configure dependencies from META.json
Checking if you have Dist::CheckConflicts 0.02 ... Yes (0.11)
Checking if you have ExtUtils::MakeMaker 6.30 ... Yes (6.66)
Checking if you have File::Spec 0 ... Yes (3.40)
Checking if you have ExtUtils::CBuilder 0.27 ... Yes (0.280210)
Running Makefile.PL
Configuring Moose-2.1210 ... cc: error trying to exec 'cc1': execvp: No such file or directory
This distribution requires a working compiler at Makefile.PL line 52.
! Configure failed for Moose-2.1210. See /home/hakon/.cpanm/work/1407056507.30283/build.log for details.
N/A

Calling sem_open on Solaris as ordinary user

This call fails on Solaris with EACCES when ran as ordinary user:
sem_open(fileName.c_str(), O_CREAT, S_IRWXU | S_IRWXG | S_IRWXO, 1);
When process is started as root, it runs fine. Is this expected behavior?
Environment:
$ uname -a
SunOS solaris 5.11 11.0 i86pc i386 i86pc
$ g++ --version
g++ (GCC) 4.5.2
At the command line try:
prctl $$
These are the system enforced resource limits your process has. Note there are
process.max-sem-ops
process.max-sem-nsems
project.max-sem-ids
These are limits that have a number, if you do not see them (or the limits are already reached) then you have to add them to your account's profile with projadd or projmod to increase them if your project already exists.
If you cannot do this (no root access) consult with your sysadmin, s/he probably has some reason for not allowing semapahore access.
Note carefully:
sempahores are kernel persistent. If you ran your code a bunch of times the sempahores you created are likely still out there.
To see existing semaphores try ipcs -as
To remove lingering sempahores that your code should have removed use ipcrm