Perlover's Blog » bugs http://blog.perlover.com Blog about Unix, Perl, Firefox, JavaScript and other internet technologies Fri, 20 Jan 2012 15:23:43 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Массивы JavaScript, Internet Explorer и запятые http://blog.perlover.com/2011/02/10/javascript-array-internet-explorer-comma-end/ http://blog.perlover.com/2011/02/10/javascript-array-internet-explorer-comma-end/#comments Thu, 10 Feb 2011 13:53:06 +0000 Perlover http://blog.perlover.com/?p=1208 Заметил такую особенность — если описывать массив как

var array = [
elem1,
elem2,
elem3,
];

То в Firefox и Google Chrome — он будет иметь 3 элемента, а в Internet Explorer (тестировалось в 8-ой версии) — 4 элемента, причем 4-ый будет null.

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

Оказывается, такой стиль имеет скрытую угрозу — ошибки, когда «прогулка»  по массиву дает null элемент, тогда как такой программист предполагал, что будет три элемента и все — не null. Вообщем, программеры JavaScript — остерегайтесь ;-)

На последок — тестовый HTML файл (сохраните код и откройте в броузере) — проверьте сами, что выдают броузеры :) 

<html>
<body>
<script>var array = [1, 2, 3, ]; alert(array.length) </script>
</body>
</html>
]]> http://blog.perlover.com/2011/02/10/javascript-array-internet-explorer-comma-end/feed/ 0 Опять Cookies, только теперь Google Chrome http://blog.perlover.com/2011/02/08/cookies-google-chrome-quoted-path-bug/ http://blog.perlover.com/2011/02/08/cookies-google-chrome-quoted-path-bug/#comments Tue, 08 Feb 2011 18:12:03 +0000 Perlover http://blog.perlover.com/?p=1192 Не успел написать программу, как опять наткнулся на неприятность, точнее, на баг. Смысл его в том, что Google Chrome некорректно ставит в JavaScript свойство document.cookie, если кука пришла от сайта с quoted path, то есть, если пришла такая:

Set-Cookie: session=session_ID; path="/"

Дело в том, что путь, заключенный в кавычки — правило, определенное самим RFC 2109 (пункт 4.1). Firefox это обрабатывает корректно, а Google Chrome — глючит. То есть, чтобы в JavaScript от Chrome считывать куки, нужно их выставлять через path без кавычек. Но в любом случае, это некорректно, поэтому отписал об этом на их форум. Посмотрим, как они исправят это ;-)

]]> http://blog.perlover.com/2011/02/08/cookies-google-chrome-quoted-path-bug/feed/ 0 Set-Cookie2 и Firefox :( http://blog.perlover.com/2011/02/08/set-cookie2-firefox-mozilla/ http://blog.perlover.com/2011/02/08/set-cookie2-firefox-mozilla/#comments Tue, 08 Feb 2011 16:24:02 +0000 Perlover http://blog.perlover.com/?p=1189 Пришлось выставлять куки программой через HTTP заголовки, и с удивлением для себя обнаружил, что Firefox 3.6.13 (самая последняя версия на данный момент) не поддерживает заголовки «Set-Cookie2:», которые определены аж в RFC 2965 от 2000 года. Работает он, видимо, только со старым типом кук — RFC 2109 (Set-Cookie:). На других броузерах не тестировал. Вообщем, программеры, учитывайте это обстоятельство ;-) Вообще, это очень странно, ведь Firefox славится следованиям разного рода стандартам.

]]> http://blog.perlover.com/2011/02/08/set-cookie2-firefox-mozilla/feed/ 0 Samba & Archive аттрибут = -Executable http://blog.perlover.com/2011/01/20/samba-archive-attribute-executable/ http://blog.perlover.com/2011/01/20/samba-archive-attribute-executable/#comments Thu, 20 Jan 2011 18:16:04 +0000 Perlover http://blog.perlover.com/?p=1144 Заметил неприятную особенность дефолтной конфигурации Samba — при сбрасывании из под Windows Archive аттрибута редактируемого файла разными редакторами, сбрасываются permissions ‘x’ (права файла) на Unix для пользователя, который владеет файлом. Например, есть на Unix файл с правами rwxr-xr-x. Если вы его через Samba поредактируете в Windows каким либо редактором, который любит сбрасывать аттрибут archive (far или komodo edit), то после сохранения изменений файл будет иметь permissions как rw-r-xr-x. Для Unix пользователей это очень плохо — файл перестает быть исполняемым для самого владельца, зато остается исполняемый для всех, кроме него. Долго искал причину, почему после редактирования в Komodo Edit теряется исполняемый бит, грешил на редактор, а выловил такую особенность default Samba configuration :)

