теперь по binkp.net и defnode вопросы

Eugene Erokhin написал(а) к Peter Khanin в Nov 16 16:34:52 по местному времени:

Как-то 12 Ноя 16 в 13:29 писал Peter Khanin письмо к Eugene Erokhin:

EE>> Теперь RESOLV_TTL не должен быть 0, вроде всё работает. Сделал pull
EE>> request на гитхабе.
PK> То-то я смотрю нода перестала звонить...
Это не я, это на binkp.net основная зона не тот адрес даёт :) Видать ip сменился, до девяти утра отдавала корректно.
У меня полёт нормальный уже 12 часов :)

wbr! Eugene.

--- GoldED+/W32-MINGW 1.1.5-b20051207

Peter Khanin написал(а) к Eugene Erokhin в Nov 16 18:19:30 по местному времени:


* Ответ на письмо из области carbonArea (Карбонка не пустая).

Здpавствуй, Eugene!

Суббота 12 Ноября 2016 16:34, ты писал(а) мне, в сообщении по ссылке area://carbonArea?msgid=2:5083/85+5826f0cf:

EE>>> Теперь RESOLV_TTL не должен быть 0, вроде всё работает. Сделал
EE>>> pull request на гитхабе.
PK>> То-то я смотрю нода перестала звонить...
EE> Это не я, это на binkp.net основная зона не тот адрес даёт :) Видать
EE> ip сменился, до девяти утра отдавала корректно. У меня полёт
EE> нормальный уже 12 часов :)

Я же все обновил, и эхотаг заодно.

Binkd 1.1a-94 из binkd@cvs.happy.kiev.ua:/cvs

И обломался. И пошел ходатайствовать сюда и тут увидел усю правду.

С уважением - Peter
--- GoldED-NSF/W32-MINGW 1.1.5-20090710

Eugene Erokhin написал(а) к Peter Khanin в Nov 16 17:53:42 по местному времени:

Как-то 12 Ноя 16 в 18:19 писал Peter Khanin письмо к Eugene Erokhin:

PK> Binkd 1.1a-94 из binkd@cvs.happy.kiev.ua:/cvs
PK> И обломался. И пошел ходатайствовать сюда и тут увидел усю правду.
1.1-a94 имеет под виндой свойство падать без предупреждения, при перечитывании конфига, если запущен с ключом -С. Не знаю, как у него с этим под линухом, но на всякий случай :) 1.0.4, 1.0.5-pre5 перечитывают нормально.

wbr! Eugene.

--- GoldED+/W32-MINGW 1.1.5-b20051207

Peter Khanin написал(а) к Eugene Erokhin в Nov 16 08:38:32 по местному времени:

Здpавствуй, Eugene!

Суббота 12 Ноября 2016 17:53, ты писал(а) мне, в сообщении по ссылке area://ru.binkd?msgid=2:5083/85+5827038a:

PK>> Binkd 1.1a-94 из binkd@cvs.happy.kiev.ua:/cvs
PK>> И обломался. И пошел ходатайствовать сюда и тут увидел усю
PK>> правду.
EE> 1.1-a94 имеет под виндой свойство падать без предупреждения, при
EE> перечитывании конфига, если запущен с ключом -С. Не знаю, как у него с
EE> этим под линухом, но на всякий случай :) 1.0.4, 1.0.5-pre5
EE> перечитывают нормально.

Под линуксой тоже падает, как выяснилось. С грохотом. segfault... aka signal 11.

С уважением - Peter
--- GoldED-NSF/W32-MINGW 1.1.5-20090710

Peter Khanin написал(а) к All в Nov 16 09:10:52 по местному времени:

Здpавствуй, All!

Воскресенье 13 Ноября 2016 08:38, я писал Eugene Erokhin, в сообщении по ссылке area://ru.binkd?msgid=2:5083/444.1+5827c456:

PK>>> Binkd 1.1a-94 из binkd@cvs.happy.kiev.ua:/cvs
PK>>> И обломался. И пошел ходатайствовать сюда и тут увидел усю
PK>>> правду.
EE>> 1.1-a94 имеет под виндой свойство падать без предупреждения, при
EE>> перечитывании конфига, если запущен с ключом -С. Не знаю, как у
EE>> него с этим под линухом, но на всякий случай :) 1.0.4, 1.0.5-pre5
EE>> перечитывают нормально.
PK> Под линуксой тоже падает, как выяснилось. С грохотом. segfault... aka
PK> signal 11.

Мастер как бы падает, но редко. А Binkd 1.0.5-pre5 с тем же болтом в defnode...

С уважением - Peter
--- GoldED-NSF/W32-MINGW 1.1.5-20090710

Eugene Erokhin написал(а) к Peter Khanin в Nov 16 10:28:54 по местному времени:

Как-то 13 Ноя 16 в 09:10 писал Peter Khanin письмо к All:

