LINUX.ORG.RU
ФорумTalks

Krita убивает Gimp

 , , ,


0

3

- Запускаем Gimp (), с любым изображением (можно создать прямо в нём, но главное чтобы не пустое, можно ткнуть кисточкой, но если изображение маленькое или занимает мало места в памяти, то фокус не проходит, потому лучше юзать фоточку).

- Выделяем всё и копируем его. (Ctrl+A Ctrl+C)

- Запускаем krita

- гимп падает:

The program 'gimp' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 74916 error_code 3 request_code 18 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

(script-fu:9801): LibGimpBase-WARNING **: 00:14:04.751: script-fu: gimp_wire_read(): error

// --- //

% X -version

X.Org X Server 1.20.1
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-7-amd64 x86_64 Debian
Current Operating System: Linux ws 4.18.0-1-amd64 #1 SMP Debian 4.18.6-1 (2018-09-06) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.18.0-1-amd64 root=UUID=f7d1e933-4f44-43e1-b2bb-697426b1e141 ro clocksource=jiffies
Build Date: 17 August 2018  08:05:00PM
xorg-server 2:1.20.1-1 (https://www.debian.org/support)
Current version of pixman: 0.34.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
% uname -a
Linux ws 4.18.0-1-amd64 #1 SMP Debian 4.18.6-1 (2018-09-06) x86_64 GNU/Linux
% gimp --version
GNU Image Manipulation Program версии 2.10.6
% krita --version
krita 4.1.1

Внимание вопрос, когда перестанут писать нужные программы на этом убогоньком недоязычке?

Deleted

Последнее исправление: Deleted (всего исправлений: 1)

Ответ на: комментарий от meliafaro

Внимание вопрос, когда перестанут писать нужные программы на этом убогоньком недоязычке?

Что сказать хотел?

Ещё вопрос, когда перебанят всех, кто умеет только писать.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

Внимание вопрос, когда перестанут писать нужные программы на этом убогоньком недоязычке?

Каком «язычке»?

Если что, проблема в Xlib, а точнее в его идеологии «все ошибки — по умолчанию фатальные, вызываем abort()». Это можно отключить, но только для части ошибок. Часть всегда фатальная.

Привязки к другим языкам, скорее всего, тоже libX11.so используют. Не реализовывать же протокол руками. И проблемы они словят те же.

i-rinat ★★★★★
()

Ты про схему?

ЗЫ. Моё скрипт-фу круче твоего.

ya-betmen ★★★★★
()
Ответ на: комментарий от i-rinat

Если что, проблема в Xlib

Ну остальные то приложения не падают, значит это гимп что-то делает не так (хоть ошибка летит «изнутри» иксов).

Deleted
()
Ответ на: комментарий от Deleted

А это точно не связано со скриптами на питоне? script-fu матюгается непонятно чего

timdorohin ★★★★
()
Ответ на: комментарий от Deleted

Ты явно не пытался делать что-нибудь нетривиальное с Xlib. Там сложно сделать так.

У тебя, что-ли, менеджера буфера обмена нет в системе?

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Ты явно не пытался делать что-нибудь нетривиальное с Xlib. Там сложно сделать так.

Мне хватило поглазеть на документацию и всплакнуть о winapi.

У тебя, что-ли, менеджера буфера обмена нет в системе?

А он то тут причём?

Deleted
()
Ответ на: комментарий от nvidia

Есть, и libX11 даже использует в потрохах xcb. Но тулкиты почему-то используют libX11, а не xcb напрямую. По крайней мере, GTK+.

i-rinat ★★★★★
()
Ответ на: комментарий от Deleted

А он то тут причём?

Его отсутствие может достать из глубины приложения баг, который на системах с менеджером буфера обмена никогда не всплывает.

Но баг есть, да. Непонятно, правда, где именно.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Его отсутствие может достать из глубины приложения баг, который на системах с менеджером буфера обмена никогда не всплывает.

ну апплет есть, который изкоробки в кедах, но там включён «игнор изображений» (проверил - эта настройка никак не влияет на баг).

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от KennyMinigun

Забавно, а раньше (2006) Krita падала: https://bugs.launchpad.net/ubuntu/ source/koffice/ bug/69898

Орнул) Они же баг исправили получается. Krita не падает, теперь ждём ответку от Gimp :)

th3m3 ★★★★★
()
Ответ на: комментарий от i-rinat

Но баг есть, да. Непонятно, правда, где именно.

Навскидку, должон быть некий обработчик (это я по опыту работы с буфером обмена в других системах), который вызывается, когда клиент запрашивает содержимое буфера. Видимо, в зависимости от размера изображения, оно то ли запрашивается не целиком (может обрывает «поток» данных), то ли запрашивается каким-то особо упоротым образом (форматом) - гимп возможно деклариурет, что может отдавать картинку несколькими форматами. Где-то там зарыта собака.

Deleted
()
Ответ на: комментарий от Deleted

У тебя, похоже, какая-то скриптота в gimp'е пытается буфер опросить. Или это gimp без каких-либо дополнительных настроек?

i-rinat ★★★★★
()

Krita очень даже юзабельный редактор. Гимп уже можно потихоньку закапывать.

Valeg ★★★
()
Ответ на: комментарий от Deleted

в кедах

КДЕ проблемы

установи гном3 там такого нет(ничего не падает)

missxu
()

Попробовал, гимп не упал.

arch up to date

xfce4

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 1)

Внимание вопрос, когда перестанут писать нужные программы на этом убогоньком недоязычке?

Правильный вопрос: когда уже из Linux'а нахрен выкинут иксы? Они, блджд, сегфолтятся на ровном месте.

EXL ★★★★★
()

а причём здесь язык?

mittorn ★★★★★
()
Ответ на: ЛОЛ! от EXL

но ведь плазма не падает...

mittorn ★★★★★
()
Ответ на: комментарий от EXL

в вяленном разве не больше возможных источников сегфолтов?

mittorn ★★★★★
()

Я видел такое при копировании изображения из firefox и tor browser на убунту с гномом. Пологаю, что баг все-таки в krita.

Khnazile ★★★★★
()

Язык тут не при чём.

Deleted
()

А ты уверен, что проблема непосредственно в крите? И у меня не воспроизводится на распоследних версиях софта

Deleted
()
Ответ на: ЛОЛ! от EXL

Как ты это делаешь вообще? Я поражаюсь твоим способностям :)

А вообще единственный способ уронить плазму, что я знаю - в классическом стартовом меню наводишь, например, на Игры-Аркады, туда мышкой переходишь, а потом резко перепрыгиваю на (например) на Графика и... Всё исчезает и перезапускается. Но окна-то о крэше не выдаёт. Где ты их берёшь?

Deleted
()
Ответ на: комментарий от i-rinat
$ ldd /usr/lib64/libQt5Widgets.so.5 | grep X11
        libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007ffff313b000)
        libX11.so.6 => /lib64/libX11.so.6 (0x00007ffff2dfe000)
$ ldd /usr/lib64/libQt5Widgets.so.5 | grep xcb
        libxcb-dri3.so.0 => /lib64/libxcb-dri3.so.0 (0x00007ffff4196000)
        libxcb-present.so.0 => /lib64/libxcb-present.so.0 (0x00007ffff3f93000)
        libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007ffff3d8c000)
        libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007ffff313b000)
        libxcb.so.1 => /lib64/libxcb.so.1 (0x00007ffff2bd8000)
        libxcb-glx.so.0 => /lib64/libxcb-glx.so.0 (0x00007ffff29bf000)
        libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x00007ffff27ba000)
$ ldd /usr/lib64/libgtk-3.so | grep xcb
        libxcb.so.1 => /lib64/libxcb.so.1 (0x00007ffff2239000)
        libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007ffff18fb000)
        libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007ffff16ee000)
        libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x00007fffef30f000)
        libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007fffef10d000)
        libxcb-dri3.so.0 => /lib64/libxcb-dri3.so.0 (0x00007fffeef0a000)
        libxcb-xfixes.so.0 => /lib64/libxcb-xfixes.so.0 (0x00007fffeed02000)
        libxcb-present.so.0 => /lib64/libxcb-present.so.0 (0x00007fffeeaff000)
        libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007fffee8f8000)
        libxcb-glx.so.0 => /lib64/libxcb-glx.so.0 (0x00007fffeda4d000)
$ ldd /usr/lib64/libgtk-x11-2.0.so | grep xcb
        libxcb.so.1 => /lib64/libxcb.so.1 (0x00007ffff36ae000)
        libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007ffff2b6c000)
        libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007ffff295f000)
        libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x00007ffff0a02000)
        libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007ffff0800000)
        libxcb-dri3.so.0 => /lib64/libxcb-dri3.so.0 (0x00007ffff05fd000)
        libxcb-xfixes.so.0 => /lib64/libxcb-xfixes.so.0 (0x00007ffff03f5000)
        libxcb-present.so.0 => /lib64/libxcb-present.so.0 (0x00007ffff01f2000)
        libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007fffeffeb000)
        libxcb-glx.so.0 => /lib64/libxcb-glx.so.0 (0x00007fffeef31000)
saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 2)

А если запустить гимп с параметром --sync как предлагает выхлоп? Скорее всего гимп не ожидает что (думаю иксовый) буфер обмена будет сообщать отправителю о процессе вставки содержимого в другую программу. Хотя возможно именно крита шлет неправильную маляву, от которой гимп и падает. Короче, багрепостить стоит и в гимп, и в кде и в иксорг.

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от DNA_Seq