Для решения этой проблемы надо просто напросто добавить строку map archive = no в smb.conf файл. После перезапустить samba: service smb stop & service smb start

]]> http://blog.perlover.com/2011/01/20/samba-archive-attribute-executable/feed/ 0 Если у вас не работает OpenCV под 64 бит… http://blog.perlover.com/2011/01/10/opencv-core-files-64bit/ http://blog.perlover.com/2011/01/10/opencv-core-files-64bit/#comments Mon, 10 Jan 2011 16:11:26 +0000 Perlover http://blog.perlover.com/?p=1108 Боролся недавно с одной проблемой — решил поделиться с вами ее решением, если вдруг вы нашли мою страницу, например, через Google ;-) Вряд ли рядовой читатель моего блога сталкивался с такой же проблемой. Потому и уповаю на Google :-)

Итак, библиотека распознавания образов — OpenCV — упорно не хочет работать на Linux Fedora Core 13 (FC13) под 64 битами! Причем как версия 1.1, так и версия 2.2. Причем,  баг проявлялся на уровне мистики — все компилированные версии opencv падали в segmentation fault (core file), и только на 64 бит, а в интернете про эту проблему совсем ничего — как будто ее и нет!  Если ставить opencv из RPM, то можно поставить 2.0, но и с ней есть проблемы (не работал perl модуль Image::ObjectDetect — сейчас он работает, но с версии 2.1). Нужна была либо 1.1, либо выше 2.0. А вот если скачать 2.2 с сайта и собрать — она нормально собереться, но при работе с ней ваши программы упорно будут выпадать в core файлы (segmentation fault). То же касается версии 1.1. Вообщем, гуглил муглил я, копался в core файлах с отладчиком gdb и выяснил, что падает она в cvCanny функции. И нашел я вот этот баг. И кто бы мог подумать, что это глюки не самой OpenCV! Я то все время думал, что разработчики opencv виноваты. Оказалось, что проблема куда глубже — компилятор GCC 4.4.3 и ранее имел баг при оптимизации кода. Результат — некоторые программы и библиотеки под 64 битами могут доходить до segfault. Не стал исключением и OpenCV (сколько таких скрытых багов могло «подтянуться» к другим библиотекам и программам — можно только гадать). Вообщем, проблема решилась обновлением GCC компилятора из репозитария Fedora Core 13 и последующей перекомпиляцией OpenCV. После проверил — обе версии — 1.1 & 2.2 работали на отлично.

]]> http://blog.perlover.com/2011/01/10/opencv-core-files-64bit/feed/ 2 Как заставить Copy Plain Text работать http://blog.perlover.com/2010/08/03/copy-plain-text-doesn-t-work-freezes/ http://blog.perlover.com/2010/08/03/copy-plain-text-doesn-t-work-freezes/#comments Tue, 03 Aug 2010 07:05:49 +0000 Perlover http://blog.perlover.com/?p=953 Разработчик расширения «Copy Plain Text» для Firefox не позаботился о том, чтобы обновить версию «Copy Plain Text» для последних и современных браузеров Firefox 3.6.* — 5.* (поставил любую максимальную версию в RDF файле), хотя его расширение используется многими другими, например AutoCopy. Результат — некорректная его работа после устновки — невозможно открыть «опции» (Options) для него из пункта Tools -> Add-ons — Firefox просто перестает реагировать на действия внутри окна Add-ons. Решение — либо вручную сделать изменения для установленного и не работающего расширения, либо использовать, например, уже правленную версию, например мою. Для моей версии кликните по этой ссылке (Firefox v*.*), а для тех, кто хочет руками поправить, смотрите патч в формате утилиты patch — ее формат довольно понятен без всяких комментариев:

