Coredump caused by memory error: Apparently invalid write #7102
Labels
bug
Not working as intended
Comments
|
I just got another crash, in the same circumstances (when going back, and unlocking) Log lines just before the crash: |
|
A different stacktrace (crash this morning) #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007fd594633543 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007fd5945e3998 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007fd5945cd53d in __GI_abort () at abort.c:79
#4 0x00007fd59462767e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fd594746433 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#5 0x00007fd59463d26c in malloc_printerr (str=str@entry=0x7fd594744062 "corrupted double-linked list") at malloc.c:5660
#6 0x00007fd59463dd34 in unlink_chunk (p=p@entry=0x561532888a30, av=0x7fd594780aa0 <main_arena>) at malloc.c:1629
#7 0x00007fd59463dec5 in malloc_consolidate (av=av@entry=0x7fd594780aa0 <main_arena>) at malloc.c:4776
#8 0x00007fd5946403b0 in _int_malloc (av=av@entry=0x7fd594780aa0 <main_arena>, bytes=bytes@entry=1088) at malloc.c:3961
#9 0x00007fd5946414bd in __GI___libc_malloc (bytes=1088) at malloc.c:3323
#10 0x00007fd591efd1a6 in ralloc_size() () at ../mesa-22.1.4/src/util/ralloc.c:120
#11 0x00007fd591efede1 in rzalloc_size () at ../mesa-22.1.4/src/util/ralloc.c:153
#12 rzalloc_array_size () at ../mesa-22.1.4/src/util/ralloc.c:233
#13 _mesa_hash_table_rehash() () at ../mesa-22.1.4/src/util/hash_table.c:403
#14 0x00007fd591eff108 in hash_table_insert() () at ../mesa-22.1.4/src/util/hash_table.c:440
#15 0x00007fd592b02591 in iris_bo_import_dmabuf() () at ../mesa-22.1.4/src/gallium/drivers/iris/iris_bufmgr.c:1924
#16 0x00007fd592b1b055 in iris_resource_from_handle() () at ../mesa-22.1.4/src/gallium/drivers/iris/iris_resource.c:1328
#17 0x00007fd591ef6d82 in dri2_create_image_from_winsys() () at ../mesa-22.1.4/src/gallium/frontends/dri/dri2.c:943
#18 0x00007fd591ef78d7 in dri2_create_image_from_fd() () at ../mesa-22.1.4/src/gallium/frontends/dri/dri2.c:1082
#19 0x00007fd591ef7a83 in dri2_from_dma_bufs2() () at ../mesa-22.1.4/src/gallium/frontends/dri/dri2.c:1689
#20 0x00007fd5938c3b50 in dri2_create_image_dma_buf.constprop.0 () at ../mesa-22.1.4/src/egl/drivers/dri2/egl_dri2.c:2922
#21 0x00007fd5938a7cdc in _eglCreateImageCommon () at ../mesa-22.1.4/src/egl/main/eglapi.c:1749
#22 0x00007fd59483feea in wlr_egl_create_image_from_dmabuf (egl=0x561531969030, attributes=attributes@entry=0x7fff52709de0, external_only=external_only@entry=0x7fff52709ddf)
at ../wlroots-0.15.1/render/egl.c:722
#23 0x00007fd59484915f in create_buffer (wlr_buffer=0x5615327e2fd0, renderer=0x561531a6b7f0) at ../wlroots-0.15.1/render/gles2/renderer.c:109
#24 gles2_bind_buffer (wlr_renderer=0x561531a6b7f0, wlr_buffer=0x5615327e2fd0) at ../wlroots-0.15.1/render/gles2/renderer.c:179
#25 0x00007fd59483e481 in renderer_bind_buffer (buffer=0x5615327e2fd0, r=0x561531a6b7f0) at ../wlroots-0.15.1/render/wlr_renderer.c:68
#26 wlr_renderer_begin_with_buffer (r=0x561531a6b7f0, buffer=0x5615327e2fd0) at ../wlroots-0.15.1/render/wlr_renderer.c:81
#27 0x00007fd59486a19b in render_cursor_buffer (cursor=0x56153246fcc0) at ../wlroots-0.15.1/types/output/cursor.c:313
#28 output_cursor_attempt_hardware (cursor=cursor@entry=0x56153246fcc0) at ../wlroots-0.15.1/types/output/cursor.c:352
#29 0x00007fd59486a6a9 in output_cursor_commit (cursor=0x56153246fcc0, update_hotspot=<optimized out>) at ../wlroots-0.15.1/types/output/cursor.c:435
#30 0x00007fd59489bc5e in wlr_signal_emit_safe (signal=<optimized out>, data=0x56153279a440) at ../wlroots-0.15.1/util/signal.c:29
#31 0x00007fd593f8e536 in ffi_call_unix64 () at ../src/x86/unix64.S:105
#32 0x00007fd593f8b037 in ffi_call_int (cif=<optimized out>, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>, closure=<optimized out>) at ../src/x86/ffi64.c:672
#33 0x00007fd5948f0ada in wl_closure_invoke (closure=closure@entry=0x5615327f5c30, target=<optimized out>, target@entry=0x5615327ac790, opcode=opcode@entry=6, data=<optimized out>,
data@entry=0x561531a3b3a0, flags=2) at ../wayland-1.21.0/src/connection.c:1025
#34 0x00007fd5948f5010 in wl_client_connection_data (fd=<optimized out>, mask=<optimized out>, data=<optimized out>) at ../wayland-1.21.0/src/wayland-server.c:437
#35 0x00007fd5948f39e2 in wl_event_loop_dispatch (loop=0x56153195b420, timeout=timeout@entry=-1) at ../wayland-1.21.0/src/event-loop.c:1027
#36 0x00007fd5948f4197 in wl_display_run (display=0x56153195b330) at ../wayland-1.21.0/src/wayland-server.c:1431
#37 0x000056152fd8ca10 in server_run (server=<optimized out>) at ../sway-1.7/sway/server.c:304
#38 main (argc=<optimized out>, argv=<optimized out>) at ../sway-1.7/sway/main.c:431 |
|
Nah, it doesn't seem like a driver issue, it seems like a memory corruption issue. |
|
It's an iGPU (`00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)`).
More info:
The dock is a Thunderbolt 3:
```
50:00.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge DD 2018] (rev 06)
51:02.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge DD 2018] (rev 06)
51:04.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge [Titan Ridge DD 2018] (rev 06)
52:00.0 USB controller: Intel Corporation JHL7540 Thunderbolt 3 USB Controller [Titan Ridge DD 2018] (rev 06)
```
Laptop is the Thinkpad X1 Carbon Gen 9, the dock came with it (that's my
new work machine). The external monitor is a `Dell Inc. DELL U2414H 9TG4645J4YYL` as reported by swaymsg -t get_outputs.
The bugs linked do not seem that similar to me. One of them is crashing
by disconnecting the output, the other crash while locked, while mine
only happen just after the unlock. (And middle one is just swaylock
crashing, not sway, unless I can't read)
|
|
Latest incidence (same circumstances): #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007fe73280b543 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007fe7327bb998 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007fe7327a553d in __GI_abort () at abort.c:79
#4 0x00007fe7327ff67e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fe73291e433 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#5 0x00007fe73281526c in malloc_printerr (str=str@entry=0x7fe732921628 "malloc(): unaligned tcache chunk detected") at malloc.c:5660
#6 0x00007fe73281972c in tcache_get (tc_idx=<optimized out>) at malloc.c:3189
#7 __GI___libc_malloc (bytes=bytes@entry=56) at malloc.c:3307
#8 0x00007fe732fa1293 in json_object_new (to_json_string=0x7fe732fa3480 <json_object_int_to_json_string>, alloc_size=56, o_type=json_type_int) at /usr/src/debug/json-c/json_object.c:314
#9 json_object_new_int64 (i=i@entry=0) at /usr/src/debug/json-c/json_object.c:757
#10 0x00007fe732fa12ed in json_object_new_int (i=i@entry=0) at /usr/src/debug/json-c/json_object.c:690
#11 0x0000563ccb4bfd83 in ipc_json_create_node
(id=4, type=0x563ccb51bd9f "workspace", name=name@entry=0x563ccd2cea60 "1", focused=<optimized out>, focus=focus@entry=0x563ccd2e1fa0, box=box@entry=0x7ffe2c929db0)
at ../sway-1.7/sway/ipc-json.c:227
#12 0x0000563ccb4c00e5 in ipc_json_describe_node (node=node@entry=0x563ccd388040) at ../sway-1.7/sway/ipc-json.c:702
#13 0x0000563ccb4c1456 in ipc_json_describe_node_recursive (node=node@entry=0x563ccd388040) at ../sway-1.7/sway/ipc-json.c:723
#14 0x0000563ccb4c77c2 in ipc_event_workspace (change=0x563ccb5160c9 "focus", new=0x563ccd381490, old=0x563ccd388040) at ../sway-1.7/sway/ipc-server.c:310
#15 ipc_event_workspace (old=0x563ccd388040, new=0x563ccd381490, change=0x563ccb5160c9 "focus") at ../sway-1.7/sway/ipc-server.c:301
#16 0x0000563ccb4dafa8 in set_workspace (new_ws=<optimized out>, seat=0x563ccd0af650) at ../sway-1.7/sway/input/seat.c:1101
#17 seat_set_focus (seat=0x563ccd0af650, node=<optimized out>) at ../sway-1.7/sway/input/seat.c:1200
#18 0x0000563ccb4deb5b in check_focus_follows_mouse (seat=0x563ccd0af650, e=0x563ccd8039c0, hovered_node=<optimized out>) at ../sway-1.7/sway/input/seatop_default.c:554
#19 0x0000563ccb4dee5e in handle_pointer_motion (seat=0x563ccd0af650, time_msec=6531883) at ../sway-1.7/sway/input/seatop_default.c:586
#20 0x00007fe732a75c5e in wlr_signal_emit_safe (signal=<optimized out>, data=0x7ffe2c92a0e0) at ../wlroots-0.15.1/util/signal.c:29
#21 0x00007fe732a75c5e in wlr_signal_emit_safe (signal=<optimized out>, data=0x7ffe2c92a0e0) at ../wlroots-0.15.1/util/signal.c:29
#22 0x00007fe732a34c6c in handle_pointer_motion (libinput_dev=<optimized out>, event=0x563ccd7883b0) at ../wlroots-0.15.1/backend/libinput/pointer.c:41
#23 handle_libinput_event (event=0x563ccd7883b0, backend=0x563ccc8b6ef0) at ../wlroots-0.15.1/backend/libinput/events.c:251
#24 handle_libinput_readable (fd=<optimized out>, mask=<optimized out>, _backend=<optimized out>) at ../wlroots-0.15.1/backend/libinput/backend.c:58
#25 handle_libinput_readable (fd=<optimized out>, mask=<optimized out>, _backend=0x563ccc8b6ef0) at ../wlroots-0.15.1/backend/libinput/backend.c:48
#26 0x00007fe732acd9e2 in wl_event_loop_dispatch (loop=0x563ccc8b5320, timeout=timeout@entry=-1) at ../wayland-1.21.0/src/event-loop.c:1027
#27 0x00007fe732ace197 in wl_display_run (display=0x563ccc8b5230) at ../wayland-1.21.0/src/wayland-server.c:1431
#28 0x0000563ccb4bea10 in server_run (server=<optimized out>) at ../sway-1.7/sway/server.c:304
#29 main (argc=<optimized out>, argv=<optimized out>) at ../sway-1.7/sway/main.c:431Log: |
|
Looks indeed like memory corruption to me. The crash occurs here which is very strange. Have you tried master or running with valgrind? |
|
On Tue, Aug 23, 2022 at 02:13:20AM -0700, Simon Zeni wrote:
Looks indeed like memory corruption to me. The crash occurs [here](https://github.com/swaywm/sway/blob/v1.7/sway/ipc-json.c#L228) which is very strange.
Does not seem that strange to me. Once we corrupt memory, another
allocation after that goes through the allocator and we trigger and
assertion on its internal integrity. `json_object_new_int` seems like
something which would do allocations to me.
Have you tried master or running with valgrind?
Valgrind run is up the thread. I haven't tried master, mostly because
the crash are really infrequent (previous one was 2 two weeks ago), not
exactly an easy reproducer, even though it does occur in similar
circumstances.
If I can find the time, I'll see if I can get an easy reproducer on
master with asan ; I suspect the randomness could be due to the
corrupted memory not being tripped upon by malloc on each run.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Yesterday I had sway dumping core, and apparently it also happened last week (coredump file is gone though for that one). I run valgrind on it (since the stack trace was about a corrupted malloc) and it seems there might be an invalid write or two.
If you need more info I should be able to rebuild with a sanitizer.
Please fill out the following:
Sway Version: 1.7
Stack Trace:
coredumpctl gdb swayand thenbt fullto obtain the stack trace.??for the location, your binaries were built without debug symbols. Please compile both sway and wlroots from source and try to reproduce.Valgrind run:
Sway is run like this on my setup (from the system systemd instance):
The only I can find from the sway process at the time of crash :
-> the glibc malloc.
It happened after I unlocked my session (swaylock) and I was connected to an external monitor (HDMI through USB-C dock).
I can upload the corefile if needed.
The text was updated successfully, but these errors were encountered: