Bus error timeout

GStreamer Daemon
GStreamer Daemon Basics
Building GStreamer Daemon
Quick Start Guide
Interacting with Pipelines
Modifying Element Properties
Sending Events
Receiving Messages from the Bus
EOS Seek Flush start/Flush stop
Receiving Signals
Enabling the Debug Subsystem
Low-level Implementation for Applications
Response Format
API Reference
C/C++ API Python API JavaScript API HTTP API
Simple Examples
Gapless Playback MP4 Video Recording New Clock Slow Motion Reverse Playback Monitor pipeline errors
Advanced Examples
Gstd and Interpipes CCTV Digital Camera GstD Digital PTZ GstD with ROS
API Examples
Python Video Player Example Javascript Video Player Example
Troubleshooting
Interpipesink
Releases
Licensing
FAQ
Contact Us

A GStreamer bus takes care of forwarding messages from a pipeline. A bus is needed so applications do not need to be thread-aware, even though the underlying pipeline is heavily threaded. For GStreamer Daemon, the concept of a bus is not important, but we use the terminology to maintain consistency with GStreamer. What is important is a pipeline can generate messages and GStreamer Daemon allows those messages to flow back to the client application.

This wiki describes the basics of how to interact with GStreamer bus properties. Specifically, how to receive messages from the bus. You’ll find that the family of commands used to interact with pipelines are prefixed with bus_<action>.

Read bus

In order to read a bus use the following command:

bus_read <name> 
       Read the bus of the pipeline.

Read and filter bus

Sometimes is important to read and filter some messages from the bus, Gstd has the capability to read and filter (ie:error+warning+eos), In order to read and filter use the following command:

bus_filter <name> <filter> 
       Read and filter the bus of the pipeline.

Bus timeout

This command will block while waiting for messages set with the bus_filter command. You can specify a maximum time with the timeout parameter, the time argument is set on nanoseconds.

bus_timeout <name> <time in nanoseconds> 
       bus timeout of the pipeline.

There are lots of bus messages that are defined. The documentation tends to lag the implementation, so if you want the latest, most complete list of support bus messages, look at the gstd_msg_type_get_type table in gstd_msg_type.c.

The following table lists the supported bus messages. You can use either a hyphen or underscore in the bus message name.

Examples Application

A very useful application using a bus filter is when is needed to know if there is an error or EOS. These examples show how to use the bus filter and bus read.

Error bus filter

This example only filter errors with an infinite timeout.

⇒ Gstd Commands:

 1 # Create the pipeline that generate an error  
 2 pipeline_create p filesrc location=/tmp/test.avi ! identity error-after=2000 ! avidemux ! avdec_mpeg4 ! fpsdisplaysink 
 3 
 4 # Filter only a message error
 5 bus_filter p error
 6 
 7 # Play the pipeline
 8 pipeline_play p
 9 
10 # Waiting until bus read a message error 
11 bus_read p

Error bus filter and timeout

This example only filter errors with a 100s of timeout. If did get an error message it returns

⇒ Gstd Commands:

 1 # Create the pipeline that generate an error  
 2 pipeline_create p filesrc location=/tmp/test.avi ! identity error-after=2000 ! avidemux ! avdec_mpeg4 ! fpsdisplaysink 
 3 
 4 # Filter only a message error
 5 bus_filter p error
 6 
 7 # wait 100s to read message error, if not, returns 
 8 bus_timeout p 100000000000 
 9 
10 # Play the pipeline
11 pipeline_play p
12 
13 # Waiting until bus read a message error 
14 bus_read p

Error+EOS bus filter

This example filter errors and eos messages with an infinite timeout.

⇒ Gstd Commands:

 1 # Create the pipeline that generate an eos  
 2 pipeline_create p filesrc location=/tmp/test.avi  ! avidemux ! avdec_mpeg4 ! fpsdisplaysink 
 3 
 4 # Filter a message error and EOS message
 5 bus_filter p error+eos
 6 
 7 # Play the pipeline
 8 pipeline_play p
 9 
10 # Waiting until bus read a message error or eos message
11 bus_read p

⇒ Example Gstd bus_read Response:

 1 {
 2   "code" : 0,
 3   "description" : "Success",
 4   "response" : {
 5     "type" : "error",
 6     "source" : "avidemux2",
 7     "timestamp" : "99:99:99.999999999",
 8     "seqnum" : 104,
 9     "message" : "Internal data stream error.",
10     "debug" : "gstavidemux.c(5713): gst_avi_demux_loop (): /GstPipeline:p/GstAviDemux:avidemux2:nstreaming stopped, reason not-linked"
11   }
12 }

Соседние файлы в предмете Микроконтроллеры ЭВМ

• #
• #

  16.04.2013108.52 Кб13MC68000.txt

• #
• #

  16.04.201356 б10readme.txt

I strongly suggest you to update to version 0.7. It is now made its way to p9 and sisyphus repos so you won’t need any additional repos from now on. I did a large rewrite of GPT parsing functionality and fixed several critical bugs since 0.6.

Usually gpoa must be run by oddjobd with root privileges without any user interaction. It is supposed you (as a user) will use gpupdate utility to trigger group policy updates via D-Bus but at the moment it is unable to pass loglevel parameter.

As for the problem I can see the following log entries:

2020-07-22 08:44:56:GPO: GPO-WPP-Setting ({GUIDGUID-GUID-GUID-GUID-GUIDGUIDGUID})
2020-07-22 08:45:52:Re-caching Local Policy

Look at the timestamps. Policy parsing and re-caching begins right after GPO replication so it took nearly one minute to replicate policies. I think we need to investigate the case. Could you please tell me the size of the GPTs which were replicated? I want to determine if it is just slow network problem or Samba bug (because I use Samba code to trigger GPO replication).

We will try to update oddjobd to overcome the problem anyway.

P. S.: I would be glad if you tell me if it is needed to make the documentation on ALTWiki or on GitHub more user-friendly or verbose so it will be easier to use the software. Any suggestions and comments will be appreciated.

Ошибка на шине (bus error)- это ошибка, которая была вызвана аппаратным обеспечением, уведомляющим операционную систему о том , что процесс пытается получить доступ к памяти, которую процессор не может физически адресовать из-за того, что у адресной шины недопустимый адрес, а следовательно, и имя. В современном использовании на большинстве архитектур они встречаются гораздо реже , чем ошибки сегментации, которые возникают в основном из-за нарушений доступа к памяти: проблем с логическим адресом или разрешениями.
На платформах, совместимых с портативным интерфейсом операционной системы( POSIX), ошибки шины обычно приводят к тому, что сигнал SIGBUS, который сигнализирует об ошибке шины, при обращении к физической памяти, передается процессу, который вызвал ошибку. SIGBUS также может быть вызван любой общей неисправностью устройства, которую обнаруживает компьютер, хотя ошибка шины редко означает, что компьютерное оборудование физически сломано, в основном это вызвано ошибкой в программном обеспечении.

Причины возникновения

Существует 4 основных причины возникновения данной ошибки.
Рассмотрим каждую из них.

Недействующий адрес

Программное обеспечение указывает процессору на чтение или запись определенного адреса физической памяти . Соответственно, центральный процессор устанавливает этот физический адрес на своей адресной шине и запрашивает все другое оборудование, подключенное к нему, чтобы ответить с результатами, если они отвечают за этот конкретный адрес. Если никакое другое оборудование не отвечает, центральный процессор вызывает исключение, указывающее, что запрошенный физический адрес не распознан всей компьютерной системой. Состоит отметить, что это касается только физических адресов памяти. Попытка доступа к неопределенному адресу виртуальной памяти обычно считается ошибкой сегментации, а не ошибкой шины, хотя если блок управления памятью (MMU) является отдельным, процессор не может определить разницу.

Несогласованный доступ

В основном центральные процессоры (CPU) являются байт-адресуемыми, где каждый уникальный адрес памяти ссылается на 8-битный байт . Большинство из них могут получить доступ к отдельным байтам из каждого адреса памяти, но они, как правило, не могут получить доступ к более крупным блокам (16 бит, 32 бит, 64 бит и т. д.) без «выравнивания» структуры данных этих блоков к определенной границе.
К примеру, если многобайтовый доступ должен быть 16-битным, адреса (заданные в байтах) в 0, 2, 4, 6 и так далее будут считаться выровненными и, следовательно, доступными, в то время как адреса 1, 3, 5 и так далее будут считаться не выровненными. Аналогично, если многобайтовый доступ должен быть 32-разрядным, адреса 0, 4, 8, 12 и так далее будут считаться выровненными и, следовательно, доступными, а все промежуточные адреса будут считаться не выровненными. Попытка получить доступ к блоку размером больше байта по не выровненному адресу может привести к ошибке шины.
Некоторые системы могут быть смешанные в зависимости от используемой архитектуры. Например, для аппаратного обеспечения, основанного на мэйнфрейме IBM System/360 , включая IBM System z, Fujitsu B8000, RCA Spectra и UNIVAC Series 90 , инструкции должны находиться на 16-разрядной границе, то есть адреса выполнения должны начинаться с четного байта. Попытка ветвления на нечетный адрес приводит к исключению спецификации. Данные, однако, могут быть извлечены из любого адреса в памяти, и могут быть размером от одного байта или больше, в зависимости от инструкции.
Процессоры, как правило, получают доступ к данным на всей ширине своей шины данных в любое время.
Система связи , которая передает данные между компонентами внутри компьютера или между компьютерами.Шина это система связи , которая передает данные между компонентами внутри компьютера или между компьютерами. Чтобы обратиться к байтам, они обращаются к памяти на всей ширине своей шины данных, затем маскируют и сдвигают для обращения к отдельному байту. Системы терпят этот неэффективный алгоритм, так как он является неотъемлемой особенностью большинства программ, особенно обработки строк. В отличие от байтов, большие блоки могут охватывать два выровненных адреса и, таким образом, требуют более одной выборки на шине данных. Процессоры могут поддерживать эту функцию, но эта функциональность редко требуется непосредственно в машинном коде уровень, таким образом, проектировщики центрального процессора обычно избегают его реализации и вместо этого выдают ошибки шины для не выровненного доступа к памяти.

Ошибка страницы

Такие ОС как,FreeBSD, Linux и Solaris могут сигнализировать об ошибке шины, когда страницы виртуальной памяти не могут быть выгружены, например, потому, что она исчезла (например, доступ к файлу с отображением памяти или выполнение двоичного образа, который был усечен во время работы программы), или потому, что только что созданный файл с отображением памяти не может быть физически выделен, потому что диск заполнен.

Несуществующий сегмент(x86)

На x86(емейство архитектур наборов команд,основанных на микропроцессоре Intel 8086 ) существует старый механизм управления памятью, известный как сегментация. Если приложение загружает регистр сегмента с селектором несуществующего сегмента , генерируется исключение. Некоторые ОС использовали это для подкачки, но под Linux это генерирует SIGBUS.

Источники

1. https://stackoverflow.com/questions/212466/what-is-a-bus-error
2. https://www.geeksforgeeks.org/segmentation-fault-sigsegv-vs-bus-error-sigbus/
3. https://studfiles.net/preview/307512/page:15/

mmap minimal POSIX 7 example

«Bus error» happens when the kernel sends SIGBUS to a process.

A minimal example that produces it because ftruncate was forgotten:

#include <fcntl.h> /* O_ constants */
#include <unistd.h> /* ftruncate */
#include <sys/mman.h> /* mmap */

int main() {
    int fd;
    int *map;
    int size = sizeof(int);
    char *name = "/a";

    shm_unlink(name);
    fd = shm_open(name, O_RDWR | O_CREAT, (mode_t)0600);
    /* THIS is the cause of the problem. */
    /*ftruncate(fd, size);*/
    map = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    /* This is what generates the SIGBUS. */
    *map = 0;
}

Run with:

gcc -std=c99 main.c -lrt
./a.out

Tested in Ubuntu 14.04.

POSIX describes SIGBUS as:

Access to an undefined portion of a memory object.

The mmap spec says that:

References within the address range starting at pa and continuing for len bytes to whole pages following the end of an object shall result in delivery of a SIGBUS signal.

And shm_open says that it generates objects of size 0:

The shared memory object has a size of zero.

So at *map = 0 we are touching past the end of the allocated object.

Unaligned stack memory accesses in ARMv8 aarch64

This was mentioned at: What is a bus error? for SPARC, but here I will provide a more reproducible example.

All you need is a freestanding aarch64 program:

.global _start
_start:
asm_main_after_prologue:
    /* misalign the stack out of 16-bit boundary */
    add sp, sp, #-4
    /* access the stack */
    ldr w0, [sp]

    /* exit syscall in case SIGBUS does not happen */
    mov x0, 0
    mov x8, 93
    svc 0

That program then raises SIGBUS on Ubuntu 18.04 aarch64, Linux kernel 4.15.0 in a ThunderX2 server machine.

Unfortunately, I can’t reproduce it on QEMU v4.0.0 user mode, I’m not sure why.

The fault appears to be optional and controlled by the SCTLR_ELx.SA and SCTLR_EL1.SA0 fields, I have summarized the related docs a bit further here.