New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i3bar disappears when switch by mouse to workspace with lot of windows #3579

Closed
bluecub opened this Issue Jan 9, 2019 · 25 comments

Comments

Projects
None yet
5 participants
@bluecub
Copy link

bluecub commented Jan 9, 2019

I'm submitting a…

[x] Bug
[ ] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

i3 bar keep disappearing, I observed it usually happens when I have workspace with lot tiles and I use my mouse to switch between workspaces. Doesn't happen with I have few windows.

Expected Behavior

the bar shouldn't disappear

Reproduction Instructions

whenever I create a workspace with lot of windows (tiles) and try to switch between workspaces using the mouse. I even replaced the config file by the sample one shipped with i3 and repeated the same thing and it crashed. I tried to disable the i3status and just keep the bar with the workspace numbers and repeated the creation a workspace with lot of tiles and switch using the mouse, and the bar crashed.

Environment

Output of i3 --moreversion 2>&-:

i3 version: 
Binary i3 version:  4.16 (2018-11-04) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.16 (2018-11-04) (pid 90270) abort…)
Loaded i3 config: /home/ram/.config/i3/config (Last modified: Wed Jan  9 20:28:31 2019, 3366 seconds ago)
It happened in my config file, and with the sample config file shipped with i3.
Logfile URL:
[logfile.log](https://github.com/i3/i3/files/2740441/logfile.log)

- FreeBSD: 
% uname -a
FreeBSD Main-WS 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  amd64

- Are you using a compositor (e.g., xcompmgr or compton): compton Version: 20160907_4

Thanks

@i3bot

This comment has been minimized.

Copy link

i3bot commented Jan 9, 2019

I don’t see a link to logs.i3wm.org. Did you follow https://i3wm.org/docs/debugging.html? (In case you actually provided a link to a logfile, please ignore me.)

@orestisf1993

This comment has been minimized.

Copy link
Member

orestisf1993 commented Jan 9, 2019

Please follow the instructions in debugging i3bar

@bluecub

This comment has been minimized.

Copy link

bluecub commented Jan 9, 2019

I followed this #1661 as I was getting the same error when trying to i3-dump-log the error:
i3-dump-log: Could not shm_open SHM segment for the i3 log (/tmp/i3-log-2393): No such file or directory

@bluecub

This comment has been minimized.

Copy link

bluecub commented Jan 9, 2019

@orestisf1993

This comment has been minimized.

Copy link
Member

orestisf1993 commented Jan 9, 2019

Thanks, but we also need the i3bar output, see section 7

@bluecub

This comment has been minimized.

Copy link

bluecub commented Jan 9, 2019

Hi @orestisf1993
i3bar.bar-0.log
Not sure if this will help

@bluecub

This comment has been minimized.

Copy link

bluecub commented Jan 9, 2019

Sorry updated the log file as per section 7

@orestisf1993

This comment has been minimized.

Copy link
Member

orestisf1993 commented Jan 9, 2019

Launch i3bar like this and redirect its output: i3bar --bar_id=bar-0 --verbose &> bar.log

@bluecub

This comment has been minimized.

Copy link

bluecub commented Jan 9, 2019

bar.log
once I change the workspace with the mouse it disappeared.

Expected: i3-ipc
ports/x11-wm/i3/work/i3-4.16/../i3-4.16/i3bar/src/ipc.c:136] Got workspace event!
[/wrkdirs/usr/ports/x11-wm/i3/work/i3-4.16/../i3-4.16/i3bar/src/ipc.c:217] Got data!
Exiting due to signal.

@orestisf1993

This comment has been minimized.

Copy link
Member

orestisf1993 commented Jan 9, 2019

Thanks!

@orestisf1993

This comment has been minimized.

Copy link
Member

orestisf1993 commented Jan 9, 2019

I can reproduce this in a freebsd virtual machine but I don't have time to learn freebsd to debug this right now. My first guess would be to revert #3263 and see if the issue persists.

@bluecub

This comment has been minimized.

Copy link

bluecub commented Jan 9, 2019

Hi @orestisf1993 , I am a bit confused are you suggesting I revert back to an old version?

@orestisf1993

This comment has been minimized.

Copy link
Member

orestisf1993 commented Jan 11, 2019

Confirming that this doesn't happen with 4.15 is a good first step but I'd like to revert the changes introduced in #3263 to check if they are responsible for the bug.

@orestisf1993

This comment has been minimized.

Copy link
Member

orestisf1993 commented Jan 11, 2019

Ok, I managed to check it myself. #3263 introduces this issue.

@orestisf1993 orestisf1993 self-assigned this Jan 11, 2019

orestisf1993 added a commit to orestisf1993/i3 that referenced this issue Jan 11, 2019