Это выхлоп с этим самым параметром.

Deleted
()
Ответ на: комментарий от Deleted

Мне хватило поглазеть на документацию и всплакнуть о winapi.

HWND APIENTRY DLGPROC! LRESULT CALLBACK! GetSomeLongShitNameEx(LPSOMESHITSTRUCTEX *lpShitStruct, LPTSTR *lpShitName)!

Harald ★★★★★
()
Ответ на: комментарий от Deleted

О, я воспроизвёл. Сначала думал, что 8000x8000 — достаточно большая картинка. Оказалось, нужно было больше.

Ошибка происходит вот тут:

(gdb) bt
#0  0x00007ffff7a4c050 in gdk_x_error (display=0x555555d70700, error=0x7fffffffda80) at ./gdk/x11/gdkmain-x11.c:458
#1  0x00007ffff641b0fa in _XError () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#2  0x00007ffff6418067 in  () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#3  0x00007ffff641810d in  () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x00007ffff6419030 in _XReply () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007ffff641498d in XSync () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007ffff6414a2b in  () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007ffff63f56c3 in XChangeProperty ()
    at /usr/lib/x86_64-linux-gnu/libX11.so.6
#8  0x00007ffff7a4e502 in IA__gdk_property_change (window=0x55555a57bea0, property=0xbe, type=0x88, format=8, mode=GDK_PROP_MODE_REPLACE, data=0x5555dafc6680 "\377\330\377", <incomplete sequence \340>, nelements=262144)
    at ./gdk/x11/gdkproperty-x11.c:732
#9  0x00007ffff7c37f48 in _gtk_selection_incr_event (window=<optimized out>, event=event@entry=0x55555a2918f0) at ./gtk/gtkselection.c:2593
#10 0x00007ffff7bd1944 in IA__gtk_main_do_event (event=0x55555a2918f0)
    at ./gtk/gtkmain.c:1540
#11 0x00007ffff7a44bac in gdk_event_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ./gdk/x11/gdkevents-x11.c:2425
#12 0x00007ffff68ddc3e in g_main_context_dispatch ()
    at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff68dded8 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0

INCR — это протокол передачи информации о выделении по кусочкам, когда целиком она слишком большая. _gtk_selection_incr_event вызывается, когда принимающая сторона уведомляет, что получила кусочек. Приложение-владелец данных подписывается на события на окне получателя. Видимо, в какой-то момент получатель закрывает окно. Затем владелец (gtk в gimp'е) пытается поменять свойство на окне получателя, а окна нет. BadWindow.

Это баг в GTK+. Который вряд ли кто-то будет фиксить, так как GTK+ 2 уже закопали.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Видимо, в какой-то момент получатель закрывает окно. Затем владелец (gtk в gimp'е) пытается поменять свойство на окне получателя, а окна нет. BadWindow.

Не может оказаться так что гимп игнориурет событие закрытия окна (ну потому что это не «ожидается») ?

Deleted
()
Ответ на: комментарий от Deleted

Скорее всего, так и происходит.

Думал, что смогу пофиксить. Но похоже, нет. Надо вникать, как вообще это работает в деталях. Лень.

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от Deleted

Ой, я тоже взял картинку побольше и теперь тоже воспроизводится. При чём даже если просто сделать Ctrl+C или если выбрать достаточно большую область и скопировать И если скопировать и вставить. А вот если выбрать маленькую область и скопировать, то не падает. Да. Ужас.

Deleted
()
Ответ на: комментарий от i-rinat

Если что, проблема в Xlib, а точнее в его идеологии «все ошибки — по умолчанию фатальные, вызываем abort()».

И это в языке без механизма проброса ошибок. Совпадение? Не думаю.

RazrFalcon ★★★★★
()
Ответ на: комментарий от AP

Завёл. Т.к. мой инглиш скилл весьма посредственный, то не возражаю, если кто причешет репорт в более приемлемый вид, если требуется.

SkyMaverick ★★★★★
()
Последнее исправление: SkyMaverick (всего исправлений: 1)
Ответ на: комментарий от SkyMaverick

С заголовком тоже плохо, но пока не опредилился как кратко и хорошо описать, а вот текст я бы написал так -

GIMP version: all

Operating System: Linux all

Package: all

GIMP crashes when copying a large chunk (or everything) and then launching Krita

Reproduction

Always when copying a large enough chunk

Reproduction steps:

    Create or open large-sized (10000px x 10000px in my case) image in GIMP
    Press Ctrl+A and Ctrl+C (or select LARGE area and then Ctrl+C)
    Launch Krita app.
    GIMP crashes while launching the main window of Krita app

Expected result: coping GIMP image into clipboard and paste in Krita

Actual result: GIMP crash on Krita startup

ммм... chunk или area?

Deleted
()
Последнее исправление: Chelobaka (всего исправлений: 3)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.