Комментарии 66
Помоему, все что нужно было написать, это: Менеджер процессов FastCGI (FPM) добавлен в SAPI.
Все остальное не так важно.
Все остальное не так важно.
Ввел в поиске «fpm», чтобы найти в changelog`e, обнаружил ваш комментарий) FPMу цены не будет, когда стабильным станет «Dynamic number of processes, depending on the load (adaptive process spawning)»
Ну как не так важно, если почитать changelog — там ошибок связанных с одними только утечками памяти — пол changelog'а, в режиме FastCGI они бы были значительно заметнее. Ну и остальное — никогда не вчитывался в changelog'и, но сейчас прочитал пока переводит — и пришел в ужас, создается впечатление что до этой версии не работала чуть более чем половина всего php.
*пока переводил
Это не далеко от истины мы тут Segmentation fault`ы второй месяц чиним для Debian x86_64 PHP 5.3.2
что показывает backtrace?
О чём вы, если Segmentaion fault, то никаких бектрейсов.
Но вообще проблема заключается в том что в 1 случае из 100 при использовании строковой функции валится Segmentation fault. Если строку предварительно склеить с пустой строкой чуть выше, то никаких ошибок. Так что дело тёмное. Кроме того в Gentoo не воспроизводится, а вот в Бебиане на нескольких тачках в одних и тех же местах.
Но вообще проблема заключается в том что в 1 случае из 100 при использовании строковой функции валится Segmentation fault. Если строку предварительно склеить с пустой строкой чуть выше, то никаких ошибок. Так что дело тёмное. Кроме того в Gentoo не воспроизводится, а вот в Бебиане на нескольких тачках в одних и тех же местах.
Почему єто никаких бектрейсов? Бектрейс как раз дает информацию, где завалилось и на каком методе.
Потому что ошибка настолько серьёзная что бектрейс не пишется.
А на методе любом валится. Просто образуется такая черная дыра что можно одну строковую функцию заменить на любою другую и всё равно свалится. А вот если убрать, то работает.
А на методе любом валится. Просто образуется такая черная дыра что можно одну строковую функцию заменить на любою другую и всё равно свалится. А вот если убрать, то работает.
Как может не писаться бектрейс, поясните? Я в это не верю.
Ниже уже написали, что вам надо сделать — получить кору, скормить ее gdb и получить репорт, в котором попробовать разобраться самостоятельно, либо отправить разработчикам.
httpd.apache.org/dev/debugging.html — читайте и получайте бектрейс.
Либо ткните меня куда-то, где пояснено, почему бектрейса «нету, если ошибка очень серьезная».
Ниже уже написали, что вам надо сделать — получить кору, скормить ее gdb и получить репорт, в котором попробовать разобраться самостоятельно, либо отправить разработчикам.
httpd.apache.org/dev/debugging.html — читайте и получайте бектрейс.
Либо ткните меня куда-то, где пояснено, почему бектрейса «нету, если ошибка очень серьезная».
Простите, но у меня нет времени этим заниматься.
железный аргумент :)
Я занимаюсь развитием OpenSource и сабмичу патчи в разные проекты. В том числе я засабмитил в PHP пять дефектов, два из которых были пофикшены.
Просто я занимаюсь этим тогда, когда у меня есть время и желание, а не потому что кто-то указал мне сделать это в комментариях.
Просто я занимаюсь этим тогда, когда у меня есть время и желание, а не потому что кто-то указал мне сделать это в комментариях.
Причем тут комментарии?
Вы же сами пишите, что имеете проблему:
> мы тут Segmentation fault`ы второй месяц чиним
И тут же говорите, что «нет времени этим заниматься».
Вы уж определитесь — хотите решить проблему или отнекиваться, что мол некогда. Для себя же вроде как.
То, чем вы занимаетесь и куда сабмитите меня в целом не волнует — это никак не относиться к нашему разговору.
Скажите лучше, что просто не знали про бектрейс и на этом разговор закончим, к чему эти припирательства.
Вы же сами пишите, что имеете проблему:
> мы тут Segmentation fault`ы второй месяц чиним
И тут же говорите, что «нет времени этим заниматься».
Вы уж определитесь — хотите решить проблему или отнекиваться, что мол некогда. Для себя же вроде как.
То, чем вы занимаетесь и куда сабмитите меня в целом не волнует — это никак не относиться к нашему разговору.
Скажите лучше, что просто не знали про бектрейс и на этом разговор закончим, к чему эти припирательства.
НЛО прилетело и опубликовало эту надпись здесь
Скормите дебагеру кору, запустите апача с ограничением в 1 дочерний процесс и приаттачтесь с gdb — варианты есть. Стек вызовов будет и без дебаг версии — символы в коде имеются.
Бектрейс отнюдь не бесполезен: в конце концов, это первое, что у вас попросят разработчики, если решите написать баг репорт. Можете покопаться сами, если и не поймете в чем дело, есть шанс, что добьетесь устойчивого репродуцирования бага.
Бектрейс отнюдь не бесполезен: в конце концов, это первое, что у вас попросят разработчики, если решите написать баг репорт. Можете покопаться сами, если и не поймете в чем дело, есть шанс, что добьетесь устойчивого репродуцирования бага.
глупости. Segfault еще ничего не означает, причин для сегфолта может быть мульйон и больше.
Как уже выше написал — нужно получать кору и бегать по ней gdb и не нужно ничего больше ставить, главное прочитать раздел дебаггинга веб-сервера.
Как уже выше написал — нужно получать кору и бегать по ней gdb и не нужно ничего больше ставить, главное прочитать раздел дебаггинга веб-сервера.
Было проходил.
Была бубунта 9.10 (в ней бере появилась)
при переходе на 10.04 бага пропала
за период ожиданий юзался фрибсд
М И С Т И К А
+ подтвердаю :: на генту и мандриве проблемы нет
Была бубунта 9.10 (в ней бере появилась)
при переходе на 10.04 бага пропала
за период ожиданий юзался фрибсд
М И С Т И К А
+ подтвердаю :: на генту и мандриве проблемы нет
5.2.14 тоже, кстати, вышел.
что, конечно, печально. Не совсем понятно стремление разделаться с веткой 5.2, народ ведь еще ой как долго будет переползать на 5.3.
This release marks the end of the active support for PHP 5.2. Following this release the PHP 5.2 series will receive no further active bug maintenance. Security fixes for PHP 5.2 might be published on a case by cases basis.
что, конечно, печально. Не совсем понятно стремление разделаться с веткой 5.2, народ ведь еще ой как долго будет переползать на 5.3.
Как раз очень понятно и правильно — незачем плодить сущности и распылять усилия. И данное предупреждение наряду с самим фактом выпуска уже третьей (и значит, уже достаточно стабильной) версии в ветке 5.3 — хороший повод для хостинг-провайдеров начать шевелиться.
Да давно бы уж пора, с момента первого релиза PHP 5.3 прошел уже год, а воз и ныне там.
Хостеры шевелятся. Только вот так ли это надо?
Ещё в прошлом году на виртхостинге к возможности выбора версии PHP 4.4.х или 5.2.х добавили 5.3.х. И что?
Используют PHP5.3 <0,1%.
Есть как субъективные причины («не трож, раз работает») и объективные — не все требуемые продукты работают под 5.3.
Ещё в прошлом году на виртхостинге к возможности выбора версии PHP 4.4.х или 5.2.х добавили 5.3.х. И что?
Используют PHP5.3 <0,1%.
Есть как субъективные причины («не трож, раз работает») и объективные — не все требуемые продукты работают под 5.3.
отсутствие ZendOptimizer под 5.3 к сожалению не позволяет шевелиться :(
под линух его уже больше года никак не выпустят, под фрибсд вроде вообще не будет :(
под линух его уже больше года никак не выпустят, под фрибсд вроде вообще не будет :(
ionCube Loader, Suhosin, eAccelerator — уже есть поддержка PHP5.3 и довольно давно.
C Zend ситуация интересная — есть поддержка PHP5.3 в Zend Server, в его состав входит ZendOptimizer+, и там тоже поддержка есть. Только это совсем не то же самое.
C Zend ситуация интересная — есть поддержка PHP5.3 в Zend Server, в его состав входит ZendOptimizer+, и там тоже поддержка есть. Только это совсем не то же самое.
лучше побыстрее переполз бы этот народ. не вижу смысла сидеть на устаревшем php
Это потребует переписывания как минимум половины PEAR, что само по себе прискорбно (большое кол-во пакетов PEAR написано в ООП-стиле на PHP 4, а обратной совместимости нет). При использовании пакетов PEAR и так приходится кучу deprecated-ошибок править.
пхп4-ооп стиль вполне совместим с пхп5.3. лично у меня что PEAR(насколько я с ним работал) что Джумла первая, что другие пережитки прошлого вполне вменяемо работают на пхп5.3
Попробовал недавно запустить джумлу под 5.3 — даже инсталятор не завёлся практически с самого начала. Не стал разбираться, ибо всё равно хостинг под этот проект заказчик на 5.2 взял.
Из известных мне проектов некоторые гордо сообщили, что ныне совместимы с 5.3. Прочие скромно молчат. В любом случае, при переводе чего угодно с 5.2 на 5.3 прийдётся усиленно тестировать.
Из известных мне проектов некоторые гордо сообщили, что ныне совместимы с 5.3. Прочие скромно молчат. В любом случае, при переводе чего угодно с 5.2 на 5.3 прийдётся усиленно тестировать.
НЛО прилетело и опубликовало эту надпись здесь
Ну так разработчики сами себе злобные буратины, несмотря на то что ereg() стал deprecated только в версии 5.3 — предупреждения о том что он устаревший, медленный и т.д. и т.п. были в справке по-моему с самого появления 5-ой версии, иже уже лет этак 6, но разработчики популярных cms по-моему лучше отстрелят себе ногу, чем откажутся от этой чудо-функции, которая собственно от preg_match по функциональности ничем выдающимся не отличается.
Это потому что вы не админ и интегратор. В нашем деле просто так не обновляются ибо за это по шапке дают.
Так не делается.
PHP 5.3 — это очень существенный шаг вперед, причем основные изменения касаются ядра языка (в отличие от релизов 5.1 и 5.2 — обычных security & stability релизов с апгрейдом расширений). Причем, судя по чейнжлогам, разработчики сами до конца не определились, как и что у них должно теперь работать. В таких случаях необходимо поддерживать две ветки, иначе это детский сад, а не процесс разработки в проекте, которому (в современном его виде) уже 12 лет.
PHP 5.3 — это очень существенный шаг вперед, причем основные изменения касаются ядра языка (в отличие от релизов 5.1 и 5.2 — обычных security & stability релизов с апгрейдом расширений). Причем, судя по чейнжлогам, разработчики сами до конца не определились, как и что у них должно теперь работать. В таких случаях необходимо поддерживать две ветки, иначе это детский сад, а не процесс разработки в проекте, которому (в современном его виде) уже 12 лет.
Когда ожидать на repo?
Поставил. Полет отличный.
Теги записи нужно через запятые перечислять, а не просто через пробел — сейчас это один тег «php php5.3 bug feature».
Исправлена ошибка №51213 (pdo_mssql обрезает значение столбца типа money) — моя работа :)
решето…
Интересный баг.
№50578 некорректная штука(?)
№50578 некорректная штука(?)
Вопрос там мой :) ну если так и написано — штука :) может конечно я не нашелся как корректно это перевести… но я так понимаю это все написано не на чистовую, под релиз, а взято прямо из производственного процесса, иже комментарии разработчиков, названия тикетов и т.п.
Вот оно :) multitran.ru/c/m.exe?CL=1&l1=1&s=shebang
Вот что такое Shebang: #!/bin/sh, например
А gettext так и не починили?
НЛО прилетело и опубликовало эту надпись здесь
Интересно, оно теперь будет собираться с родным libiconv на Mac OS X…
Надо проверить…
Надо проверить…
Хабровская:
— Исправлена ошибка №52001 (Ошибка выделения памяти после использования переменных переменных).
— Исправлена ошибка №52001 (Ошибка выделения памяти после использования переменных переменных).
У меня сейчас проблема на сервере, после обновления портов, не работает GD с PNG (ОС FreeBSD 8.0) — обновлял порты месяц назад — и снова появилась ошибка не совместимости php5-gd с png_1.4 (падает пхп с Core Dump)
До этого эта ошибка был в 5.2.8, так как 5.2.8 работал с png_1.2, а как выкатили 1.4 — появился баг… Сейчас тоже самое с 1.4.1_1 (вроде такая версия последняя)
Пробовал пересобирать как png, так и php5-gd. пересобирал все зависимости =( не помогает…
Может кто то сталкивался с проблемой??? баг появился месяц назад… до этого тоже самое было в апреле-мае
До этого эта ошибка был в 5.2.8, так как 5.2.8 работал с png_1.2, а как выкатили 1.4 — появился баг… Сейчас тоже самое с 1.4.1_1 (вроде такая версия последняя)
Пробовал пересобирать как png, так и php5-gd. пересобирал все зависимости =( не помогает…
Может кто то сталкивался с проблемой??? баг появился месяц назад… до этого тоже самое было в апреле-мае
«Изменены классы в пространствах имен, так что теперь конструктор может быть задан только через __construct» это как понимать? только при
namespace dfgdg;
не будут работать конструкторы типа php4?
namespace dfgdg;
не будут работать конструкторы типа php4?
Лучше бы нормальную поддержку юникода сделали (
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Релиз PHP 5.3.3