{$IfDef Kylix}
libc;
опять на давно умершем Кайликсе ?
:) Это директива осталась. Сейчас библиотека откомпилирована под FP 2.4.4.
Повторюсь, откомпилированная библиотека на давно умершем Кайликсе, работает
и не жужжит на всех версиях птички вплоть до 2.1.3 включительно. Начиная с
2.1.4 и
В письме от Fri, 14 Oct 2011 10:19:19 +0400, Vsevolod
iuaa...@gmail.com сообщал:
{$IfDef Kylix}
libc;
опять на давно умершем Кайликсе ?
:) Это директива осталась.
и она как минимум подключает libc, который возможно не нужен, а возможно
ещё и переключает что-то в самом FPC или других
Если падает, можно прислать бекап метаданных и удф мне.
Спасибо. Попробую воспроизвести тестовый пример и выслать. Хотя надеюсь
апдейт ядра и glibc поможет.
После вчераших изысков получил следующие результаты :
1. segmentation fault скорее всего появлялась из-за того, что библиотека
Vsevolod iuaa...@gmail.com
сообщил/сообщила в новостях следующее:
news:1318487736538-3900707.p...@n4.nabble.com...
Если можно подскажи приз где я не прав и что не так делаю.
Не знаю к кому ты стучишся. Если конкретно к Владу то извини.
Вот мои потуги в написании библиотек на ФрееПаскале.
Храпко Виктор пишет:
Я в лазарусе компилил. Еще и для 64 разрядного OpenSuse 11.2
А версия лазаруса какая?
Как-то пытался перекомпилировать UDF для FB под 64битный RedHat,
но старая версия лазаруса не позволяла.
---
Игорь
В письме от Thu, 13 Oct 2011 10:35:36 +0400, Vsevolod
iuaa...@gmail.com сообщал:
3. Переписал все вызовы malloc на ib_util_malloc. Теперь функции
вызываются, возвращают правильные результаты, но теперь клиент виснет при
дисконнекте от БД. Завис IBE, также завис процесс gbak после того как
1) а у тебя не используется что-то с авто-созданием строк ? какой-нибудь
StrNew, который автоматически вызовет собственный heap manager, а не
ib-шный ?
в Delphi заменить стандартный менеджер на ib_malloc понятно как, есть ли
аналогичный хуки в FPC не знаю.
Там гораздо все интересней.
В письме от Thu, 13 Oct 2011 23:50:56 +0400, Cherevatenko Vsevolod
iuaa...@gmail.com сообщал:
и все
равно виснет и клиент и серверный процесс, собака :(
виснет при выгрузке, так ?
может быть если просмоьтреть в ldd удфку и сервер - увидим, что они гурзят
разные версиии одной и той же
Для начала попробуй рестор только метаданных.
Я вчера во-первых нашел check constrain, который пользовался udf, убил
его. После этого segmentation fault стал появляться перед finishing,
closing, and going home
Только после того как заремарил ВСЕ вызовы удф база отресторилась без
Только после того как заремарил ВСЕ вызовы удф база отресторилась без
ошибок. Как то подозрительно, что вдруг все функции стали кривые.
Сама удф написана на паскале.
Посмотри на всякий случай initialization секции и тому подобные
автоматически вызываемые при загрузке udf места.
Что-то похоже
Добрый день, всем.
Некоторое время назад пытались переползти на версию птички 2.1.4 с 2.1.3.
Получили ошибку при ресторе БД и на время отказались. Но со вчерашнего дня
опять вернулись к этому вопросу из-за постоянной ошибки
http://tracker.firebirdsql.org/browse/CORE-2936, которая якобы
Vsevolod ...
Добрый день, всем.
Некоторое время назад пытались переползти на версию птички 2.1.4 с 2.1.3.
Получили ошибку при ресторе БД и на время отказались. Но со вчерашнего дня
опять вернулись к этому вопросу из-за постоянной ошибки
http://tracker.firebirdsql.org/browse/CORE-2936, которая
Что значит - якобы ?
Потому что проверить сам не могу пока :)
Ну так пиши отдельный пост. Или два. Скока надо - пиши :)
Ок :)
Ну так что тут не понятно ? Кривая UDF, скорее всего. И используется
в expression index'е. В 2.1.3 везло, баг не обнаруживался (хотя частое
появление
Vsevolod ...
Ну так что тут не понятно ? Кривая UDF, скорее всего. И используется
в expression index'е. В 2.1.3 везло, баг не обнаруживался (хотя частое
появление страниц с не тем типом может на это указывать), в 2.1.4 повезло
ещё больше и баг сразу вылез. Найти и уничтожить :)
Какой
Значит не в индексе дело. Хотя тогда ещё более странно все, если часть
индексов
успевает создаться.
В любом случае - раз с удф проблема есть, а без неё - нет, то дело
конечно в фазе луны.
Ясно. А можешь как-то подсказать более короткий путь как этого жука найти.
Или отключать по
Или отключать по порядку каждую функцию,
не по-порядку, а делением пополам конечно.
отключаем половину функций, ресторим
29.09.2009 20:19 я отправил пост с темой Segmentation fault во время работы
gbak -r
*
Обновил у заказчика firebird 1.0 на firebird 2.1
(нужно было использовать временные таблицы и
Vsevolod ...
Значит не в индексе дело. Хотя тогда ещё более странно все, если часть
индексов
успевает создаться.
В любом случае - раз с удф проблема есть, а без неё - нет, то дело
конечно в фазе луны.
Ясно. А можешь как-то подсказать более короткий путь как этого жука найти.
Привет!
Проблема эта решилась только заменой сервера (Старый поработал до
этого 6 лет, решили что пора менять - поменяли стало все нормально
работать). Что для меня было не понятно - сервер был настоящий - с
ECC памятью, и по моему с Intel RAiD U42. Так как за 6 лет работы
сервер морально
В письме от Tue, 11 Oct 2011 14:06:43 +0400, Vsevolod
iuaa...@gmail.com сообщал:
нет у нас ни одного expression index.
а полей computed by UDF/expression-with-UDF ? которые могут встретиться в
индексе
--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
В письме от Tue, 11 Oct 2011 11:51:56 +0400, Vsevolod
iuaa...@gmail.com сообщал:
При этом текстовый лог обрывается вот так :
gbak:activating and creating deferred index FK_KRB_ST_EV_2CERT
gbak:activating and creati
интересно, а там лог буферизованный ?
Почему на пол-слова
Arioch wrote ...
В письме от Tue, 11 Oct 2011 11:51:56 +0400, Vsevolod сообщал:
При этом текстовый лог обрывается вот так :
gbak:activating and creating deferred index FK_KRB_ST_EV_2CERT
gbak:activating and creati
интересно, а там лог буферизованный ?
Обычный stdout
Почему на
22 matches
Mail list logo
