<div dir="ltr"><table class="gmail-highlight gmail-tab-size gmail-js-file-line-container"><tbody><tr><td id="gmail-LC981" class="gmail-blob-code gmail-blob-code-inner gmail-js-file-line">As valgrind pointing out at shell.c line 982<br><br></td>
      </tr>
      <tr>
        </tr></tbody></table><div>shell = <span class="gmail-pl-c1">zalloc</span> (<span class="gmail-pl-k">sizeof</span> (shell));</div><div><br></div><div>Here you are allocating the pointer size not the structure size. You probably want type Shell.<br></div><div><br></div><div>Best</div><div>Matteo<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 28, 2019 at 9:36 PM adlo <<a href="mailto:adloconwy@gmail.com">adloconwy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 2019-05-28 at 13:38 -0400, Adam Jackson wrote:<br>
> On Tue, 2019-05-28 at 08:26 +0100, adlo wrote:<br>
> > When switching tty, my compositor crashes with error messages such<br>
> > as<br>
> > <br>
> > free (): invalid size Aborted (core dumped) <br>
> > or <br>
> > malloc (): invalid chunk size<br>
> <br>
> This means something is corrupting the malloc arena metadata. Run<br>
> your<br>
> compositor under valgrind and fix what it complains about.<br>
> <br>
<br>
Here is the valgrind output:<br>
<br>
==15641== Memcheck, a memory error detector<br>
==15641== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et<br>
al.<br>
==15641== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright<br>
info<br>
==15641== Command: src/xfway<br>
==15641== Parent PID: 7074<br>
==15641== <br>
==15641== Invalid write of size 8<br>
==15641==    at 0x404604: launch_desktop_shell_process (shell.c:961)<br>
==15641==    by 0x48822D2: wl_event_loop_dispatch_idle (in<br>
/usr/lib64/libwayland-server.so.0.1.0)<br>
==15641==    by 0x4882327: wl_event_loop_dispatch (in<br>
/usr/lib64/libwayland-server.so.0.1.0)<br>
==15641==    by 0x4880F24: wl_display_run (in /usr/lib64/libwayland-<br>
server.so.0.1.0)<br>
==15641==    by 0x403A47: main (main-wayland.c:626)<br>
==15641==  Address 0x8f21c58 is 0 bytes after a block of size 8 alloc'd<br>
==15641==    at 0x483AB1A: calloc (vg_replace_malloc.c:762)<br>
==15641==    by 0x4052C2: zalloc (zalloc.h:38)<br>
==15641==    by 0x4052C2: xfway_server_shell_init (shell.c:982)<br>
==15641==    by 0x403A37: main (main-wayland.c:623)<br>
==15641== <br>
==15641== Invalid write of size 8<br>
==15641==    at 0x40460D: launch_desktop_shell_process (shell.c:968)<br>
==15641==    by 0x48822D2: wl_event_loop_dispatch_idle (in<br>
/usr/lib64/libwayland-server.so.0.1.0)<br>
==15641==    by 0x4882327: wl_event_loop_dispatch (in<br>
/usr/lib64/libwayland-server.so.0.1.0)<br>
==15641==    by 0x4880F24: wl_display_run (in /usr/lib64/libwayland-<br>
server.so.0.1.0)<br>
==15641==    by 0x403A47: main (main-wayland.c:626)<br>
==15641==  Address 0x8f21c78 is 24 bytes after a block of size 16 in<br>
arena "client"<br>
==15641== <br>
==15641== Invalid write of size 8<br>
==15641==    at 0x4884AB8: wl_list_insert (in /usr/lib64/libwayland-<br>
server.so.0.1.0)<br>
==15641==    by 0x48822D2: wl_event_loop_dispatch_idle (in<br>
/usr/lib64/libwayland-server.so.0.1.0)<br>
==15641==    by 0x4882327: wl_event_loop_dispatch (in<br>
/usr/lib64/libwayland-server.so.0.1.0)<br>
==15641==    by 0x4880F24: wl_display_run (in /usr/lib64/libwayland-<br>
server.so.0.1.0)<br>
==15641==    by 0x403A47: main (main-wayland.c:626)<br>
==15641==  Address 0x8f21c68 is 16 bytes after a block of size 8<br>
alloc'd<br>
==15641==    at 0x483AB1A: calloc (vg_replace_malloc.c:762)<br>
==15641==    by 0x4052C2: zalloc (zalloc.h:38)<br>
==15641==    by 0x4052C2: xfway_server_shell_init (shell.c:982)<br>
==15641==    by 0x403A37: main (main-wayland.c:623)<br>
==15641== <br>
<br>
valgrind: m_mallocfree.c:305 (get_bszB_as_is): Assertion 'bszB_lo ==<br>
bszB_hi' failed.<br>
valgrind: Heap block lo/hi size mismatch: lo = 80, hi = 4211536.<br>
This is probably caused by your program erroneously writing past the<br>
end of a heap block and corrupting heap metadata.  If you fix any<br>
invalid writes reported by Memcheck, this assertion failure will<br>
probably go away.  Please try that before reporting this as a bug.<br>
<br>
<br>
host stacktrace:<br>
==15641==    at 0x58046F6A: ??? (in /usr/libexec/valgrind/memcheck-<br>
amd64-linux)<br>
==15641==    by 0x58047097: ??? (in /usr/libexec/valgrind/memcheck-<br>
amd64-linux)<br>
==15641==    by 0x5804723B: ??? (in /usr/libexec/valgrind/memcheck-<br>
amd64-linux)<br>
==15641==    by 0x580513A3: ??? (in /usr/libexec/valgrind/memcheck-<br>
amd64-linux)<br>
==15641==    by 0x5803DD8A: ??? (in /usr/libexec/valgrind/memcheck-<br>
amd64-linux)<br>
==15641==    by 0x5803CC8F: ??? (in /usr/libexec/valgrind/memcheck-<br>
amd64-linux)<br>
==15641==    by 0x58041E04: ??? (in /usr/libexec/valgrind/memcheck-<br>
amd64-linux)<br>
==15641==    by 0x5803C0C8: ??? (in /usr/libexec/valgrind/memcheck-<br>
amd64-linux)<br>
==15641==    by 0x1002D09984: ???<br>
==15641==    by 0x1002BA5F2F: ???<br>
==15641==    by 0x1002BA5F17: ???<br>
==15641==    by 0x1002BA5F2F: ???<br>
==15641==    by 0x1002BA5F3F: ???<br>
<br>
sched status:<br>
  running_tid=1<br>
<br>
Thread 1: status = VgTs_Runnable (lwpid 15641)<br>
==15641==    at 0x4884ABB: wl_list_insert (in /usr/lib64/libwayland-<br>
server.so.0.1.0)<br>
==15641==    by 0x48822D2: wl_event_loop_dispatch_idle (in<br>
/usr/lib64/libwayland-server.so.0.1.0)<br>
==15641==    by 0x4882327: wl_event_loop_dispatch (in<br>
/usr/lib64/libwayland-server.so.0.1.0)<br>
==15641==    by 0x4880F24: wl_display_run (in /usr/lib64/libwayland-<br>
server.so.0.1.0)<br>
==15641==    by 0x403A47: main (main-wayland.c:626)<br>
client stack range: [0x1FFEFF5000 0x1FFF000FFF] client SP: 0x1FFEFFF6C8<br>
valgrind stack range: [0x1002AA6000 0x1002BA5FFF] top usage: 8360 of<br>
1048576<br>
<br>
Thread 2: status = VgTs_WaitSys syscall 202 (lwpid 15659)<br>
==15641==    at 0x57A54E5: pthread_cond_wait@@GLIBC_2.3.2 (in<br>
/usr/lib64/<a href="http://libpthread-2.29.so" rel="noreferrer" target="_blank">libpthread-2.29.so</a>)<br>
==15641==    by 0x6ECC5DA: ??? (in /usr/lib64/dri/i965_dri.so)<br>
==15641==    by 0x6ECC31A: ??? (in /usr/lib64/dri/i965_dri.so)<br>
==15641==    by 0x579F5A1: start_thread (in /usr/lib64/libpthread-<br>
<a href="http://2.29.so" rel="noreferrer" target="_blank">2.29.so</a>)<br>
==15641==    by 0x58B3162: clone (in /usr/lib64/<a href="http://libc-2.29.so" rel="noreferrer" target="_blank">libc-2.29.so</a>)<br>
client stack range: [0x7B2D000 0x832BFFF] client SP: 0x832B9F0<br>
valgrind stack range: [0x1005BC0000 0x1005CBFFFF] top usage: 2936 of<br>
1048576<br>
<br>
<br>
Note: see also the FAQ in the source distribution.<br>
It contains workarounds to several common problems.<br>
In particular, if Valgrind aborted or crashed after<br>
identifying problems in your program, there's a good chance<br>
that fixing those problems will prevent Valgrind aborting or<br>
crashing, especially if it happened in m_mallocfree.c.<br>
<br>
If that doesn't help, please report this bug to: <a href="http://www.valgrind.org" rel="noreferrer" target="_blank">www.valgrind.org</a><br>
<br>
In the bug report, send all the above text, the valgrind<br>
version, and what OS and version you are using.  Thanks.<br>
<br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">“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.”<br>- Tony Hoare</div>