diff -Nur 1/copy_plain_text-0.3.3-fx+mz+tb/chrome.manifest 2/copy_plain_text-0.3.3-fx+mz+tb/chrome.manifest
--- 1/copy_plain_text-0.3.3-fx+mz+tb/chrome.manifest	1970-01-01 05:00:00.000000000 +0500
+++ 2/copy_plain_text-0.3.3-fx+mz+tb/chrome.manifest	2010-08-03 12:17:02.031250000 +0600
@@ -0,0 +1,6 @@
+overlay chrome://browser/content/browser.xul chrome://copyplaintext/content/overlay.xul
+overlay chrome://navigator/content/navigatorOverlay.xul chrome://copyplaintext/content/overlay_moz.xul
+overlay chrome://navigator/content/navigator.xul chrome://copyplaintext/content/overlay_moz.xul
+overlay chrome://messenger/content/mailWindowOverlay.xul chrome://copyplaintext/content/overlay_thunder.xul
+overlay chrome://messenger/content/messengercompose/messengercompose.xul chrome://copyplaintext/content/overlay_thunder.xul
+content copyplaintext jar:chrome/copyplaintext.jar!/content/
diff -Nur 1/copy_plain_text-0.3.3-fx+mz+tb/install.rdf 2/copy_plain_text-0.3.3-fx+mz+tb/install.rdf
--- 1/copy_plain_text-0.3.3-fx+mz+tb/install.rdf	2006-11-27 21:14:12.000000000 +0500
+++ 2/copy_plain_text-0.3.3-fx+mz+tb/install.rdf	2010-08-03 12:15:14.812500000 +0600
@@ -22,7 +22,7 @@
 			<Description>
 				<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
 				<em:minVersion>1.0</em:minVersion>
-				<em:maxVersion>2.0</em:maxVersion>
+				<em:maxVersion>*.*</em:maxVersion>
 			</Description>
 		</em:targetApplication>
]]> http://blog.perlover.com/2010/08/03/copy-plain-text-doesn-t-work-freezes/feed/ 2 Roboform + Firefox = CPU 100% http://blog.perlover.com/2010/05/21/firefox-roboform-bug-cpu-100/ http://blog.perlover.com/2010/05/21/firefox-roboform-bug-cpu-100/#comments Fri, 21 May 2010 15:16:01 +0000 Perlover http://blog.perlover.com/?p=766 Давно юзаю Roboform, и все никак не могу избавиться от бага, о котором я уже неоднократно сообщал в суппорт разработчика. Сначала они не хотели его признавать, потом, после моих настойчивых тикетов, они его признали, а затем «забили» на него — не отказываются от него, но и не устраняют его (баг есть более года).

Итак, если говорить кратко, то если вы используете последние версии программ Roboform 6.9.9*б 6.10.* (включая из 7-у. бета версию) и Firefox 3.6.*, то часто ваш Firefox будет зависать с потреблением CPU (процессора) на 100%. А более подробно чуть ниже.