Use ipc queue for all messages
I was able to reproduce i3#3579 in Linux by running:
`sudo sysctl net.core.wmem_default=10000`

If a subscription message was too big to be sent at once, it was
possible to break a client by sending a reply to an other message sent
by the client. Eg:
- Write 8192 out of 11612 bytes of a workspace event.
- Blockingly write the reply to a workspace change message.
- Write the rest 3420 bytes of the workspace event.

This commit fixes this by utilizing the ipc queue for all types of
writes.

ipc_receive_message can only be called from a callback started in
ipc_new_client. This callback uses the same file descriptor with the
client also created in ipc_new_client. When the client is deleted, the
read callback is now also stopped. Thus, we can assume that whenever
ipc_receive_message is called, the corresponding client should still
exist.

- ipc_client now contains pointers to both write and read watchers. When
freed, a client will stop both of them.
- IPC_HANDLERs now work with ipc_clients instead of fds.

Fixes i3#3579.
@bluecub

This comment has been minimized.

Copy link

bluecub commented Jan 12, 2019

Ok, I managed to check it myself. #3263 introduces this issue.

Thanks a lot...

@orestisf1993

This comment has been minimized.

Copy link
Member

orestisf1993 commented Jan 12, 2019

Until this gets fixed, you can work around it by running sysctl net.local.stream.sendspace=106496 (13 times the default of 8192). You can make the change permanent by editing /etc/sysctl.conf.

@bluecub

This comment has been minimized.

Copy link

bluecub commented Jan 12, 2019

Brilliant thanks heaps....

stapelberg added a commit that referenced this issue Jan 12, 2019

Use ipc queue for all messages (#3585)
I was able to reproduce #3579 in Linux by running:
`sudo sysctl net.core.wmem_default=10000`

If a subscription message was too big to be sent at once, it was
possible to break a client by sending a reply to an other message sent
by the client. Eg:
- Write 8192 out of 11612 bytes of a workspace event.
- Blockingly write the reply to a workspace change message.
- Write the rest 3420 bytes of the workspace event.

This commit fixes this by utilizing the ipc queue for all types of
writes.

ipc_receive_message can only be called from a callback started in
ipc_new_client. This callback uses the same file descriptor with the
client also created in ipc_new_client. When the client is deleted, the
read callback is now also stopped. Thus, we can assume that whenever
ipc_receive_message is called, the corresponding client should still
exist.

- ipc_client now contains pointers to both write and read watchers. When
freed, a client will stop both of them.
- IPC_HANDLERs now work with ipc_clients instead of fds.

Fixes #3579.
@anowlcalledjosh

This comment has been minimized.

Copy link

anowlcalledjosh commented Jan 15, 2019

That workaround doesn't work for me:

$ sudo sysctl net.local.stream.sendspace=106496
sysctl: cannot stat /proc/sys/net/local/stream/sendspace: No such file or directory

Apparently nothing under net.local exists on my system:

$ sudo sysctl net.local
sysctl: cannot stat /proc/sys/net/local: No such file or directory

Is there another workaround, or do I have to wait until the fix lands in a release?

@bluecub

This comment has been minimized.

Copy link

bluecub commented Jan 15, 2019

$ sudo sysctl net.local.stream.sendspace=106496 sysctl: cannot stat /proc/sys/net/local/stream/sendspace: No such file or directory

Are you using freeBSD?

@Main-WS:~/.config % sudo sysctl net.local.stream.sendspace
net.local.stream.sendspace: 8192

Check the forum: https://forums.freebsd.org/threads/sysctl-conf-question.48007/

@orestisf1993

This comment has been minimized.

Copy link
Member

orestisf1993 commented Jan 15, 2019

Maybe we can make a bugfix release @stapelberg ? I feel that the regressions we fixed recently can affect many people.

@stapelberg

This comment has been minimized.

Copy link
Member

stapelberg commented Jan 15, 2019

Sure. Can you send me an email with all the fixes that should be included (if it’s more than just this issue) please? I can try to get one out in the next few days.

@bluecub

This comment has been minimized.

Copy link

bluecub commented Jan 15, 2019

Thank you so much @orestisf1993 and @stapelberg :)

@anowlcalledjosh

This comment has been minimized.

Copy link

anowlcalledjosh commented Jan 15, 2019

Are you using freeBSD?

Nope, just Ubuntu 18.04 (kernel 4.15).

I'm happy to wait a few days for a bugfix release though :)

@orestisf1993

This comment has been minimized.

Copy link
Member

orestisf1993 commented Jan 15, 2019

Nope, just Ubuntu 18.04 (kernel 4.15).

Interesting. What's the output of sysctl net.core.wmem_default and sysctl net.core.wmem_max?

@anowlcalledjosh

This comment has been minimized.

Copy link

anowlcalledjosh commented Jan 15, 2019

212992 for both.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment