Closed martinetd closed 4 years ago
That first one is perplexing. I don't see how we could have a freed instruction in the container's instruction list. We remove it from the list before we free it, unless it somehow got placed into a different container's list but I don't see how that can happen either.
For the second one, it doesn't look like Firefox requested to map. You would have the arrange log messages soon after "New xwayland surface" if it did. In fact, I think it stopped pretty early because when I start Firefox I get heaps of XCB log messages and several surfaces. So maybe that's a Firefox issue, or you had an instance open and it just opened a new tab or something.
As for the actual crash, I note that setting focus to a container can cause seat_set_focus_warp
to destroy a workspace. This is likely the problem - the output is not being arranged, which causes the workspace to not be removed from the output's current
children list. The workspace is marked as destroying, and when it's involved in another transaction it gets freed. I'm reluctant to create a transaction inside seat_set_focus
though, because they should ideally only be done by high level code. If we scatter them everywhere then it becomes a mess and isn't very performant. I'm not sure what the best way is to handle that yet. I'm also not sure why I can't reproduce this.
Yeah I spent a bit of time on the first one and I don't get it either... I can reproduce it once every 10 runs or so though, so added some logs, that makes it quite a bit easier to understand :)
2018-07-04 21:29:33 - [sway/desktop/transaction.c:400] transaction notify view ready by size on view 0x616000178880 con 0x614000020440
2018-07-04 21:29:33 - [sway/desktop/transaction.c:406] found instruction 0x61000028b540, index 0
2018-07-04 21:29:33 - [sway/desktop/transaction.c:382] setting ready instruction 0x61000028b540, index 0
2018-07-04 21:29:33 - [sway/ipc-server.c:371] Client 18 writable
2018-07-04 21:29:33 - [sway/desktop/transaction.c:400] transaction notify view ready by size on view 0x616000178880 con 0x614000020440
2018-07-04 21:29:33 - [sway/desktop/transaction.c:406] found instruction 0x61000028d140, index 1
2018-07-04 21:29:33 - [sway/desktop/transaction.c:382] setting ready instruction 0x61000028b540, index 0
2018-07-04 21:29:33 - [sway/desktop/transaction.c:367] Transaction 0x6060000d6fa0 is ready
2018-07-04 21:29:33 - [sway/desktop/transaction.c:180] Applying transaction 0x6060000d6fa0
2018-07-04 21:29:33 - [sway/desktop/transaction.c:83] destroying transaction 0x6060000d6fa0
2018-07-04 21:29:33 - [sway/desktop/transaction.c:88] destroying instruction 0x61000028b140 from container 0x6dc4a0
2018-07-04 21:29:33 - [sway/desktop/transaction.c:88] destroying instruction 0x61000028b240 from container 0x61400000dc40
2018-07-04 21:29:33 - [sway/desktop/transaction.c:88] destroying instruction 0x61000028b340 from container 0x61400000de40
2018-07-04 21:29:33 - [sway/desktop/transaction.c:88] destroying instruction 0x61000028b440 from container 0x61400000e040
2018-07-04 21:29:33 - [sway/desktop/transaction.c:88] destroying instruction 0x61000028b540 from container 0x614000020440
2018-07-04 21:29:33 - [sway/desktop/transaction.c:88] destroying instruction 0x61000028b640 from container 0x614000020640
2018-07-04 21:29:33 - [sway/desktop/transaction.c:180] Applying transaction 0x6060000d85c0
2018-07-04 21:29:33 - [sway/desktop/transaction.c:83] destroying transaction 0x6060000d85c0
2018-07-04 21:29:33 - [sway/desktop/transaction.c:88] destroying instruction 0x61000028cf40 from container 0x61400000de40
2018-07-04 21:29:33 - [sway/desktop/transaction.c:88] destroying instruction 0x61000028d040 from container 0x61400000e040
2018-07-04 21:29:33 - [sway/desktop/transaction.c:88] destroying instruction 0x61000028d140 from container 0x614000020440
2018-07-04 21:29:33 - [sway/desktop/transaction.c:88] destroying instruction 0x61000028d240 from container 0x614000020640
2018-07-04 21:29:33 - [sway/desktop/transaction.c:382] setting ready instruction 0x61000028d140, index 1
=================================================================
==19747==ERROR: AddressSanitizer: heap-use-after-free on address 0x61000028d1fc at pc 0x000000433b46 bp 0x7ffcf7d017a0 sp 0x7ffcf7d01790
I'm not sure why the second transaction would get applied, but that explains the use-after-free... I can get more logs (or more brain cells usage) if that wasn't enough.
Haven't thought about what you said for 2nd one yet, will try to understand tomorrow maybe
@martinetd Are you still able to reproduce the second crash? If so, would you be able to provide a current trace?
Not sure how helpful this is going to be as I don't really know what I was doing (as usual!), but I got a couple of crashes I couldn't figure easily so writing them here to remember about it:
First one, happened with X11 backend. I have some exec in my config file that spawn 2 x11 windows (one i3-nagbar and one urxvt); and this was started from wmii where I don't have any tagrule configured to let the X11 output float so the output was resized at around the same time as the x11 views appeared. As I don't think it'll be easy to reproduce, filled in some logs before the crash.
Second one I'm honestly not sure what happened, it might be related to what @RyanDwyer mentioned in the workspace pid tracking PR (#2165) as I was just switching workspace after running firefox-wayland, and since it was so slow I expected it to not come up at all, but even with logs I have no idea if that was that... Nothing happened for over 8 seconds after bemenu finished running :/