Re: Compositor crashes when switching tty
Re-iterate the process. Run valgrind, read the log, search for bugs. Until valgrind run smoothly. Best On Wed, May 29, 2019, 02:32 adlo wrote: > On 29 May 2019, at 03:53, Matteo Valdina wrote: > > As valgrind pointing out at shell.c line 982 > > shell = zalloc (sizeof (shell)); > > Here you are allocating the pointer size not the structure size. You > probably want type Shell. > > > This reduces the amount of crashing, but does not completely eliminate it. > My compositor still coredumps when switching vt multiple times, especially > when also opening and closing windows on my compositor. > > What else might I need to do? > > Is this code enough to open a basic display on the DRM backend? > > > https://github.com/adlocode/xfway/blob/9a676ddd9eecc7f8e23915d5c79f57c6368d6fc7/src/main-wayland.c#L276 > > Regards > > adlo > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compositor crashes when switching tty
As valgrind pointing out at shell.c line 982 shell = zalloc (sizeof (shell)); Here you are allocating the pointer size not the structure size. You probably want type Shell. Best Matteo On Tue, May 28, 2019 at 9:36 PM adlo wrote: > On Tue, 2019-05-28 at 13:38 -0400, Adam Jackson wrote: > > On Tue, 2019-05-28 at 08:26 +0100, adlo wrote: > > > When switching tty, my compositor crashes with error messages such > > > as > > > > > > free (): invalid size Aborted (core dumped) > > > or > > > malloc (): invalid chunk size > > > > This means something is corrupting the malloc arena metadata. Run > > your > > compositor under valgrind and fix what it complains about. > > > > Here is the valgrind output: > > ==15641== Memcheck, a memory error detector > ==15641== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et > al. > ==15641== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright > info > ==15641== Command: src/xfway > ==15641== Parent PID: 7074 > ==15641== > ==15641== Invalid write of size 8 > ==15641==at 0x404604: launch_desktop_shell_process (shell.c:961) > ==15641==by 0x48822D2: wl_event_loop_dispatch_idle (in > /usr/lib64/libwayland-server.so.0.1.0) > ==15641==by 0x4882327: wl_event_loop_dispatch (in > /usr/lib64/libwayland-server.so.0.1.0) > ==15641==by 0x4880F24: wl_display_run (in /usr/lib64/libwayland- > server.so.0.1.0) > ==15641==by 0x403A47: main (main-wayland.c:626) > ==15641== Address 0x8f21c58 is 0 bytes after a block of size 8 alloc'd > ==15641==at 0x483AB1A: calloc (vg_replace_malloc.c:762) > ==15641==by 0x4052C2: zalloc (zalloc.h:38) > ==15641==by 0x4052C2: xfway_server_shell_init (shell.c:982) > ==15641==by 0x403A37: main (main-wayland.c:623) > ==15641== > ==15641== Invalid write of size 8 > ==15641==at 0x40460D: launch_desktop_shell_process (shell.c:968) > ==15641==by 0x48822D2: wl_event_loop_dispatch_idle (in > /usr/lib64/libwayland-server.so.0.1.0) > ==15641==by 0x4882327: wl_event_loop_dispatch (in > /usr/lib64/libwayland-server.so.0.1.0) > ==15641==by 0x4880F24: wl_display_run (in /usr/lib64/libwayland- > server.so.0.1.0) > ==15641==by 0x403A47: main (main-wayland.c:626) > ==15641== Address 0x8f21c78 is 24 bytes after a block of size 16 in > arena "client" > ==15641== > ==15641== Invalid write of size 8 > ==15641==at 0x4884AB8: wl_list_insert (in /usr/lib64/libwayland- > server.so.0.1.0) > ==15641==by 0x48822D2: wl_event_loop_dispatch_idle (in > /usr/lib64/libwayland-server.so.0.1.0) > ==15641==by 0x4882327: wl_event_loop_dispatch (in > /usr/lib64/libwayland-server.so.0.1.0) > ==15641==by 0x4880F24: wl_display_run (in /usr/lib64/libwayland- > server.so.0.1.0) > ==15641==by 0x403A47: main (main-wayland.c:626) > ==15641== Address 0x8f21c68 is 16 bytes after a block of size 8 > alloc'd > ==15641==at 0x483AB1A: calloc (vg_replace_malloc.c:762) > ==15641==by 0x4052C2: zalloc (zalloc.h:38) > ==15641==by 0x4052C2: xfway_server_shell_init (shell.c:982) > ==15641==by 0x403A37: main (main-wayland.c:623) > ==15641== > > valgrind: m_mallocfree.c:305 (get_bszB_as_is): Assertion 'bszB_lo == > bszB_hi' failed. > valgrind: Heap block lo/hi size mismatch: lo = 80, hi = 4211536. > This is probably caused by your program erroneously writing past the > end of a heap block and corrupting heap metadata. If you fix any > invalid writes reported by Memcheck, this assertion failure will > probably go away. Please try that before reporting this as a bug. > > > host stacktrace: > ==15641==at 0x58046F6A: ??? (in /usr/libexec/valgrind/memcheck- > amd64-linux) > ==15641==by 0x58047097: ??? (in /usr/libexec/valgrind/memcheck- > amd64-linux) > ==15641==by 0x5804723B: ??? (in /usr/libexec/valgrind/memcheck- > amd64-linux) > ==15641==by 0x580513A3: ??? (in /usr/libexec/valgrind/memcheck- > amd64-linux) > ==15641==by 0x5803DD8A: ??? (in /usr/libexec/valgrind/memcheck- > amd64-linux) > ==15641==by 0x5803CC8F: ??? (in /usr/libexec/valgrind/memcheck- > amd64-linux) > ==15641==by 0x58041E04: ??? (in /usr/libexec/valgrind/memcheck- > amd64-linux) > ==15641==by 0x5803C0C8: ??? (in /usr/libexec/valgrind/memcheck- > amd64-linux) > ==15641==by 0x1002D09984: ??? > ==15641==by 0x1002BA5F2F: ??? > ==15641==by 0x1002BA5F17: ??? > ==15641==by 0x1002BA5F2F: ??? > ==15641==by 0x1002BA5F3F: ??? > > sched status: > running_tid=1 > > Thread 1: status = VgTs_Runnable (lwpid 15641) > ==15641==at 0x4884ABB: wl_list_insert (in /usr/lib64/libwayland- > server.so.0.1.0) > ==15641==by 0x48822D2: wl_event_loop_dispatch_idle (in > /usr/lib64/libwayland-server.so.0.1.0) > ==15641==by 0x4882327: wl_event_loop_dispatch (in > /usr/lib64/libwayland-server.so.0.1.0) > ==15641==by 0x4880F24: wl_display_run (in /usr/lib64/libwayland- > server.so.0.1.0) > ==15641==by 0x403A47: main (main-wayland.c:626) > client stack range: [0x1FFEFF5000 0x1FFF000FFF] client SP:
Re: DMAbuf flickering from three different sources
Thanks, I'll continue to give a look. Best Matteo Valdina On Thu, Oct 4, 2018, 06:29 Pekka Paalanen wrote: > On Thu, 4 Oct 2018 05:59:14 -0500 > Matteo Valdina wrote: > > > Hi Pekka, > > No the problem is also present on weston 4.0 and 5.0. > > > > One interesting note, all sources use the same resolution (4K and > GStreamer > > is using format NV12). > > The two gstreamer sources are in full screen in two different display. > > Sorry, I have no idea. I did get a thought about a patch in master, but > then saw it was from you. :-) > > Maybe it could be some state mixup around the YUV texturing in > GL-renderer, I would assume that to be rarely tested, especially with > multiple simultaneous clients hitting it. > > > Thanks, > pq > > > On Thu, Oct 4, 2018, 05:44 Pekka Paalanen wrote: > > > > > On Wed, 3 Oct 2018 11:19:28 -0500 > > > Matteo Valdina wrote: > > > > > > > Hi Y'all, > > > > > > > > I'm working in a Weston-based compositor (4.0 and later on the 5.0) > and I > > > > faced an issue. > > > > > > > > I have two different sources (1 QT application and 2 GStreamer > > > waylandsink) > > > > that provide content a live stream using the > linux-dmabuf-unstable-v1. > > > > The issue is that the frames of this three sources are displayed in > > > > randomly on all these sources. > > > > > > > > I mean that source 1 display some frame for source 1 and some frame > from > > > > source 2 or 3. And this is affecting multiple processes (the QT > > > application > > > > is a different process). > > > > > > > > It looks like the same DMAbuf pool is shared across all applications. > > > > > > > > This is a Kernel 4.12, Weston 5.0, Qt5, GStreamer 1.14 Mesa 18.1.7 > and on > > > > an Intel HD graphics 610. > > > > > > > > Any suggestions to tackle this? > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: DMAbuf flickering from three different sources
Hi Pekka, No the problem is also present on weston 4.0 and 5.0. One interesting note, all sources use the same resolution (4K and GStreamer is using format NV12). The two gstreamer sources are in full screen in two different display. Best Matteo Valdina On Thu, Oct 4, 2018, 05:44 Pekka Paalanen wrote: > On Wed, 3 Oct 2018 11:19:28 -0500 > Matteo Valdina wrote: > > > Hi Y'all, > > > > I'm working in a Weston-based compositor (4.0 and later on the 5.0) and I > > faced an issue. > > > > I have two different sources (1 QT application and 2 GStreamer > waylandsink) > > that provide content a live stream using the linux-dmabuf-unstable-v1. > > The issue is that the frames of this three sources are displayed in > > randomly on all these sources. > > > > I mean that source 1 display some frame for source 1 and some frame from > > source 2 or 3. And this is affecting multiple processes (the QT > application > > is a different process). > > > > It looks like the same DMAbuf pool is shared across all applications. > > > > This is a Kernel 4.12, Weston 5.0, Qt5, GStreamer 1.14 Mesa 18.1.7 and on > > an Intel HD graphics 610. > > > > Any suggestions to tackle this? > > Hi, > > is this problem only on your own compositor, while upstream Weston > works fine? > > How different is your compositor from Weston, what have you modified? > > I can't imagine what kind of bug in the compositor could cause mixing > up buffers from different clients at the dmabuf level. > > > Thanks, > pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
DMAbuf flickering from three different sources
Hi Y'all, I'm working in a Weston-based compositor (4.0 and later on the 5.0) and I faced an issue. I have two different sources (1 QT application and 2 GStreamer waylandsink) that provide content a live stream using the linux-dmabuf-unstable-v1. The issue is that the frames of this three sources are displayed in randomly on all these sources. I mean that source 1 display some frame for source 1 and some frame from source 2 or 3. And this is affecting multiple processes (the QT application is a different process). It looks like the same DMAbuf pool is shared across all applications. This is a Kernel 4.12, Weston 5.0, Qt5, GStreamer 1.14 Mesa 18.1.7 and on an Intel HD graphics 610. Any suggestions to tackle this? Best Matteo Valdina -- “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” - Tony Hoare ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Busy loop in the wl_priv_signal_final_emit
Hi,
I figure it out. The issue was in my compositor.
For reference, I was using the same wl_listener for multiple clients
(wl_client_add_destroy_listener). This was the root cause of my issue.
Best
Matteo
On Wed, Aug 29, 2018 at 4:46 PM Matteo Valdina
wrote:
> Hi,
> I'm moving my compositor to latest libweston 5.0 /wayland 1.16 library and
> I noticed a regression when I terminate my compositor.
>
> The compositor will never exit because is stuck in a busy loop.
> The busy loop is in the "wl_priv_signal_final_emit" that was added in the
> latest wayland.
>
> And precisely is looping to notify that the same client is disconnected.
> With this code (from here:
> https://github.com/wayland-project/wayland/blame/bb1a8ca91e7d99f54b43ece01674ccbd720ec4bd/src/wayland-server.c#L2057
> )
>
> while (!wl_list_empty(>listener_list)) {
> pos = signal->listener_list.next;
>l = wl_container_of(pos, l, link);
>wl_list_remove(pos);
>wl_list_init(pos);
> l->notify(l, data);
> }
>
> The listener_list is pointing to itself
>
> $3 = {listener_list = {prev = 0x24f7eb0, next = 0x24f7eb0}, emit_list =
> {prev = 0x298f888, next = 0x298f888}}
> But to be empty next should point to _list that it is
> p &$3->listener_list
> $11 = (struct wl_list *) 0x298f878
>
>
> A more expert eye on this codebase can confirm that there is no issue on
> how the wl_list_remove is done in wl_priv_signal_final_emit?
>
> Best
> Matteo Valdina
>
> --
> “There are two ways of constructing a software design: One way is to make
> it so simple that there are obviously no deficiencies, and the other way is
> to make it so complicated that there are no obvious deficiencies. The first
> method is far more difficult.”
> - Tony Hoare
>
--
“There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way is
to make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.”
- Tony Hoare
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Busy loop in the wl_priv_signal_final_emit
Hi,
I'm moving my compositor to latest libweston 5.0 /wayland 1.16 library and
I noticed a regression when I terminate my compositor.
The compositor will never exit because is stuck in a busy loop.
The busy loop is in the "wl_priv_signal_final_emit" that was added in the
latest wayland.
And precisely is looping to notify that the same client is disconnected.
With this code (from here:
https://github.com/wayland-project/wayland/blame/bb1a8ca91e7d99f54b43ece01674ccbd720ec4bd/src/wayland-server.c#L2057
)
while (!wl_list_empty(>listener_list)) {
pos = signal->listener_list.next;
l = wl_container_of(pos, l, link);
wl_list_remove(pos);
wl_list_init(pos);
l->notify(l, data);
}
The listener_list is pointing to itself
$3 = {listener_list = {prev = 0x24f7eb0, next = 0x24f7eb0}, emit_list =
{prev = 0x298f888, next = 0x298f888}}
But to be empty next should point to _list that it is
p &$3->listener_list
$11 = (struct wl_list *) 0x298f878
A more expert eye on this codebase can confirm that there is no issue on
how the wl_list_remove is done in wl_priv_signal_final_emit?
Best
Matteo Valdina
--
“There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way is
to make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.”
- Tony Hoare
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
