Changes in golded+ sources

golded+ inspector написал(а) к All в Dec 16 01:20:10 по местному времени:


Updated file: srcdate.h in current branch
revision: 1.57; date: 2016-12-21 08:45:14+00; committed by vasilyevmax; lines: +1 -1
Log message:
update sources date constant to 20161221
============

Updated file: goldlib/gall/gusrgold.h in current branch
revision: 1.3; date: 2016-12-21 08:45:09+00; committed by vasilyevmax; lines: +4 -4
Log message:
Нudson message base bugfix for x64 platforms by Wilfred van Velzen, 2:280/464
============

Updated file: goldlib/gall/gusrhuds.h in current branch
revision: 1.3; date: 2016-12-21 08:45:09+00; committed by vasilyevmax; lines: +4 -4
Log message:
Нudson message base bugfix for x64 platforms by Wilfred van Velzen, 2:280/464
============

Updated file: goldlib/gall/gusrpcb.h in current branch
revision: 1.3; date: 2016-12-21 08:45:09+00; committed by vasilyevmax; lines: +5 -5
Log message:
Нudson message base bugfix for x64 platforms by Wilfred van Velzen, 2:280/464
============

Updated file: goldlib/gall/gusrra2.h in current branch
revision: 1.4; date: 2016-12-21 08:45:09+00; committed by vasilyevmax; lines: +12 -12
Log message:
Нudson message base bugfix for x64 platforms by Wilfred van Velzen, 2:280/464
============
--- hpt/lnx 1.4.0

golded+ inspector написал(а) к All в Mar 17 01:20:06 по местному времени:


Updated file: srcdate.h in current branch
revision: 1.58; date: 2017-03-03 07:16:57+00; committed by grsf; lines: +1 -1
Log message:
update sources date constant to 20170303
============

Updated file: cfgs/charset/866_koi.chs in current branch
revision: 1.5; date: 2017-03-03 07:16:52+00; committed by grsf; lines: +2 -2
Log message:
Force replacement of non-breaking spaces with hard spaces
============

Updated file: cfgs/charset/koi_866.chs in current branch
revision: 1.4; date: 2017-03-03 07:16:52+00; committed by grsf; lines: +2 -2
Log message:
Force replacement of non-breaking spaces with hard spaces
============
--- hpt/lnx 1.4.0

Semen Panevin написал(а) к All в Apr 17 14:10:54 по местному времени:

Доброго здоровьица тебе, All!

В продолжение темы...

Добрался наконец-то до gdb

Падает вот так:

--------------------------
(gdb) bt
#0 0xb7fdac60 in _kernelvsyscall ()
#1 0xb7afc34b in raise () from /lib/libc.so.6
#2 0xb7afd971 in abort () from /lib/libc.so.6
#3 0xb7b38707 in ?? () from /lib/libc.so.6
#4 0xb7b3eabf in ?? () from /lib/libc.so.6
#5 0xb7b3f282 in ?? () from /lib/libc.so.6
#6 0xb7d825a1 in operator delete(void*) () from /usr/lib/gcc/i686-pc-linux-gnu/5.4.0/libstdc++.so.6
#7 0xb7d82691 in operator delete[](void*) () from /usr/lib/gcc/i686-pc-linux-gnu/5.4.0/libstdc++.so.6
#8 0x8015309f in CSpellLang::RecodeText (this=0x809a21a0, srcText=0xbfffdcfc "фыважо", dstText=...,
flag=true) at gespell.cpp:722
#9 0x80153426 in CSpellChecker::Check (this=0xbfffe380, text=0xbfffdcfc "фыважо") at gespell.cpp:908
#10 0x8009d336 in IEclass::dispstringsc (this=0xbfffe2b4,
_buf=0xbfffde5c "причё fasidjf;;asjf;sfj fdsa фыважо", ' ' <repeats 72 times>, __beg=0, _end=107,
_row=2, _col=0, endchar=0 '\000') at geedit.cpp:287
#11 0x8009e3ff in IEclass::dispstring (this=0xbfffe2b4, line=0x809a2778, row=2) at geedit.cpp:443
#12 0x8009e55d in IEclass::displine (this=0xbfffe2b4, _line=0x809a2778, _row=2) at geedit.cpp:608
#13 0x800a2216 in IEclass::wrapit (this=0xbfffe2b4, _currline=0xbfffe348, __currcol=0xbfffe320,
_curr_row=0xbfffe324, _display=true) at geedit.cpp:1141
#14 0x800a24de in IEclass::wrapins (this=0xbfffe2b4, _currline=0xbfffe348, __currcol=0xbfffe320,
_curr_row=0xbfffe324, _display=true) at geedit.cpp:1207
#15 0x800a2d75 in IEclass::insertchar (this=0xbfffe2b4, ch=207 'о') at geedit.cpp:1255
#16 0x800a5e41 in IEclass::Start (this=0xbfffe2b4, _mode=256, __position=0xbfffe540, _msg=0x802c8404)
at geedit.cpp:3025
#17 0x8009c52e in EditMsg (_mode=256, __position=0xbfffe540, _msg=0x802c8404) at geedit2.cpp:1998
#18 0x800d2fec in MakeMsg2 (cmpmsg=<optimized out>, oldmsg=<optimized out>, msg=<optimized out>,
topline=<synthetic pointer>, forwstat=<synthetic pointer>, status=<synthetic pointer>,
mode=<synthetic pointer>) at gepost.cpp:593
#19 MakeMsg (mode=<optimized out>, omsg=0x802c414c, ignore_replyto=false) at gepost.cpp:1137
#20 0x800ee07f in NewMsg () at getpls.cpp:1050
#21 0x800e2d4f in Reader () at geread.cpp:847
#22 0x8005129e in main (argc=1, argv=0xbffff394) at gemain.cpp:53
---------------------------

Идеи? Кто с цпп дружит, может глянете одним глазком в код?

Вроде бы по трейсу понятно что падает именно голдед а не hunspell.

722 строка файла gespell.cpp выглядит как
delete[] dstbuffer;

Ниже цитата с чего всё началось.

Tuesday September 06 2016 08:32, Semen Panevin писал Semen Panevin:

SP> Доброго здоровьица тебе, Semen!

SP> Monday September 05 2016 22:59, Semen Panevin писал golded+
SP> inspector:

SP>> Sorry for English language.

SP>> Re-compiled with new sources right after the change. It worked
SP>> well until today, when I tried to answer in R50.SYSOP.DRUNKS, it
SP>> stopped with some error and broke my terminal (I'm not sure that
SP>> I tried to write messages between these events) right after the
SP>> internal editor were loaded.

SP>> I tried to write here the error and it started the editor well,
SP>> but when I tried to enter a few Russian characters it stopped
SP>> again with the same or very similar error.

SP>> I'm surprised that I can write English with no errors.

SP>> Please somebody, help me to understand the problem and fix it.

SP> В выводе после падения вот такая галиматья

SP> =============================
SP> 7745000-b7746000 ---p 00051000 08:03 26804702 /lib/libncurses.so.5.9

SP> b7746000- b7748000 r--p 00051000 08:03 26804702
SP> /lib/libncurses.so.5.9

SP> b7748000-b7749000 rw-p 00053000 08:03 26804702
SP> /lib/libncurses.so.5.9
SP> b7749000-b77a1000
SP> r-xp 00000000 08:03 26608268 /usr/lib/libhunspell-1.3.so.0.0.0

SP> b77a1000-b77a2000 r--p 00057000 08:03 26608268
SP> /usr/lib/libhunspell-1.3.so.0.0.0

SP> b77a2000-b77a6000 rw-p 00058000 08:03 26608268
SP> /usr/lib/libhunspell-1.3.so.0.0.0

SP> b77b2000-b77b3000 rw-p 00000000 00:00 0
SP> b77b3000-b77b5000 r--p 00000000 00:00 0
SP> [vvar]

SP> b77b50 00-b77b6000 r-xp 00000000 00:00 0 [vdso]
SP> b77b6000-b77d7000 r-xp
SP> 00000000 08:03 42560235 /lib/ld-2.22.so
SP> b77d7000-b77d8000 rw-p 00000000 00:00
SP> 0

SP> b77d800 0-b77d9000 r--p 00021000 08:03 42560235 /lib/ld-2.22.so

SP> b77d9000-b77da000 rw-p 00022000 08:03 42560235 /lib/ld-2.22.so
SP> bff6f000-bffa4000 rw-p
SP> 00000000 00:00 0 [stack]
SP> /home/fido/bin/golded: line 4: 9825 Аварийный останов
SP> =============================

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

SP> Как можно заметить по этому письму, с отключенным спеллчекером всё
SP> работает.

SP> С наилучшими пожеланиями, Семён.

SP> ... От правды далеко не убежишь (с) Sage

С наилучшими пожеланиями, Семён.

... В гостях хорошо, а дома хуже...
--- GoldED+/LNX 1.1.5-b20170303 (Linux 4.1.12-gentoo iF6M10)

Semen Panevin написал(а) к All в Apr 17 01:22:38 по местному времени:

Доброго здоровьица тебе, All!

Saturday April 22 2017 14:10, Semen Panevin послал All:

SP> Падает вот так:

SP> --------------------------
SP> (gdb) bt
SP> #0 0xb7fdac60 in _kernelvsyscall ()
SP> #1 0xb7afc34b in raise () from /lib/libc.so.6
SP> #2 0xb7afd971 in abort () from /lib/libc.so.6
SP> #3 0xb7b38707 in ?? () from /lib/libc.so.6
SP> #4 0xb7b3eabf in ?? () from /lib/libc.so.6
SP> #5 0xb7b3f282 in ?? () from /lib/libc.so.6
SP> #6 0xb7d825a1 in operator delete(void*) () from
SP> /usr/lib/gcc/i686-pc-linux-gnu/5.4.0/libstdc++.so.6 #7 0xb7d82691 in
SP> operator delete[](void*) () from
SP> /usr/lib/gcc/i686-pc-linux-gnu/5.4.0/libstdc++.so.6 #8 0x8015309f in
SP> CSpellLang::RecodeText (this=0x809a21a0, srcText=0xbfffdcfc "фыважо",
SP> dstText=...,
SP> flag=true) at gespell.cpp:722
Перечитал всё что можно про delete и delete[], поставил несколько следственных экспериментов в рамках остаточных сиплюсплюсных познаний, и даже попытался осилить XlatStr(...). На первый взгляд косяков не обнаружено. Но падает...

Падает точно после XlatStr. Если её закомментить - то не падает.

И ведь раньше не падало тоже... неужели что-то в libstcc++ или даже libc сломали? Но линковка емнип была динамической (впрочем тут я могу и ошибаться) поэтому упало бы сразу после апдейта а не после пересборки только деда...

С наилучшими пожеланиями, Семён.

... Человек может все, пока не начнет что-то делать... (c)...
--- GoldED+/LNX 1.1.5-b20170303 (Linux 4.1.12-gentoo iF6M10)

Michael Dukelsky написал(а) к Semen Panevin в Apr 17 19:10:42 по местному времени:

Привет, Semen!

23 Apr 17 01:22, Semen Panevin послал(а) письмо к All:

SP> Перечитал всё что можно про delete и delete[], поставил несколько
SP> следственных экспериментов в рамках остаточных сиплюсплюсных познаний,
SP> и даже попытался осилить XlatStr(...). На первый взгляд косяков не
SP> обнаружено. Но падает...

SP> Падает точно после XlatStr. Если её закомментить - то не падает.

Копаться в этом коде лень. Скорее всего эта функция пишет в массив, не проверяя нарушения границ массива, и радостно перезаписывает то место, где хранится указатель на массив. После чего попытка освобождения выделенной памяти приводит к краху.

Желаю успехов, Semen!
За сим откланиваюсь, Michael.

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20151128

Semen Panevin написал(а) к Michael Dukelsky в Apr 17 20:52:00 по местному времени:

Доброго здоровьица тебе, Michael!

Sunday April 23 2017 19:10, Michael Dukelsky писал Semen Panevin:

SP>> Перечитал всё что можно про delete и delete[], поставил несколько
SP>> следственных экспериментов в рамках остаточных сиплюсплюсных
SP>> познаний, и даже попытался осилить XlatStr(...). На первый взгляд
SP>> косяков не обнаружено. Но падает...

SP>> Падает точно после XlatStr. Если её закомментить - то не падает.

MD> Копаться в этом коде лень.
Т.е. всё? можно попрощаться со спелчекером? Или есть шанс, что найдётся кто-то кому не лень?

MD> Скорее всего эта функция пишет в массив, не
MD> проверяя нарушения границ массива, и радостно перезаписывает то место,
MD> где хранится указатель на массив. После чего попытка освобождения
MD> выделенной памяти приводит к краху.

Под dest выделяется памяти src len + 1. Я пробовал увеличить в 2 раза, не помогло.

Смущает то, что эта функция не является частью кода спелчекера, и используется ещё в куче мест. Но больше нигде почему-то не падает, и в этом месте тоже раньше почему-то не падало...

Правда в других местах может не быть new/delete поэтому грабли могут вылезти крайне случайно и неочевидно...

С наилучшими пожеланиями, Семён.

... Без крыльев далеко не улетишь
--- GoldED+/LNX 1.1.5-b20170303 (Linux 4.1.12-gentoo iF6M10)

Michael Dukelsky написал(а) к Semen Panevin в Apr 17 10:04:02 по местному времени:

Привет, Semen!

23 Apr 17 20:52, Semen Panevin послал(а) письмо к Michael Dukelsky:

SP>>> Перечитал всё что можно про delete и delete[], поставил
SP>>> несколько следственных экспериментов в рамках остаточных
SP>>> сиплюсплюсных познаний, и даже попытался осилить XlatStr(...).
SP>>> На первый взгляд косяков не обнаружено. Но падает...

SP>>> Падает точно после XlatStr. Если её закомментить - то не падает.

MD>> Копаться в этом коде лень.
SP> Т.е. всё? можно попрощаться со спелчекером?

Ну почему же? У меня даже нет права корректировать исходники голдеда на сервере. Так что на меня не надо ориентироваться. Я просто подсказал тебе возможную причину падения.

SP> Или есть шанс, что найдётся кто-то кому не лень?

Шанс есть всегда. :)

MD>> Скорее всего эта функция пишет в массив, не
MD>> проверяя нарушения границ массива, и радостно перезаписывает то
MD>> место, где хранится указатель на массив. После чего попытка
MD>> освобождения выделенной памяти приводит к краху.

SP> Под dest выделяется памяти src len + 1. Я пробовал увеличить в 2 раза,
SP> не помогло.

Не надо гадать. Надо проверить, что функция XlatStr действительно портит значение указателя на выделенную память. Если портит, то нужно разобраться из-за чего это происходит, из-за того, что она получает неверные данные, которые она не должна была получить, или из-за ошибки в самой функции. В первом случае неверные данные могут быть такими, что функция пишет по адресам, меньшим чем начало выделенного массива памяти. Поэтому сколько памяти не выделяй, это не поможет. В обоих случаях надо добавить проверку входных данных функции, чтобы она не могла писать за границы выделенного массива. Ну и в случае неверных данных надо разбираться, откуда эти неверные данные взялись.

Желаю успехов, Semen!
За сим откланиваюсь, Michael.

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20151128

Semen Panevin написал(а) к Michael Dukelsky в Apr 17 21:41:54 по местному времени:

Доброго здоровьица тебе, Michael!

Monday April 24 2017 10:04, Michael Dukelsky писал Semen Panevin:

SP>>>> Падает точно после XlatStr. Если её закомментить - то не
SP>>>> падает.

MD>>> Копаться в этом коде лень.
SP>> Т.е. всё? можно попрощаться со спелчекером?

MD> Ну почему же? У меня даже нет права корректировать исходники голдеда
MD> на сервере. Так что на меня не надо ориентироваться. Я просто
MD> подсказал тебе возможную причину падения.
Да это я и так понимаю. Но беглый пробег по содержимому XlatStr не выявил явных косяков. А если учесть, что я уже почти 10 лет как кодю только на C# - то станет понятно, что сиплюсплюсные типы данных, ссылки, указатели и проч. - это для меня уже тёмный лес, даже если я раньше в них худо-бедно ориентировался...

SP>> Или есть шанс, что найдётся кто-то кому не лень?
MD> Шанс есть всегда. :)
Буду ждать и верить...

MD> Не надо гадать. Надо проверить, что функция XlatStr действительно
MD> портит значение указателя на выделенную память.
Это не так просто. Особенно учитывая как ncurses раскорячивает терминал, отлаживаться там с помощью непривычного gdb - это адъ. Если б оно каждый раз падало - было бы проще. Так нет же, падает не на первой букве, и даже не всегда на первом слове...

Там ещё оптимизатор буфер оптимизирует, поэтому его значение в гдб не так просто выцепить.

С наилучшими пожеланиями, Семён.

... Если человек родился, то это уж на всю жизнь... (c)...
--- GoldED+/LNX 1.1.5-b20170303 (Linux 4.1.12-gentoo iF6M10)

Semen Panevin написал(а) к Michael Dukelsky в Apr 17 08:04:04 по местному времени:

Доброго здоровьица тебе, Michael!

Monday April 24 2017 10:04, Michael Dukelsky писал Semen Panevin:

MD>>> Скорее всего эта функция пишет в массив, не
MD>>> проверяя нарушения границ массива, и радостно перезаписывает то
MD>>> место, где хранится указатель на массив. После чего попытка
MD>>> освобождения выделенной памяти приводит к краху.

SP>> Под dest выделяется памяти src len + 1. Я пробовал увеличить в 2
SP>> раза, не помогло.

MD> Не надо гадать. Надо проверить, что функция XlatStr действительно
MD> портит значение указателя на выделенную память.
Увеличение буфера в ТРИ раза помогло. Значит точно портит, и точно в конце. Функция здоровая с кучей непонятной мне логики, самому разобраться в ней я ниасилю. Посему вопрос: коммитить воркароунд с увеличением буфера?

MD> Если портит, то нужно
MD> разобраться из-за чего это происходит, из-за того, что она получает
MD> неверные данные, которые она не должна была получить, или из-за ошибки
MD> в самой функции. В первом случае неверные данные могут быть такими,
MD> что функция пишет по адресам, меньшим чем начало выделенного массива
MD> памяти. Поэтому сколько памяти не выделяй, это не поможет.
Путём следственных экспериментов выяснено, что портится именно в конце. Иначе увеличение не помогло бы.

MD> В обоих
MD> случаях надо добавить проверку входных данных функции, чтобы она не
MD> могла писать за границы выделенного массива.
Ниасилю. Я все эти указатели позабывал уже.

С наилучшими пожеланиями, Семён.

... Хорошо там, где мы есть! (про фидошников)
--- GoldED+/LNX 1.1.5-b20170303 (Linux 4.1.12-gentoo iF6M10)

Vitaliy Aksyonov написал(а) к Semen Panevin в Apr 17 20:48:46 по местному времени:

Привет, Semen!

29 апр 17 08:04, Semen Panevin -> Michael Dukelsky:

MD>> Не надо гадать. Надо проверить, что функция XlatStr действительно
MD>> портит значение указателя на выделенную память.
SP> Увеличение буфера в ТРИ раза помогло. Значит точно портит, и точно в
SP> конце. Функция здоровая с кучей непонятной мне логики, самому
SP> разобраться в ней я ниасилю. Посему вопрос: коммитить воркароунд с
SP> увеличением буфера?

Я могу глянуть. Постараюсь найти причину. Костыль, который вроде работает, но непонятно почему, тоже ничего хорошего.

С наилучшими пожеланиями, Vitaliy.

... 10.0 times 0.10 is hardly ever 1.00.
--- GoldED+/LNX 1.1.5-b20160201