When running mplayer -identify dvd:// -dvd-device g: -frames 0 in order to scrape information from a DVD, I'm getting this error on the Yo Gabba Gabba! Music Makes Me Move! DVD:
MPlayer Redxii-SVN-r38151-6.2.0 (x86_64) (C) 2000-2019 MPlayer Team
Using FFmpeg N-94664-g0821bc4eee (2019-08-26 16:09:11 -0700)
Compiled on 2019-08-28 01:29:43 EDT (rev. 1)
Fontconfig error: Cannot load default config file
Playing dvd://.
libdvdcss debug: opening target `g:'
libdvdcss debug: using Win2K API for access
libdvdcss debug: disc reports copyright information 0x1
libdvdcss debug: drive region(s) 1, region mask 0xfe, RPC-II, region code set
libdvdcss debug: disc is scrambled
libdvdcss debug: requesting authentication grant ID (AGID)
libdvdcss debug: drive authenticated, using variant 0
libdvdcss debug: authentication established
libdvdcss debug: authentication success flag set, ASF=1
libdvdcss debug: decrypting disc key 53:24:5a:f4:76
libdvdcss debug: trying player key 01:af:e3:12:80
libdvdcss debug: decrypted disc key is 6a:cb:11:d3:bf
ID_DVD_TITLES=99
ID_DVD_TITLE_1_CHAPTERS=1
...
ID_DVD_TITLE_97_LENGTH=0.867
libdvdread: Unable to read invalid PCG
MPlayer interrupted by signal 11 in module: open_stream
ID_SIGNAL=11
- MPlayer crashed by bad usage of CPU/FPU/RAM.
Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
gcc version. If you think it's MPlayer's fault, please read
DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
won't help unless you provide this information when reporting a possible bug.
What should I do to attempt to fix this error? I heard something about using GDB, but am unsure of how to use it on Windows.
Related
The code is working. I can build it and to mention. it was working, i could upload it to my custom made ESP32 board. From all of a sudden it stopped working. Tried with different PCB boards also different cables.
I somehow resolved my problem so i can program it, but now i get a verification error after Programming Finished
Here is my complete log from terminal.
Processing esp32dev (platform: espressif32; board: esp32dev; framework: espidf)
-----------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (3.4.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
- framework-espidf 3.40301.0 (4.3.1)
- tool-cmake 3.16.4
- tool-esptoolpy 1.30100.210531 (3.1.0)
- tool-mkspiffs 2.230.0 (2.30)
- tool-ninja 1.9.0
- tool-openocd-esp32 2.1000.20210721 (10.0)
- toolchain-esp32ulp 1.22851.191205 (2.28.51)
- toolchain-riscv32-esp 8.4.0+2021r1
- toolchain-xtensa-esp32 8.4.0+2021r1
- toolchain-xtensa-esp32s2 8.4.0+2021r1
Reading CMake configuration...
LDF: Library Dependency Finder ->
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Building in debug mode
Retrieving maximum program size .pio/build/esp32dev/firmware.elf
Checking size .pio/build/esp32dev/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [= ] 10.1% (used 32992 bytes from 327680 bytes)
Flash: [======== ] 75.7% (used 794197 bytes from 1048576 bytes)
Configuring upload protocol...
AVAILABLE: esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = esp-prog
Uploading .pio/build/esp32dev/firmware.bin
Open On-Chip Debugger v0.10.0-esp32-20210721 (2021-07-21-13:34)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 1
adapter speed: 20000 kHz
WARNING: boards/esp-wroom-32.cfg is deprecated, and may be removed in a future release.
adapter speed: 2000 kHz
** Programming Started **
** Programming Finished **
** Verify Started **
Error: **** Verification failure! ****
Error: target_hash cbc6a9...992065
Error: file_hash: 773d62...93803f
embedded:startup.tcl:449: Error: ** Verify Failed **
in procedure 'program_esp'
in procedure 'program_error' called at file "/Users/USER/.platformio/packages/tool-openocd-esp32/share/openocd/scripts/target/esp_common.cfg", line 135
at file "embedded:startup.tcl", line 449
*** [upload] Error 1
I have a problem when run command: sudo -su user_test ./pgsql/bin/initdb -D /example/folder
I had researched many sources from the internet but don’t found a solution.
I hope everyone could help me. Thanks.
Enviroment:
initdb (PostgreSQL) 10.10
OS: uname -a Linux DL2100 3.10.38 #1 SMP Build-gitb1820a8 x86_64 GNU/Linux
selecting default max_connections … 100
selecting default shared_buffers … 128MB
selecting default timezone … Europe/Helsinki
selecting dynamic shared memory implementation … posix
creating configuration files … ok
running bootstrap script … 2020-11-03 11:52:56.303 EET [3928] DEBUG: invoking IpcMemoryCreate(size=148545536)
2020-11-03 11:52:56.303 EET [3928] DEBUG: mmap(148897792) with MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory
2020-11-03 11:52:56.315 EET [3928] DEBUG: SlruScanDirectory invoking callback on pg_notify/0000
2020-11-03 11:52:56.315 EET [3928] DEBUG: removing file "pg_notify/0000"
2020-11-03 11:52:56.316 EET [3928] DEBUG: dynamic shared memory system will support 288 segments
2020-11-03 11:52:56.316 EET [3928] DEBUG: created dynamic shared memory control segment 1852866650 (6928 bytes)
2020-11-03 11:52:56.319 EET [3928] PANIC: could not generate secret authorization token
Aborted
child process exited with exit code 134```
The error is thrown in BootStrapXLOG in src/backend/access/transam/xlog.c:
/*
* Generate a random nonce. This is used for authentication requests that
* will fail because the user does not exist. The nonce is used to create
* a genuine-looking password challenge for the non-existent user, in lieu
* of an actual stored password.
*/
if (!pg_backend_random(mock_auth_nonce, MOCK_AUTH_NONCE_LEN))
ereport(PANIC,
(errcode(ERRCODE_INTERNAL_ERROR),
errmsg("could not generate secret authorization token")));
src/backend/utils/misc/backend_random.c says:
pg_backend_random() function fills a buffer with random bytes. Normally,
it is just a thin wrapper around pg_strong_random(), but when compiled
with --disable-strong-random, we provide a built-in implementation.
So it seems that PostgreSQL was built on a system that had a source for strong random numbers (OpenSSL or /dev/urandom, if you are not on Windows), but the facility is not working on your current system.
try with the lates minor release of v10 (currently 10.15) – maybe a bug has been fixed.
run pg_config --configure to check if PostgreSQL was built --with-openssl
OpenSSL also uses /dev/urandom, so there is likely a problem with that source of random numbers; investigate there
If all fails, build PostgreSQL from source and configure it with
./configure --disable-strong-random ...
It worked fine. Thank you very much, #Laurenz Albe
trying to program and debug STM32F103 (Bluepill) from Atollic TrueStudio 9.3 I got following message:
STMicroelectronics ST-LINK GDB server. Version 5.1.0 Copyright (c)
2018, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
Vendor = 0x55
Error in initializing ST-LINK device. Reason: ST-LINK: Could not
verify ST device! Abort connection.
Trying to do the same thing in St-Link utility works without any problems (also erasing and programming):
What could be the problem with this, why does it have problems with verification ?
Tnx for helping in advance!
The problem is that the ID of the STM32F103 on the BluePill and the ID, defined the debugger config files are different. Often the BluePills have counterfeit ICs on them in order to keep the price low, but these do not have the same ID as genuine ICs.
The Instructions/video below are made for STM32CubeIDE however they should also work for TrueSTUDIO.
Video about a workaround: https://youtu.be/bJYp8o7FoYo
Open the Debug Configuration Window
Select ST-LINK(OpenOCD) in the Debug Probe Dropdown
Search stm32f1x.cfg file the C:\ST\STM32CubeIDE_1.2.0\STM32CubeIDE and open it using notepad.
Search for this Line
Now change the ID from 0x1ba01477 to 0x2ba01477 as shown here
Save the file, now debugging should work
this solution also works for clone chips like CH32F103 which is in some cases on BluePill
the other solution is to change a parameter in "stm32f1x.cfg"
open it with a text editor and find this line:
swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
change "$_CPUTAPID" to zero at the end of line it should be like this:
swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0
after that :Open the Debug Configuration Window like picture above and choose "Select ST-LINK(OpenOCD)" in the Debug Probe Dropdown
then click "Show generator options…” and in Mode setup change"Reset Mode”For“Software system reset”.
both of ways works and i've tested them with CubeIDE and CH32f103c8t6.
remember to change jumper on board
jumpers : up = 0 ; down = 1
I followed this article to enable FTRACE
https://lwn.net/Articles/365835/
to test a realtime system, my system uses arm cortexa15 (Description: https://mp.renesas.com/en-us/rzg/marketplace/board/RZGB000003.html)
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_STACK_TRACER=y
CONFIG_DYNAMIC_FTRACE=y
But, it didn't work, caused the system hang-up when starting kernel.
Even referred How to Enable or configure ftrace module
I would like to test latency in the realtime system with cyclictest (option -b to trigger FTRACER)
cyclictest -a -t -n -p99 -f -b100
It generated dump message:
INFO: debugfs mountpoint: /sys/kernel/debug/tracing/
WARN: tracing_enabled or tracing_on not found
debug fs not mounted, TRACERs not configured?
could not set ftrace_enabled to 0
FATAL: Can't open /sys/kernel/debug/tracing/available_tracers for reading
I repeated a next step to enable a group of tracer configs:
CONFIG_FTRACE=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FUNCTION_TRACER=y
CONFIG_IRQSOFF_TRACER=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_PREEMPT_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_ENABLE_DEFAULT_TRACERS=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACER_SNAPSHOT=y
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_TRACEPOINT_BENCHMARK=y
CONFIG_BACKTRACE_SELF_TEST=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_LL=y
The result still was the same. Kernel hung and didn't show anything.
Anyone who deal with realtime system and Ftrace can help ? Thanks.
I resolve my problem. Below is a part of my defconfig file.
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_TRACEPOINTS=y
CONFIG_STACKTRACE=y
CONFIG_NOP_TRACER=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_CLOCK=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_GENERIC_TRACER=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACER_SNAPSHOT=y
CONFIG_STACK_TRACER=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FTRACE_MCOUNT_RECORD=y
After enabling Ftrace tool, the culprit can then be found in the trace output at /sys/kernel/debug/tracing/trace. The kernel function that was executed just before a latency of more than 100 microseconds was detected is marked with an exclamation mark.
I’m trying to install check_mk agent with the standard check_mk xinetd config file via puppet on a Debian 7 server.
Check_mk installs without a problem but I've got an issue with the xinetd config.
When I change the port in the source config file on the puppet master and run puppet agent -t on the client host the new configuration is deployed correctly but puppet doesn't reload the xinetd service because the system can't recognize the state of the xinetd service.
The puppet manifest looks like this:
class basic::check-mk {
case $operatingsystem {
debian: {
package {'check-mk-agent':
ensure => present,
}
file { '/etc/xinetd.d/check_mk':
notify => Service['xinetd'],
ensure => file,
source => 'puppet:///modules/basic/etc--xinetd--checkmk',
mode => '0644',
}
service { 'xinetd':
ensure => running,
enable => true,
restart => '/etc/init.d/xinetd reload',
}
}
}
}
The debug looks like this:
info: Applying configuration version '1464186485'
debug: /Stage[main]/Ntp::Config/notify: subscribes to Class[Ntp::Service]
debug: /Stage[main]/Ntp/Anchor[ntp::begin]/before: requires Class[Ntp::Install]
debug: /Stage[main]/basic::Check-mk/Service[xinetd]/subscribe: subscribes to File[/etc/xinetd.d/check_mk]
debug: /Stage[main]/Ntp::Install/before: requires Class[Ntp::Config]
debug: /Stage[main]/Ntp::Service/before: requires Anchor[ntp::end]
debug: /Schedule[daily]: Skipping device resources because running on a host
debug: /Schedule[monthly]: Skipping device resources because running on a host
debug: /Schedule[hourly]: Skipping device resources because running on a host
debug: Prefetching apt resources for package
debug: Executing '/usr/bin/dpkg-query -W --showformat '${Status} ${Package} ${Version}\n''
debug: Puppet::Type::Package::ProviderApt: Executing '/usr/bin/dpkg-query -W --showformat '${Status} ${Package} ${Version}\n''
debug: /Schedule[never]: Skipping device resources because running on a host
debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson
debug: /Stage[main]/basic::Check-mk/File[/etc/xinetd.d/check_mk]/content: Executing 'diff -u /etc/xinetd.d/check_mk /tmp/puppet-file20160525-10084-1vrr8zf-0'
notice: /Stage[main]/basic::Check-mk/File[/etc/xinetd.d/check_mk]/content:
--- /etc/xinetd.d/check_mk 2016-05-25 14:57:26.220873468 +0200
+++ /tmp/puppet-file20160525-10084-1vrr8zf-0 2016-05-25 16:28:06.393363702 +0200
## -25,7 +25,7 ##
service check_mk
{
type = UNLISTED
- port = 6556
+ port = 6554
socket_type = stream
protocol = tcp
wait = no
debug: Finishing transaction 70294357735140
info: FileBucket got a duplicate file {md5}cb0264ad1863ee2b3749bd3621cdbdd0
info: /Stage[main]/basic::Check-mk/File[/etc/xinetd.d/check_mk]: Filebucketed /etc/xinetd.d/check_mk to puppet with sum cb0264ad1863ee2b3749bd3621cdbdd0
notice: /Stage[main]/basic::Check-mk/File[/etc/xinetd.d/check_mk]/content: content changed '{md5}cb0264ad1863ee2b3749bd3621cdbdd0' to '{md5}56ac5c1a50c298de4999649b27ef6277'
debug: /Stage[main]/basic::Check-mk/File[/etc/xinetd.d/check_mk]: The container Class[basic::Check-mk] will propagate my refresh event
info: /Stage[main]/basic::Check-mk/File[/etc/xinetd.d/check_mk]: Scheduling refresh of Service[xinetd]
debug: Service[ntp](provider=debian): Executing '/etc/init.d/ntp status'
debug: Service[xinetd](provider=debian): Executing '/etc/init.d/xinetd status'
debug: Service[xinetd](provider=debian): Executing '/etc/init.d/xinetd start'
notice: /Stage[main]/basic::Check-mk/Service[xinetd]/ensure: ensure changed 'stopped' to 'running'
debug: /Stage[main]/basic::Check-mk/Service[xinetd]: The container Class[basic::Check-mk] will propagate my refresh event
debug: Service[xinetd](provider=debian): Executing '/etc/init.d/xinetd status'
debug: /Stage[main]/basic::Check-mk/Service[xinetd]: Skipping restart; service is not running
notice: /Stage[main]/basic::Check-mk/Service[xinetd]: Triggered 'refresh' from 1 events
debug: /Stage[main]/basic::Check-mk/Service[xinetd]: The container Class[basic::Check-mk] will propagate my refresh event
debug: Class[basic::Check-mk]: The container Stage[main] will propagate my refresh event
debug: /Schedule[weekly]: Skipping device resources because running on a host
debug: /Schedule[puppet]: Skipping device resources because running on a host
debug: Finishing transaction 70294346109840
debug: Storing state
debug: Stored state in 0.01 seconds
notice: Finished catalog run in 1.43 seconds
debug: Executing '/etc/puppet/etckeeper-commit-post'
debug: report supports formats: b64_zlib_yaml pson raw yaml; using pson
The following line seems suspicious to me:
debug: /Stage[main]/basic::Check-mk/Service[xinetd]: Skipping restart; service is not running
And service --status-all says [ ? ] xinetd. Why does the system not recognize the state of the service?
Your debug log and the output of your manual service command suggest that your xinetd does not have a working status subcommand. As a result, Puppet does not know how (or whether) to manage its run state.
You could consider fixing the initscript to recognize the status subcommand and make an LSB-compliant response (or at least to exit with code 0 if the service is running and anything else otherwise). Alternatively, you can add a status attribute to the Service resource, giving an alternative command that Puppet can use to ascertain the service's run state. (I have linked to the current docs, but I'm pretty sure that Service has had that attribute since well before Puppet 2.7.)
SOLVED: To fix the problem I had to add a status section to the init.d script of xinetd. Afterwards service xinetd status and puppet were able to recognize the status of the service. The added section looks like this:
status)
if pidof xinetd > /dev/null
then
echo "xinetd is running."
exit 0
else
echo "xinetd is NOT running."
exit 1
fi
;;
Additionaly I added the status option to the Usage line:
*)
echo "Usage: /etc/init.d/xinetd {start|stop|reload|force-reload|restart|status}"
exit 1
;;
This solved the problem.