arakiken / mlterm

Other
155 stars 13 forks source link

mlterm crashes #33

Open vovan69 opened 2 years ago

vovan69 commented 2 years ago

Hello,

I'm recently experiencing mlterm crashes quite often, but only when screensaver is active (I'm using cinnamon 5.0). I haven't been able to get any info form logs regarding this crash, besides this message:

X Error of failed request: BadMatch (Invalid parameter attributes)
Major opcode of failed request: 73 (X_GetImage)
Serial number of failed request: 385790
Current serial number in the output stream: 385790

Affected mlterm version 3.9.1 and 3.9.2. I'd appreciate any thoughts about this issue.

Thank you in advance, Vlad.

arakiken commented 2 years ago

Thanks. Will you show me your ~/.mlterm/main ?

vovan69 commented 2 years ago

Thanks. Will you show me your ~/.mlterm/main ?


fg_color = #dcdcdc
bg_color = #333333
use_transbg = true
wall_picture =
depth = 32
logsize = 512
scrollbar_mode = none
use_clipboard = true
use_variable_column_width = true
termtype = xterm-256color
icon_path = /home/xxx/graphics/utilities-terminal.png
input_method = none
col_size_of_width_a = 1
use_dynamic_comb = false
receive_string_via_ucs = true
use_multi_column_char = true
use_bidi = false
mod_meta_mode = esc
use_combining = true
geometry=177x99-66+0
use_ansi_colors = true
only_use_unicode_font = true
regard_uri_as_word = true
baseline_offset = -1

fontsize = 14 type_engine = xft font_size_range = 10-100 step_in_changing_font_size = 1

arakiken commented 2 years ago

I tried to reproduce it on cinnamon 5.2.7 on arch linux, but I couldn't. I'll test it for a while.

Does mlterm crash even if you remove "use_transbg = true" ?

vovan69 commented 2 years ago

Does mlterm crash even if you remove "use_transbg = true" ?

I'll test and let you know.

vovan69 commented 2 years ago

Does mlterm crash even if you remove "use_transbg = true" ?

According to my tests mlterm doesn't crash with use_transbg = false.

vovan69 commented 2 years ago

One more observation: simply turning off monitor (unplugging power) triggers mlterm crash in my case.

arakiken commented 2 years ago

I haven't reproduced it yet, but I suspect that the following line causes this problem. https://github.com/arakiken/mlterm/blob/master/uitoolkit/xlib/ui_imagelib.c#L1603

Will you try to remove "depth=32" option from ~/.mlterm/main ?

vovan69 commented 2 years ago

Will you try to remove "depth=32" option from ~/.mlterm/main ?

I'll test and let you know.

vovan69 commented 2 years ago

Will you try to remove "depth=32" option from ~/.mlterm/main ?

I'll test and let you know.

vovan69 commented 2 years ago

No crashes so far without depth=32 option.

vovan69 commented 2 years ago

No crashes so far without depth=32 option.

Apparently mlterm crashes without depth=32 option as well, maybe less frequently.

arakiken commented 2 years ago

Thanks. Is the crash message (BadMatch error at X_GetImage) same either with or without depth=32 option ?

vovan69 commented 2 years ago

Thanks. Is the crash message (BadMatch error at X_GetImage) same either with or without depth=32 option ?

The error is different:

BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 14 (X_GetGeometry)
arakiken commented 2 years ago

Pixmap which mlterm gets by XGetWindowProperty() with _XROOTPMAP_ID atom might be invalid when screen saver of cinnamon is active, but I don't know why for now.

On the other hand, it could be caused by updating background image when screen saver is active and mlterm is unmapped . Will you test http://mlterm.sf.net/mlterm-3.9.2-fixtp.patch ?

vovan69 commented 2 years ago

Will you test http://mlterm.sf.net/mlterm-3.9.2-fixtp.patch ?

Still crashed with depth = 32. Should I test without this option as well?

arakiken commented 2 years ago

I'd like you to test without depth=32.

vovan69 commented 2 years ago

I'd like you to test without depth=32.

Crashed as well after a while

hramrach commented 1 year ago

IIRC error handling in Xlib is really problematic. The X requests are asynchronous for performance but then matching the error to a request is problematic. There should be an option to register an error callback that ignores the error but it's difficult to tell if the error is from something non-essential like the background image and can be ignored.