When I execute a gstreamer-1.0 pipeline:
gst-launch-1.0 -evm videotestsrc ! v4l2sink device=/dev/video1
for video loop back using v4l2loopback version 0.6.3 it thows the following error:
"(gst-launch-1.0:17157): GStreamer-CRITICAL **: gst_buffer_get_meta: assertion `buffer != NULL' failed.
The behaviour is inconsistent; in 5 attempts, this error comes appears at least 3 times.
System Environment, Ubuntu 12.10, 32bit, 3.5.0-26-generic kernel.
It looks like some problem with the v4l2loopback element, because when I replace the v4l2lopback with fakesink, it didnt throw any error.
Related
After upgrading from Debian Stretch to Bullseye (e.g. Python 3.5 → 3.9) we've got the following uWSGI segfault:
uWSGI process 314459 got Segmentation Fault !!!
*** backtrace of 314459 ***
/usr/bin/uwsgi(uwsgi_backtrace+0x2f) [0x558ed0a9b96f]
/usr/bin/uwsgi(uwsgi_segfault+0x23) [0x558ed0a9bd73]
/lib/x86_64-linux-gnu/libc.so.6(+0x3bd60) [0x7fd71a9e0d60]
/usr/lib/x86_64-linux-gnu/libpython3.9.so.1.0(PyErr_Occurred+0xe) [0x7fd7184d247e]
/usr/lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x12d655) [0x7fd718586655]
/usr/lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyType_Lookup+0x2d) [0x7fd71858678d]
/usr/lib/x86_64-linux-gnu/libpython3.9.so.1.0(_PyObject_GenericGetAttrWithDict+0x4d) [0x7fd71856a73d]
/usr/lib/x86_64-linux-gnu/libpython3.9.so.1.0(+0x1121c9) [0x7fd71856b1c9]
/usr/lib/x86_64-linux-gnu/libpython3.9.so.1.0(PyObject_GetAttrString+0x3b) [0x7fd71856730b]
/usr/lib/x86_64-linux-gnu/libpython3.9.so.1.0(PyObject_HasAttrString+0x7) [0x7fd718567d87]
/usr/lib/uwsgi/plugins/python3_plugin.so(uwsgi_python_autoreloader_thread+0x179) [0x7fd718a04d19]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8ea7) [0x7fd71b2d3ea7]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7fd71aaa2def]
*** end of backtrace ***
How can we find out what is causing this and how to fix the issue?
Disabling psycopg2 SSL mode does not help.
This line in the backtrace made me think that maybe the issue has something to do with automatic reloading:
/usr/lib/uwsgi/plugins/python3_plugin.so(uwsgi_python_autoreloader_thread+0x179) [0x7fd718a04d19]
Then I found this issue: https://github.com/unbit/uwsgi/issues/1968
As a workaround I disabled autoreload and the service recovered. According to this page autoreloading is only for development purposes.
Please help me with the solution as i am trying to install mongodb via brew on mac M1 air.
It is throwing me this error
Bootstrap failed: 5: Input/output error
Error: Failure while executing;
/bin/launchctl bootstrap gui/501 /Users/shrirajdesai/Library/LaunchAgents/homebrew.mxcl.mongodb-community#4.2.plist
exited with 5.
I had a similar error when I tried to run brew services restart postgresql and I got this error:
Bootstrap failed: 5: Input/output error
Error: Failure while executing; /bin/launchctl bootstrap gui/501 /Users/user/Library/LaunchAgents/homebrew.mxcl.postgresql.plist exited with 5.
This solution worked for me:
brew services. Cant start service. get "Bootstrap failed: 5: Input/output error"
In my case I replaced the mongodb-community with postgresql. I am currently running macOS Big Sur version 11.6.2.
I am running an easy Fortran 90 program (Hello world) with MPI.
The compilation works fine, if I run ./a.out I get the message, but as soon as I run
$mpiexec -n 1 exec ./a.out
I get two errors:
channel initialization failed
and
gethostbyname failed
Here is a screenshot. If I run a similar Python script what I get is this error.
I have set up mpi4py on a new server, and it isn't quite working. When I import mpi4py.MPI, it crashes. However, if I do the same thing under mpiexec, it works. On my other server and on my workstation, both techniques work fine. What am I missing on the new server?
Here's what happens on the new server:
$ python -c 'from mpi4py import MPI; print("OK")'
--------------------------------------------------------------------------
It looks like orte_init failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
PMI2_Job_GetId failed failed
--> Returned value (null) (14) instead of ORTE_SUCCESS
--------------------------------------------------------------------------
--------------------------------------------------------------------------
It looks like orte_init failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during orte_init; some of which are due to configuration or
environment problems. This failure appears to be an internal failure;
here's some additional information (which may only be relevant to an
Open MPI developer):
orte_ess_init failed
--> Returned value (null) (14) instead of ORTE_SUCCESS
--------------------------------------------------------------------------
--------------------------------------------------------------------------
It looks like MPI_INIT failed for some reason; your parallel process is
likely to abort. There are many reasons that a parallel process can
fail during MPI_INIT; some of which are due to configuration or environment
problems. This failure appears to be an internal failure; here's some
additional information (which may only be relevant to an Open MPI
developer):
ompi_mpi_init: ompi_rte_init failed
--> Returned "(null)" (14) instead of "Success" (0)
--------------------------------------------------------------------------
*** An error occurred in MPI_Init_thread
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
*** and potentially your MPI job)
[Octomore:45430] Local abort before MPI_INIT completed successfully; not able to aggregate error messages, and not able to guarantee that all other processes were killed!
If I run it with mpiexec, it's fine.
$ mpiexec -np 1 python -c 'from mpi4py import MPI; print("OK")'
OK
I'm running on CentOS 6.7. I've installed Python 2.7 as a software collection, and I've loaded the openmpi/gnu/1.10.2 module. MPICH and MPICH2 are also installed, so they may be conflicting with OpenMPI. I haven't loaded the MPICH modules, though. I'm running Python in a virtualenv:
$ pip list
mpi4py (2.0.0)
pip (8.1.2)
setuptools (18.0.1)
wheel (0.24.0)
It turned out that mpi4py is not compatible with version 1.10.2 of OpenMPI. It works fine with version 1.6.5.
$ module load openmpi/gnu/1.6.5
$ python -c 'from mpi4py import MPI; print("OK")'
OK
I tried to install node.js by following instructions here:
https://github.com/joyent/node/wiki/Building-node.js-on-Cygwin-(Windows)
I got these errors after running ./configure:
$ ./configure
Checking for program g++ or c++ : /usr/bin/g++
2 [main] python 6768 C:\cygwin\bin\python.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\python2.6\lib-dynload\time.dll to same address as parent: 0x3A0000 != 0x3D0000
Stack trace:
Frame Function Args
002891E8 6102796B (002891E8, 00000000, 00000000, 00000000)
002894D8 6102796B (6117EC60, 00008000, 00000000, 61180977)
0028A508 61004F1B (611A7FAC, 61249144, 003A0000, 003D0000)
End of stack trace
3 [main] python 5292 fork: child 6768 - died waiting for dll loading, errno 11
/home/user/node/wscript:228: error: could not configure a cxx compiler!
I did a rebaseall on cygwin and ran configure again and got these errors:
$ ./configure
Checking for program g++ or c++ : /usr/bin/g++
Checking for program cpp : /usr/bin/cpp
Checking for program ar : /usr/bin/ar
Checking for program ranlib : /usr/bin/ranlib
Checking for g++ : ok
Checking for program gcc or cc : /usr/bin/gcc
2 [main] python 6100 C:\cygwin\bin\python.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\python2.6\lib-dynload\_functools.dll to same address as parent: 0x3A0000 != 0x3D0000
Stack trace:
Frame Function Args
002891E8 6102796B (002891E8, 00000000, 00000000, 00000000)
002894D8 6102796B (6117EC60, 00008000, 00000000, 61180977)
0028A508 61004F1B (611A7FAC, 6124976C, 003A0000, 003D0000)
End of stack trace
2 [main] python 4424 fork: child 6100 - died waiting for dll loading, errno 11
/home/user/node/wscript:230: error: could not configure a c compiler!
What am I doing wrong?
You can follow the steps on this page:
http://www.garethhunt.com/2008/02/11/cygwin-died-waiting-for-dll-loading/
it worked perfectly for me.
You can avoid installing node.js through Cygwin and try to use native Windows executable which would/should be preffered (unless you have some specific reasons to do otherwise).