Страницы, которые используют JavaScript и манипулируют документом HTML, называются DHTML, или страницами, работающими с DOM структурой документа, или еще их называют Ajax. И именно на таких страницах проявляется этот баг. В жизни, это может быть статистика чего либо, либо даже интернет-магазин сайт и т.п..  Сейчас я вам продемонстрирую такую страницу, где эта проблема Roboform возникает всегда! Итак, если у вас есть и Roboform и Firefox, идите на страницу http://google.com/codesearch/p?hl=en#6V-_MuMB1HQ/mozilla-2.0.0.3/mozilla-2.0.0.3/xpcom/build/malloc.c (эта страница — просто пример программого кода, найденного через Google Code Search — вы можете доверять той странице, так как там исполняются только скрипты, написанные Google), затем кликните левой кнопкой мыши по правому окну, где программный код (если этого не выполнить, а сразу покрутить колесиком мышки, зависания не произойдет) программы, и покрутите колесиком мышки в этом окне. Я уверен, что если все условия выполнены, ваш Firefox зависнет. Но, если у вас на компьютере нет Roboform-а, все будет работать на отлично и вы даже не заметите каких либо задержек при прокрутке! Также, не помогает отключение адаптера в Firefox — требуется деинсталяция Roboform (можно деинсталировать, не трогая пасскарты и лицензию и не перегружая компьютер).

Другими словами, Roboform — это зло, если вы работаете в Firefox. Из-за него ваш броузер будет часто зависать на разного рода сайтах и вы будете терять свое драгоценное время, выполненую работу и деньги. И главное — разработчикам Roboform-а на это абсолютно пофиг. У них есть куда более важные задачи, например, как сделать  красивее кнопочки, или менюшечки с иконками. Тем более, рядовому пользователю трудно догадаться, почему завис его броузер. Скорее всего, этот пользователь просто спишет все свои проблемы на разработчиков Firefox (ведь косяки Roboform-а отражаются именно на нем).

Также, если вам все это не нравится и вы не готовы тратить нервы, могу предложить вам использовать бесплатную замену — LastPass. Не такой гибкий, как Roboform, зато не подвешивает броузер.

P.P.S. Из этой же оперы, пишут другие люди — зарубежные пользователи:

Roboform can cause extreme slowness in Firefox

]]> http://blog.perlover.com/2010/05/21/firefox-roboform-bug-cpu-100/feed/ 5 Немного про ИБП фирмы APC http://blog.perlover.com/2009/12/14/ups-apc-troubles-hints/ http://blog.perlover.com/2009/12/14/ups-apc-troubles-hints/#comments Mon, 14 Dec 2009 08:38:35 +0000 Perlover http://blog.perlover.com/?p=641 ИБП — это источник бесперебойного питания (UPS — англ. термин). У ИБП широко-распространенной марки APC есть пара интересных особенностей, о которых я напишу.

Правильный момент включения

Когда вы включаете  APC, у него сначала мигает зеленая верхняя лампочка («On line»), затем через пару секунд загорается желтая средняя из трех лампочек («On Battery») — это идет тестирование, а затем она гаснет и снова начинает гореть постоянно зеленая «On line». Дак вот, мало кто знает, что по правильному лучше компьютер включать не сразу, а в тот момент, когда мигает желтая «On Battery» — это идет момент тестирования, и если вы, включив компьютер, обнаружите, что он не включается именно в этот момент, значит ИБП вам не поможет в случае отсутствия 220V в вашей розетке. Если же вы включите компьютер после тестирования (когда горит только зеленый верхний индикатор), то вы не узнаете, поможет ли вам UPS, так как момент тестирования уже будет пройден и в этот момент ваш ИБП работает просто как сетевой фильтр. Если включите до тестирования, то возможно, на фазе тестирования питание к компьютеру пропадет — это также будет говорить про будущие проблемы с питанием. Но такой момент может пройти малозаметно для вас. Поэтому включайте комп всегда в момент самотестирования.

Если новый UPS

Также, если вы купили новый UPS, его вам надо зарядить как минимум 8 часов без нагрузки. Средний срок жизни аккумулятора APC, заявленный производителем — около 3х лет. По моему опыту — он может быть 5 и более лет.

Мои «проблемные» UPS…