PK> Мастер как бы падает, но редко. А Binkd 1.0.5-pre5 с тем же болтом в
PK> defnode...
Болт в defnode в 1.0.x правится аккурат точно так же, как и в мастере. Там вроде разница в ftnnode.c косметическая между мастером и 1.0.5. Если я правильно понял, как гитхабом пользоваться :)

wbr! Eugene.

--- GoldED+/W32-MINGW 1.1.5-b20051207

Nil Alexandrov написал(а) к Peter Khanin в Nov 16 06:59:06 по местному времени:

Нello, Peter!

Sunday November 13 2016 09:10, from Peter Khanin -> All:

PK> Мастер как бы падает, но редко. А Binkd 1.0.5-pre5 с тем же болтом в
PK> defnode...

А я тут погонял binkd последний из cvs с Perl хуком для нодлиста,
под valgrind, много интересного. Много глюков связано с конфигом и его
перечитыванием. Ну ладно, что "деструктор" не вычищает всю аллоцируемую
память, это просто вопрос стиля чтоли.

Вот это уже более серьёздно.
Например, во free_nodes() освобождается xfree(node->pipe);
Но у меня в конфигах нет ни каких пайпов ни разу.

==21674== Invalid free() / delete / delete[] / realloc()
==21674== at 0x4C2BD57: free (vgreplacemalloc.c:530)
==21674== by 0x42AD62: xfree (xalloc.c:60)
==21674== by 0x42759C: free_nodes (ftnnode.c:409)
==21674== by 0x40950C: unlockconfigstructure (readcfg.c:262)
==21674== by 0x415AE7: clientmgr (client.c:258)
==21674== by 0x4261E4: branch (branch.c:87)
==21674== by 0x408F0B: main (binkd.c:721)
==21674== Address 0x6ccf110 is 0 bytes inside a block of size 1 free'd
==21674== at 0x4C2BD57: free (vgreplacemalloc.c:530)
==21674== by 0x42AD62: xfree (xalloc.c:60)
==21674== by 0x42759C: free_nodes (ftnnode.c:409)
==21674== by 0x40950C: unlockconfigstructure (readcfg.c:262)
==21674== by 0x415AE7: clientmgr (client.c:258)
==21674== by 0x4261E4: branch (branch.c:87)
==21674== by 0x408F0B: main (binkd.c:721)
==21674== Block was alloc'd at
==21674== at 0x4C2AC3D: malloc (vgreplacemalloc.c:299)
==21674== by 0x42ABEA: xalloc (xalloc.c:21)
==21674== by 0x42ACA5: xstrdup (xalloc.c:42)
==21674== by 0x426864: addnodenolock (ftnnode.c:139)
==21674== by 0x426B32: add_node (ftnnode.c:202)
==21674== by 0x40B72E: readnodeinfo (readcfg.c:1237)
==21674== by 0x40A16A: readcfg0 (readcfg.c:724)
==21674== by 0x40A256: readcfg (readcfg.c:747)
==21674== by 0x40A681: checkcfg (readcfg.c:890)
==21674== by 0x415B1E: clientmgr (client.c:274)
==21674== by 0x4261E4: branch (branch.c:87)
==21674== by 0x408F0B: main (binkd.c:721)

Или вот прикол ещё, при звонке на не стандартный порт (г-н Пушкин, хостит
/2140 на дефолтовом, а вот /2141 на 24555), в функцию srv_getaddrinfo()
передаётся поинтер на левую память в service, и там atoi() падает.

==8538== Invalid read of size 1
==8538== at 0x56365B4: ___strtol_l_internal (strtoll.c:438)
==8538== by 0x5632EAF: atoi (atoi.c:27)
==8538== by 0x44E44B: srvgetaddrinfo (srvgai.c:80)
==8538== by 0x417429: call0 (client.c:429)
==8538== by 0x417EC6: call (client.c:647)
==8538== by 0x427A36: branch (branch.c:87)
==8538== by 0x416A83: do_client (client.c:146)
==8538== by 0x416DED: clientmgr (client.c:265)
==8538== by 0x427A36: branch (branch.c:87)
==8538== by 0x409121: main (binkd.c:721)
==8538== Address 0x71cdc20 is 16 bytes inside a block of size 21 free'd
==8538== at 0x4C2BD57: free (vgreplacemalloc.c:530)
==8538== by 0x40BF80: gethost_andport (readcfg.c:1300)
==8538== by 0x417C53: call0 (client.c:392)
==8538== by 0x417EC6: call (client.c:647)
==8538== by 0x427A36: branch (branch.c:87)
==8538== by 0x416A83: do_client (client.c:146)
==8538== by 0x416DED: clientmgr (client.c:265)
==8538== by 0x427A36: branch (branch.c:87)
==8538== by 0x409121: main (binkd.c:721)
==8538== Block was alloc'd at
==8538== at 0x4C2AC3D: malloc (vgreplacemalloc.c:299)
==8538== by 0x42CB7B: xalloc (xalloc.c:21)
==8538== by 0x42CC82: xstrdup (xalloc.c:42)
==8538== by 0x42C593: getwordx2 (getw.c:22)
==8538== by 0x40BE47: gethost_andport (readcfg.c:1266)
==8538== by 0x417C53: call0 (client.c:392)
==8538== by 0x417EC6: call (client.c:647)
==8538== by 0x427A36: branch (branch.c:87)
==8538== by 0x416A83: do_client (client.c:146)
==8538== by 0x416DED: clientmgr (client.c:265)
==8538== by 0x427A36: branch (branch.c:87)
==8538== by 0x409121: main (binkd.c:721)

Волшебная функция gethost_andport(), получает для переменной s память внутри
getwordx2(src, ..), ну и в конце честно делает free (s), только вот возвращает
в port адрес на часть подстроки из s, вот тут *port = find_port(), и память уже
тут не валидная.

Я думал щас быстренько патчик выпущу на все тут найденные приколы (а их много),
но сдался, тут сложно понять идеалогию кто чем владеет, постоянно делается
strdup(), указатель потом освобождается где-то в совсем другом месте, или вовсе
не осбобождается (пофиг, главное не падает).
Ну и там srcpy(), strcat() без проверки на границы.

Я такой код починить не могу, проще написать на C++, чтобы стринги владели
памятью. Листы на STL'ные контейнеры если заменить, то весь бойлерплейт тоже
уйдёт. Если дропнуть совместимость с экзотикой, или сказать, что мы собираем
везде, где поддерживается C++11 (уже многое из 17го поддерживается
современными компиляторами), то уйдёт весь этот развесистый код.

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Eugene Erokhin написал(а) к Nil Alexandrov в Nov 16 16:05:54 по местному времени:

Как-то 13 Ноя 16 в 06:59 писал Nil Alexandrov письмо к Peter Khanin:

NA> Я такой код починить не могу, проще написать на C++, чтобы стринги
NA> владели памятью. Листы на STL'ные контейнеры если заменить, то весь
NA> бойлерплейт тоже уйдёт. Если дропнуть совместимость с экзотикой, или
NA> сказать, что мы собираем везде, где поддерживается C++11 (уже многое
NA> из 17го поддерживается современными компиляторами), то уйдёт весь этот
NA> развесистый код.
"Папа, а это ты сейчас с кем разговаривал?" :))))

Мне так кажется, что если переписывать на крестах, то переписать придётся примерно всё. И получится тоже хороший мылер, но другой :) Тоже как бы дело хорошее, но большое очень, далеко за багфиксы binkd выходящее.

Так что кесарю - кесарево, а я помедитирую на днях, наверное, на предмет выпадания при перечитывании конфига :)

wbr! Eugene.

--- GoldED+/W32-MINGW 1.1.5-b20051207

Roman Trunov написал(а) к Nil Alexandrov в Nov 16 12:55:30 по местному времени:

Нello Nil!

NA> Волшебная функция gethost_andport(), получает для переменной s память
NA> внутри getwordx2(src, ..), ну и в конце честно делает free (s), только вот
NA> возвращает в port адрес на часть подстроки из s, вот тут *port =
NA> find_port(), и память уже тут не валидная.

ПРЭЛЭЭСТНО! Теперь понятно, почему оно регулярно валится. Дело в том, что раньше в gethost_and_port было в параметрах unsigned short port, и port = find_port() возвращал число - номер порта, никто ни на кого не ссылался и все освобождалось где надо. Потом кто-то полез переделывать и get_host_andport за каким-то хреном стал возвращать порт в виде строки. Подозреваю, что это произошло или в момент вкорячивания пайпов, или ipv6.

Roman

--- GoldED+/W32 1.1.0

Vitaliy Aksyonov написал(а) к Roman Trunov в Nov 16 12:31:44 по местному времени:

Привет, Roman!

14 ноя 16 12:55, Roman Trunov -> Nil Alexandrov:

NA>> Волшебная функция gethost_andport(), получает для переменной s
NA>> память внутри getwordx2(src, ..), ну и в конце честно делает free
NA>> (s), только вот возвращает в port адрес на часть подстроки из s,
NA>> вот тут *port = find_port(), и память уже тут не валидная.

RT> ПРЭЛЭЭСТНО! Теперь понятно, почему оно регулярно валится. Дело в том,
RT> что раньше в gethost_andport было в параметрах unsigned short *port,
RT> и *port = find_port() возвращал число - номер порта, никто ни на кого
RT> не ссылался и все освобождалось где надо. Потом кто-то полез
RT> переделывать и gethost_andport за каким-то хреном стал возвращать
RT> порт в виде строки. Подозреваю, что это произошло или в момент
RT> вкорячивания пайпов, или ipv6.

Да уж... Бывают досадные ошибки... Патч пришлешь? :)

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

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