Из своего небольшого опыта (сталкивался с 4-5-тью UPS фирмы APC) я уже столкивался с такими проблемами (я сам, честно говоря, поражен такой статистикой, но данные дефекты труднодоказуемы в сервисе, поэтому ремонтники могут даже и не знать о них):

  1. С одним UPS у меня регулярно наблюдается такое: то несколько дней и недель тесты всегда проходят, то несколько дней или недель у меня они не проходят. С чем это связано, я не знаю. Вряд ли аккумулятор — у меня есть APC более старые + я неоднократно оставлял этот проблемный ИБП на зарядке 8 часов и более — не помогало. Я даже снимал контакты с батареи, чистил их, надевал и обжимал — не помогало. Также, для неисправного аккумулятора в APC предусмотрена индикация «Replace Battery», но я никогда еще нигде не видел, чтобы она загоралась. Вообщем, итог в этом случае — неведомые мне «глюки», возможно, в электронике.
  2. Был UPS, который не держал определенные старые корпуса системных блоков. Например, подключаешь к нему корпус компа эдак 2003-го года, выключаешь APC из розетки — комп идет на перезагрузку. Подключаешь системник 2008-го года — все работает на ура. Другие APC такой же марки могли «держать» и старый корпус. С чем связано? Догадки только такие: ИБП выпускаются с погрешностью времени переключения +/- несколько миллисикунд, например. Для производителя — все в пределах нормы, там даже с APC идет всегда распечатка тестирования на заводе. Но на практике, видимо, все не так — для некоторых блоков питания эта погрешность значима. По моему предположению — есть корпуса с питанием, где есть конденсаторный блок, который может спасать от кратковременных перерывов или падения питания (доказательством этого является факт свечения оптической USB мышки уже после выключения системного блока — питание на USB пропадает не сразу). В моем случае, старый корпус такого блока не имел, а новый имеет. От того, на там ИБП были такие результаты. Но повторюсь, подключая другие APC такой же марки, тот старый «системный» блок не перегружался. Видимо, все таки есть заведомо проблемные APC. И вам их даже не заменят, если вы придете к продавцу или в мастерскую — там просто не смогут повторить вашу проблему (либо надо брать свой системный блок).

Итого: из 5-ти APC, два из них были «проблемными». Моя статистика — это 40%. Нехило для широкоизвестной фирмы!

Выводы

Если не хотите потярять важные данные, всегда включайте компьютер в момент тестирования и он сразу должен заработать — иначе — он вам не поможет при отказе 220V в вашей розетке. И второй вывод: после покупки проверьте ИБП именно на том системном блоке, с которым вы будете его эксплуатировать (проверка только одна — вытащить шнур из розетки). Если он не держит, идите его меняйте, но не забудьте взять системный блок, так как часто проблема может быть в паре — ИБП + «системник».

]]> http://blog.perlover.com/2009/12/14/ups-apc-troubles-hints/feed/ 7 Автозаполнение Firefox — маленький глюк http://blog.perlover.com/2009/11/30/autofill-bug-firefox/ http://blog.perlover.com/2009/11/30/autofill-bug-firefox/#comments Mon, 30 Nov 2009 10:12:02 +0000 Perlover http://blog.perlover.com/?p=552 Установлен у меня Firefox 3.0.15. Но вот уже продолжительное время наблюдаю такой глюк. Причем только на одном компе из двух. Спустя непродолжительное время, например, после работы в некоторых сайтах (например, заведение аккаунта в Google Analytics), вдруг везде перестает работать автозаполнение в Firefox. То есть сначала все как обычно — клик мышки в каком либо поле — предлагается список ранее вводимых данных для поля формы, а в некоторый момент времени все это перестает работать — клик мышки и никаких предложений о вводе в поле от Firefox нет. Глюк не страшный, но раздражает. Лечится только рестартом «Огненной Лисы». Может кто встречал у себя подобный глюк? Я по интернету рыл — ничего подобного ни у кого не нашел. Но у меня он встречается постоянно — каждый день :(

]]> http://blog.perlover.com/2009/11/30/autofill-bug-firefox/feed/ 0