Created attachment 7457 [details] chromium/i586 debug info Chromium на i586 не запускается. В консоли ругается: Недопустимая инструкция Воспроизводится 100% в виртуалке QEMU. Похож на баг #32731. Можно скачать свежую регулярку icewm/i586, установить на виртуальный диск, добавить репу с debuginfo, установить gdb и chromium-debuginfo. Детали в приложении...
$ lscpu Architecture: i686 CPU op-mode(s): 32-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 6 Model name: QEMU Virtual CPU version 2.5+ Stepping: 3 CPU MHz: 2592.004 BogoMIPS: 5184.00 Hypervisor vendor: KVM Virtualization type: full L1d cache: 32K L1i cache: 32K L2 cache: 4096K L3 cache: 16384K Flags: fpu de pse tsc msr pae mce cx8 apic sep pge cmov mmx fxsr sse sse2 ht cpuid pni x2apic hypervisor $ rpm -qi chromium Name : chromium Version : 65.0.3325.146 Release : alt1 Architecture: i586 Install Date: Вт 27 мар 2018 08:15:45 Group : Networking/WWW Size : 243661414 ... Нужна дополнительная информация?
А можно воспроизвести этот баг не в qemu? Либо покажите вывод /proc/cpuinfo с хост системы и с какими флагами запускается сам qemu.
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/Y1E391CFJf0 "I have a i586 CPU. It doesn't support SSE instructions." "No, we don't do anything to support CPUs that old."
(В ответ на комментарий №2) > А можно воспроизвести этот баг не в qemu? Не знаю, судя по трейсу, возможно. К сожалению, мне пока не на чем. > Либо покажите вывод /proc/cpuinfo с хост системы $ cat /proc/cpuinfo ... processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz stepping : 3 microcode : 0xba cpu MHz : 799.963 cache size : 6144 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb invpcid_single retpoline rsb_ctxsw kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp bugs : cpu_meltdown spectre_v1 spectre_v2 bogomips : 5184.00 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: # то есть всего восемь полу-ядер таких [0-7] # и тоже с хост-системы, не из гостевой: $ uname -a Linux bmt 4.9.80-std-def-alt0.M80P.1 #1 SMP Mon Feb 5 17:49:55 UTC 2018 x86_64 GNU/Linux > и с какими флагами запускается сам qemu $ vhd_file="$(mktemp -q $TMPDIR/qemu-XXXXXXXXX.img)" $ qemu-img create -f qcow2 -o size=25G "$vhd_file" $ qemu-system-i386 -name icewm/i586 \ -machine type=q35,igd-passthru=on,accel=kvm -enable-kvm \ -smp sockets=1,cores=4 -m 4096 -balloon virtio -soundhw hda,pcspk \ -drive if=scsi,id=drive0,format=qcow2,file=$vhd_file \ -device scsi-hd,drive=drive0 -cdrom regular-icewm-20180327-i586.iso \ -netdev user,id=net0,restrict=no -device virtio-net,netdev=net0,id=eth0 \ -fsdev local,security_model=none,id=fsdev0,path=$TMPDIR \ -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=host-in \ -rtc base=localtime,clock=host,driftfix=slew -no-fd-bootchk \ -sdl -ctrl-grab -vga virtio Два раза в неделю я тестирую регулярки. Все наши дистрибутивы. По крайней мере, для i586. И набор параметров QEMU стараюсь сильно не менять. Сегодня проверялось с такими параметрами. С другими браузерами и пакетами таких проблем не обнаружено. Впрочем, иногда (редко, но бывает) с этими параметрами сама виртуалка не запускается, QEMU-сегфолтится в момент загрузки иксов. Причём, только на icewm, gnustep, wmaker с i586, на x86_64 такого не было ни разу. Но это почти не воспроизводимо и вряд ли связано, а вот вызов недопустимой инструкции в chromium чётко воспроизводится только в сегодняшней регулярке без падения самой QEMU, в ней даже подебажить это удалось. (В ответ на комментарий №3) > "No, we don't do anything to support CPUs that old." Понятно. Точнее не совсем. Ведь в моём случае процессор гостевой системы поддерживает набор инструкций SSE и даже SSE2: Flags: fpu de pse tsc msr pae mce cx8 apic sep pge cmov mmx fxsr sse sse2 ht cpuid pni x2apic hypervisor
Предыдущая версия chromium работает в таком же окружении ?
(В ответ на комментарий №5) > Предыдущая версия chromium работает в таком же окружении ? Месячной давности -- да, работает. Недельной давности -- нет, не работает. Последнее время не я тестировал, но неделю назад успел к себе закачать. Миша и Антон тестируют в VirtualBox'е. Сейчас надо разбираться по датам, когда это случилось. От 20 марта -- уже не работает. От 21 февраля -- ещё работало. Доеду до работы, тогда смогу посмотреть между ними остальные.
(В ответ на комментарий №6) > (В ответ на комментарий №5) > > Предыдущая версия chromium работает в таком же окружении ? > > Месячной давности -- да, работает. Недельной давности -- нет, не работает. > Последнее время не я тестировал, но неделю назад успел к себе закачать. Миша и > Антон тестируют в VirtualBox'е. Сейчас надо разбираться по датам, когда это > случилось. От 20 марта -- уже не работает. От 21 февраля -- ещё работало. Доеду > до работы, тогда смогу посмотреть между ними остальные. /ALT/repo/sisyphus/date/2018/02/05/files/SRPMS/chromium-63.0.3239.132-alt1.src.rpm /ALT/repo/sisyphus/date/2018/02/06/files/SRPMS/chromium-64.0.3282.119-alt1.src.rpm /ALT/repo/sisyphus/date/2018/03/16/files/SRPMS/chromium-65.0.3325.146-alt1.src.rpm между 21 февраля и 20 марта была смена версии. меня интересует работает ли 64.0.3282.119-alt1 в том же окружении.
(In reply to comment #7) > /ALT/repo/sisyphus/date/2018/02/06/files/SRPMS/chromium-64.0.3282.119-alt1.src.rpm > > между 21 февраля и 20 марта была смена версии. > меня интересует работает ли 64.0.3282.119-alt1 в том же окружении. Да, эта версия работает: $ rpm -qi chromium Name : chromium Version : 64.0.3282.119 Release : alt1 Architecture: i586 Install Date: Ср 21 фев 2018 05:08:00 Group : Networking/WWW Size : 317406583 License : BSD-3-Clause and LGPL-2.1+ Signature : DSA/SHA1, Вс 04 фев 2018 20:56:28, Key ID 95c584d5ae4ae412 Source RPM : chromium-64.0.3282.119-alt1.src.rpm Build Date : Вс 04 фев 2018 20:45:58 Это регулярка icewm/i586 от 21.02.2018, которая у меня сохранилась. А вот в публичном доступе всё уже "уехало", но думается, хотя и не проверял, что в этой регулярке: http://nightly.altlinux.org/sisyphus/snapshots/20180307/regular-icewm-20180307-i586.iso собрана та же версия chrominum (старым llvm).
Да, в мартовских та же версия. Достаточно поменять timestamp и использовать команду выше, чтобы убедиться. Вот в этих: 20180307, 20180314 -- работающая версия 64.0, а в 20180321 уже сломалось и там как раз новая версия 65.0.
(In reply to comment #9) > Да, в мартовских та же версия. Достаточно поменять timestamp и использовать > команду выше, чтобы убедиться. Вот в этих: 20180307, 20180314 -- работающая > версия 64.0, а в 20180321 уже сломалось и там как раз новая версия 65.0. Да, я проморгал на прошлой недели, на i586 chromium не запускал...
Created attachment 7474 [details] multi-thread debug info
Created attachment 7475 [details] chromium crash disassembly Выкладываю дополнительную информацию по просьбе Глеба...
(In reply to comment #12) > Created an attachment (id=7475) [details] > chromium crash disassembly > > Выкладываю дополнительную информацию по просьбе Глеба... => 0x02807dee <+686>: ud2 Какой интересный компилятор.
*** Bug 34742 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > (In reply to comment #12) > > Created an attachment (id=7475) [details] [details] > > chromium crash disassembly > > > > Выкладываю дополнительную информацию по просьбе Глеба... > > => 0x02807dee <+686>: ud2 > > Какой интересный компилятор. http://blog.davidwolinsky.com/2015/03/gcc-and-ud2-instructions.html Наводит на мысль, что либо это флаги сборки, либо что-то не так с оптимизацией.
(В ответ на комментарий №15) > http://blog.davidwolinsky.com/2015/03/gcc-and-ud2-instructions.html > > Наводит на мысль, что либо это флаги сборки, либо что-то не так с оптимизацией. А накакие флаги стоит обратить внимение ? Я сейчас пробую -O1 т.к. слышал, что это помогает в некоторых случаях, но прогноз плохой т.к. под i586 я схватил сигнал при линковке.
(В ответ на комментарий №15) > Наводит на мысль, что либо это флаги сборки, либо что-то не так с оптимизацией. Оптимизированный код без отладки и код с отладочными символами лучше получать двумя раздельными операциями, иначе такое на выходе вероятно. Насколько я понимаю, это может войти в противоречие с концепцией отделения отладочных символов в debuginfo репозиторий. (В ответ на комментарий №16) > А на какие флаги стоит обратить внимание ? Я бы добавил только это: -fno-isolate-erroneous-paths-attribute.
Created attachment 7477 [details] Debian's patch to disable sse2
Этот патч из Debian не поможет? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750361
(In reply to comment #13) > (In reply to comment #12) > > Created an attachment (id=7475) [details] [details] > > chromium crash disassembly > > > > Выкладываю дополнительную информацию по просьбе Глеба... > > => 0x02807dee <+686>: ud2 > > Какой интересный компилятор. Это не компилятор. На x86 так обычно реализуют макрос BUG(): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/include/asm/bug.h#n73 Я бы сделал gdb record, а затем отмотал назад на несколько шагов, чтоб посмотреть, что его вызвало.
(In reply to comment #20) > (In reply to comment #13) > > (In reply to comment #12) > > > Created an attachment (id=7475) [details] [details] [details] > > > chromium crash disassembly > > > > > > Выкладываю дополнительную информацию по просьбе Глеба... > > > > => 0x02807dee <+686>: ud2 > > > > Какой интересный компилятор. > > Это не компилятор. На x86 так обычно реализуют макрос BUG(): > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/include/asm/bug.h#n73 > > Я бы сделал gdb record, а затем отмотал назад на несколько шагов, чтоб > посмотреть, что его вызвало. И я бы посмотрел gdb x/i в точке падения.
(В ответ на комментарий №18) > Created an attachment (id=7477) [details] > Debian's patch to disable sse2 Нет. Такой патч не годится т.к. на этой платформе есть sse2. Да и поддерживать его просто адище. (В ответ на комментарий №17) > > А на какие флаги стоит обратить внимание ? > > Я бы добавил только это: -fno-isolate-erroneous-paths-attribute. Стоит попробовать. Спасибо.
(В ответ на комментарий №22) > (В ответ на комментарий №17) > > Я бы добавил только это: -fno-isolate-erroneous-paths-attribute. > > Стоит попробовать. Даже не знаю. Ставлю breakpoint в "падающем" методе policy:: ConfigurationPolicyHandlerList:: ApplyPolicySettings(). Делаю next и программа бежит дальше, выпадая в другом месте (тоже на ud2), но уже не в этой функции. То есть очень возможно, что это ошибка апстрима в 32-бит реализации многопоточности. Могу приложить ассеблерный код всего метода. Судя по нему, всего 4 проверки выполняется, которые приводят к точке <+686> ud2. (В ответ на комментарий №20) > Это не компилятор. На x86 так обычно реализуют макрос BUG(): Кстати, на целевой платформе действительно CONFIG_DEBUG_BUGVERBOSE=y, если это желательно учитывать. А при сборке там оно же по идее должно быть? > Я бы сделал gdb record, а затем отмотал назад на несколько шагов, чтоб > посмотреть, что его вызвало. Тут выше уже выкладывал и короткий, и полный backtrace, но я так не очень понял, надо record btrace pt или bts? Может хватит кода функции (asm) + все данные в стеке, с чем оно там оказывается?
(В ответ на комментарий №17) > Я бы добавил только это: -fno-isolate-erroneous-paths-attribute. clang++: error: unknown argument: '-fno-isolate-erroneous-paths-attribute' Я не вижу другого выхода кроме отката на gcc. На это уйдёт некоторое время.
А собирать под x86_64 clang, а под i586 - gcc, насколько трудозатратно?
(В ответ на комментарий №24) > clang++: error: unknown argument: '-fno-isolate-erroneous-paths-attribute' Это gcc'шный флаг, да. > Я не вижу другого выхода кроме отката на gcc. На это уйдёт некоторое время. Думал cas@ сам озвучит, он ещё на неделе предложил сделать раздельную сборку через %ifarch пока и дальше спокойно разбираться с clang/i586.
(В ответ на комментарий №25) > А собирать под x86_64 clang, а под i586 - gcc, насколько трудозатратно? Не-не-не. Такое я делать не буду. Это совершенно разный набор патчей и опций сборки. Поддерживать два разных инструментария это не вариант для меня. Я конечно понимаю, что в текущей конфигурации chromium очень близок к google chrome и это очень хочется сохранить, но всё-таки вам нужно выбрать между производительнотью и платформой, которая не поддерживается апстримом.
(В ответ на комментарий №27) > Я конечно понимаю, что в текущей конфигурации chromium очень близок к google > chrome и это очень хочется сохранить, но всё-таки вам нужно выбрать между > производительнотью и платформой, которая не поддерживается апстримом. А проблемной инструкции нет именно на i586 или на i686 тоже? (опять к тому, что вообще-то пентиумная оптимизация на 32-битных x86 сейчас едва ли не худший выбор)
(В ответ на комментарий №28) > А проблемной инструкции нет именно на i586 или на i686 тоже? Знать бы какой инструкции не хватает. > (опять к тому, что вообще-то пентиумная оптимизация на 32-битных x86 сейчас > едва ли не худший выбор) Тут ещё проблема, что firefox и chromium еле-еле влезают в адресное пространство при линковке на i586. Про debuginfo на этой платформе можно забыть. Насчёт оптимизации похожая история. Какие у тебя предложения? Не скрою, мне не хочется возвращаться на gcc т.к. c сlang6.0 сборка проходит намного быстрее и runtime получается быстрее (как тут уже было доказано).
Я не силен в вопросе, но патч предложил потому, что он может (как мне кажется) отключить проблемные инструкции, как временное решение.
(В ответ на комментарий №29) > Какие у тебя предложения? i686 (что наверняка довольно много мороки в сумме для уходящей платформы) или хотя бы -mtune=atom какой (но тут лучше погонять разные варианты). Впрочем, это уже не про chromium, а про репозиторий и отдельно...
(В ответ на комментарий №30) > Я не силен в вопросе, но патч предложил потому, что он может (как мне кажется) > отключить проблемные инструкции, как временное решение. Нет ничего более постоянного, чем временное. Указанный вами очень старый патч пытается отключить SSE2, который на этой платформе[1] поддерживается. Кроме того, хромиум с некоторых пор требует наличия SSE2 [2]. [1] https://bugzilla.altlinux.org/show_bug.cgi?id=34722#c1 [2] https://chromium.googlesource.com/chromium/src.git/+/3dd9f21718ea149dc06ad5a906a1d6dbe9f94dfd [3] https://bugs.chromium.org/p/chromium/issues/detail?id=348761
(В ответ на комментарий №31) > i686 (что наверняка довольно много мороки в сумме для уходящей платформы) > или хотя бы -mtune=atom какой (но тут лучше погонять разные варианты). > Впрочем, это уже не про chromium, а про репозиторий и отдельно... Ну я бы тоже предложил такое, но решать не мне. Обсудите это у себя там.
Created attachment 7480 [details] ApplyPolicySettings disassembly (В ответ на комментарий №29) > (В ответ на комментарий №28) > > А проблемной инструкции нет именно на i586 или на i686 тоже? > > Знать бы какой инструкции не хватает. Речь идёт об ассемблерной инструкции ud2, появившейся в Pentium Pro. Её задача -- спровоцировать SIGILL (undefined). Как указал выше Андрей Савченко, на x86 она используется для маркировки бага. Вполне возможно, код, генерируемый компилятором, выполняет проверки через макрос BUG() или что-то подобное, и вставляет эти инструкции. Ассемблерный вывод всей проблемной функции прилагаю. То есть инструкция ud2 совершенно легально появляется в коде. И скорее, вследствие смешивания отладочных и оптимизационных опций. В последнее время компиляторы чудят с таким смешиванием всё больше. Но возникает вопрос: почему так получилось? Из-за новой сборки (с переходом на новый clang) или в новой версии допущена ошибка апстримом (для сборки i586)? Судя по тому, что остановка в начале проблемной функции позволяет избежать воспроизводимости SIGILL в том же месте, вполне может быть и второй вариант.
(В ответ на комментарий №34) > Речь идёт об ассемблерной инструкции ud2, появившейся в Pentium Pro. Её задача > -- спровоцировать SIGILL (undefined). Я знаю, что это за интструкция, спасибо. > То есть инструкция ud2 совершенно легально появляется в коде. И скорее, > вследствие смешивания отладочных и оптимизационных опций. В последнее время > компиляторы чудят с таким смешиванием всё больше. Я не вижу в исходном коде[1] ничего крименального. [1] http://git.altlinux.org/people/legion/packages/chromium.git?p=chromium.git;a=blob;f=components/policy/core/browser/configuration_policy_handler_list.cc;h=1d0fe628f4b75f12438e5774643f6261e2a75860;hb=6579a750466e0633876a307259a9e8b7f628bfb8#l38 Мне пока кажется, что clang/lld могли, что-то переоптимизировать. В текущей сборке пакета был сделан упор на задействование оптимизации clang/lld. > Но возникает вопрос: почему так получилось? Из-за новой сборки (с переходом на > новый clang) или в новой версии допущена ошибка апстримом (для сборки i586)? Апстримом чего ? > Судя по тому, что остановка в начале проблемной функции позволяет избежать > воспроизводимости SIGILL в том же месте, вполне может быть и второй вариант. Да, но если это баг в 32 битной сборке chromium, то оно и дальше не должно работать. Кроме того, такая же проблема должна вылезать у всех дистров, а я не вижу ничего такого у fedora (gcc), gentoo (clang), archlinux (clang).
(В ответ на комментарий №34) > Судя по тому, что остановка в начале проблемной функции позволяет избежать > воспроизводимости SIGILL в том же месте, вполне может быть и второй вариант. Ну и чтобы проверить действительно ли эта бага зависит от компилятора, я сейчас прохожу через адский гемор сборки gcc'ой. В этом проекте нельзя просто взять и переключить компилятор ))
(В ответ на комментарий №13) > (In reply to comment #12) > > Выкладываю дополнительную информацию по просьбе Глеба... > > => 0x02807dee <+686>: ud2 > > Какой интересный компилятор. Глеб, а ты это видел? https://github.com/rust-lang/rfcs/issues/1454 До чего борьба с напастью года доводит! :) Вот только почему такие "подсказки оптимизатору о недостижимости кода" в нашем случае работают с точностью до наоборот?.. (В ответ на комментарий №35) > Апстримом чего ? // Copyright (c) 2012 The Chromium Authors. All rights reserved. Не компилятора, конечно. (В ответ на комментарий №36) > Ну и чтобы проверить действительно ли эта бага зависит от компилятора, я сейчас > прохожу через адский гемор сборки gcc'ой. В этом проекте нельзя просто взять и > переключить компилятор )) Везёт! :) Мне даже не удалось репу склонировать, нигде места свободного нет...
(In reply to comment #23) > (В ответ на комментарий №20) > > Это не компилятор. На x86 так обычно реализуют макрос BUG(): > > Кстати, на целевой платформе действительно CONFIG_DEBUG_BUGVERBOSE=y, если это > желательно учитывать. А при сборке там оно же по идее должно быть? Попробуй выключить (=n). > > Я бы сделал gdb record, а затем отмотал назад на несколько шагов, чтоб > > посмотреть, что его вызвало. > > Тут выше уже выкладывал и короткий, и полный backtrace, но я так не очень > понял, надо record btrace pt или bts? Может хватит кода функции (asm) + все > данные в стеке, с чем оно там оказывается? record и bt — это разные вещи. В данном случае сам по себе ud2 не является ошибкой. Ошибка в том, что каким-то образом ветвь исполнения до него дошла. bt тебе только стек даёт, record позволяет тебе исполнить программу в обратном направлении (reverse-step, reverse-continue и т.д.) и посмотреть, что привело к такой ветви кода. Это может быть как проблема в коде, так и проблема в компиляторе; сейчас сложно сказать.
(In reply to comment #35) > > Судя по тому, что остановка в начале проблемной функции позволяет избежать > > воспроизводимости SIGILL в том же месте, вполне может быть и второй вариант. > > Да, но если это баг в 32 битной сборке chromium, то оно и дальше не должно > работать. Кроме того, такая же проблема должна вылезать у всех дистров, а я не > вижу ничего такого у fedora (gcc), gentoo (clang), archlinux (clang). Подтверждаю, что в Gentoo проблем с ud2 нет. Есть много других, например, нехватка памяти при линковке, потому что 3GB для этого жирного монстра впритык. Впринципе, можно собрать ядро с 3.5/0.5 GB memory split, но это уже уход от ванильки и всё равно может не хватить.
(В ответ на комментарий №39) > Подтверждаю, что в Gentoo проблем с ud2 нет. А можете подтвердить, что собрано именно clang ? > Есть много других, например, > нехватка памяти при линковке, потому что 3GB для этого жирного монстра впритык. > Впринципе, можно собрать ядро с 3.5/0.5 GB memory split, но это уже уход от > ванильки и всё равно может не хватить. Для lto нужно ещё больше памяти ))
> Кроме того, такая же проблема должна вылезать у всех дистров, а я не вижу ничего такого у fedora (gcc), gentoo (clang), archlinux (clang). Arch уже давно отключили x86_32, в остальных clang 5.0, а не 6.0 https://packages.gentoo.org/packages/sys-devel/clang (желтый - это нестабильный бранч) В Ubuntu 18.04 clang 6.0, сейчас пытаюсь запустить 18.04 daily build i386 и проверить Chromium 65, который там собирается clang; уже clang 6.0, на момент сборки Chromium мог быть 5.0, но, скорее всего, 6.0 все же Патч disable sse2 взят из Chromium 65 из Ubuntu 18.04, он актуален, хромиум там собирается с ним. Запустил пересборку Chromium, чтобы был точно clang 6.0: https://launchpad.net/~mikhailnov/+archive/ubuntu/chromium/+build/14517838
(In reply to comment #40) > (В ответ на комментарий №39) > > Подтверждаю, что в Gentoo проблем с ud2 нет. > > А можете подтвердить, что собрано именно clang ? У меня лично — нет. На имеющейся 32-битной машине 2GB RAM и увеличить нельзя, даже с zswap всё слишком грустно. chromium team делает регулярные проверочные сборки.
(In reply to comment #41) > > Кроме того, такая же проблема должна вылезать у всех дистров, а я не > вижу ничего такого у fedora (gcc), gentoo (clang), archlinux (clang). > Arch уже давно отключили x86_32, в остальных clang 5.0, а не 6.0 > https://packages.gentoo.org/packages/sys-devel/clang (желтый - это нестабильный > бранч) Нестабильный в терминах Gentoo это примерно как Sisyphus в терминах Альт: на нём обычно тестируются все пакеты перед коммитом в дерево и его использует большинство разработчиков. Другой вопрос в том, что число пользователей x86 уменьшается, соответственно, неизбежно падает качество архитектуры.
(В ответ на комментарий №42) > > А можете подтвердить, что собрано именно clang ? > > У меня лично — нет. Тогда это не так интересно, хоть и говорит кое о чём. > chromium team делает регулярные проверочные сборки. Это не показатель. В сизифе chromium сейчас тоже собирается под 32 бита, но вот только не работает. Кстати, я заметил, что в gentoo не используют lld даже в случае сборки clang[1]. В убунте тоже собирают clang'ом без него [2]. [1] https://bugs.gentoo.org/641556 [2] https://launchpad.net/~mikhailnov/+archive/ubuntu/chromium/+packages
Да, я посмотрел патчи Gentoo для chromium-65.0.3325.146. Есть три штуки части clang: https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/files/chromium-clang-r2.patch https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/files/chromium-clang-r3.patch https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/files/chromium-ffmpeg-r1.patch clang-r2 патч можт быть полезен для данной проблемы, т.к. он убирает игры с debug info, а наши проблемы вылезли как раз на CONFIG_DEBUG_BUGVERBOSE. Для актуальной версии 67.0.3377.1 патчи тоже актуальны кроме clang-r3.
(In reply to comment #44) > > chromium team делает регулярные проверочные сборки. > > Это не показатель. В сизифе chromium сейчас тоже собирается под 32 бита, но вот > только не работает. Показатель, т.к. сборки делаются разработчиками самостоятельно и обычно проверяется, что приложение запускается и работает. Это не всегда так, но чаще всего. > Кстати, я заметил, что в gentoo не используют lld даже в случае сборки > clang[1]. В убунте тоже собирают clang'ом без него [2]. Да, lld выключен. > [1] https://bugs.gentoo.org/641556 Обратите внимание, что myconf_gn+=" use_lld=false" мало. Нужен ещё https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/files/chromium-ffmpeg-clang.patch Т.к. там lld руками забит.
Created attachment 7481 [details] ubuntu 18.04 (clang) - chromium 65 works
(В ответ на комментарий №45) > Да, я посмотрел патчи Gentoo для chromium-65.0.3325.146. Есть три штуки части > clang: > > https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/files/chromium-clang-r2.patch > https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/files/chromium-clang-r3.patch > https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/files/chromium-ffmpeg-r1.patch > > clang-r2 патч можт быть полезен для данной проблемы, т.к. он убирает игры с > debug info, а наши проблемы вылезли как раз на CONFIG_DEBUG_BUGVERBOSE. > > Для актуальной версии 67.0.3377.1 патчи тоже актуальны кроме clang-r3. Я видел эти патчи, но не придал им значения т.к. я собираю без debuginfo на всех уровнях. Хотя, теперь после молока можно подуть на воду. (В ответ на комментарий №46) > Показатель, т.к. сборки делаются разработчиками самостоятельно и обычно > проверяется, что приложение запускается и работает. Это не всегда так, но чаще > всего. Я вас не понял в прошлый раз. > Обратите внимание, что > myconf_gn+=" use_lld=false" > мало. Нужен ещё > https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/files/chromium-ffmpeg-clang.patch > Т.к. там lld руками забит. Да, я знаю. Это актуально тем, кто собирает chromium с внутренним ffmpeg, а моя сборка использует системный.
Возможно, апстрим не в курсе конкретно этой ситуации на i586 ввиду отличий в сборке, но что точно, прямо в те же дни с чем-то похожим и они воюют, например: [1] https://bugs.chromium.org/p/chromium/issues/detail?id=824548 [2] https://bugs.chromium.org/p/chromium/issues/detail?id=822820 Там ещё много чего по ud2 находится...
Так. Мне тут подсказывают, что моя сборка chromium c gcc работает на i586.
Виновник найден. В 65.0.3325.181-alt1 должно быть исправлено.
(In reply to comment #51) > Виновник найден. В 65.0.3325.181-alt1 должно быть исправлено. Так поведайте сообществу, кто виновник, в чём была проблема. В git log ничего не сказано по этому поводу, в %changelog тоже. Анализ изменений показывает, что это может быть 0020-ALT-allow-_FORTIFY_SOURCE-for-clang.patch как единственный новый патч. Вообще, такие проблемы следует отражать в логе.
(В ответ на комментарий №52) > Так поведайте сообществу, кто виновник, в чём была проблема. В git log ничего > не сказано по этому поводу, в %changelog тоже. Анализ изменений показывает, что > это может быть 0020-ALT-allow-_FORTIFY_SOURCE-for-clang.patch как единственный > новый патч. Так дело не в патча, не в коде, не в sse2. Это был ложный путь изначально. Во всех дистрибутивах разный набор часто уникальных патчей. Те что не уникальны относятся к багам в коде (типа пропущенных хэдеров). Но сборка под ubuntu дала подсказку. Сборки под gentoo и под ubuntu используют use_clang=true, но в нашей же сборке используется больше оптимизаций. У меня задействовано: clang+lld+lto+cfi. Я попробовал сначала проверить код и пересобрал всё с gcc. Эта сборка работает. Сборка только clang, тоже работает. Значит дело не в нём, а в оптимизации. Виновником оказался CFI. Compile with Control Flow Integrity to protect virtual calls and casts. See http://clang.llvm.org/docs/ControlFlowIntegrity.html > Вообще, такие проблемы следует отражать в логе. Эм ... Следует ? Как я должен это воспринимать ?
Я конечно дилетант в этом деле пока, но проделанная работа над самым большим и долго собирающимся пакетом проделана колоссальная и, на мой взгляд, высоко профессионально! Ждём пакета в следующих регулярках... (In reply to comment #53) > Виновником оказался CFI. Похоже что в #49 [2] оно же!
(In reply to comment #53) > Так дело не в патча, не в коде, не в sse2. Это был ложный путь изначально. Во > всех дистрибутивах разный набор часто уникальных патчей. Те что не уникальны > относятся к багам в коде (типа пропущенных хэдеров). Но сборка под ubuntu дала > подсказку. Сборки под gentoo и под ubuntu используют use_clang=true, но в нашей > же сборке используется больше оптимизаций. > > У меня задействовано: clang+lld+lto+cfi. > > Я попробовал сначала проверить код и пересобрал всё с gcc. Эта сборка работает. > Сборка только clang, тоже работает. Значит дело не в нём, а в оптимизации. > > Виновником оказался CFI. Вот, спасибо. Вы сообщили о проблеме в chromium и/или clang? > Compile with Control Flow Integrity to protect virtual calls and casts. See > http://clang.llvm.org/docs/ControlFlowIntegrity.html > > > Вообще, такие проблемы следует отражать в логе. > > Эм ... Следует ? Как я должен это воспринимать ? Как то, что расписанные выше детали следует помещать в git лог коммита, который их вносит. Я посмотрел коммит 5fd713914c1af9359986ffb21ea59702f4e24780 в Вашем репозитории chromium и этой информации там не было. Это важная информация и она не должна быть потеряна. Тем более, что подобные проблемы могут выстрелить в других пакетах.
(В ответ на комментарий №55) > > Виновником оказался CFI. > Вот, спасибо. Вы сообщили о проблеме в chromium и/или clang? Порой бываю благодарен, когда кто-нить ещё берётся помочь (например, работой с апстримом), а не требовать предельной полноты от меня... > > > Вообще, такие проблемы следует отражать в логе. > > Эм ... Следует ? Как я должен это воспринимать ? Как пожелание, очевидно. > Как то, что расписанные выше детали следует помещать в git лог коммита, > который их вносит. Тут скорее другой момент: в однострочном сообщении _можно_ просуммировать, что было _сделано_ -- но _по возможности_ в многострочном сообщении коммита стоит писать, _зачем_ или _почему_ было сделано: контекст и впрямь теряется со временем. Если есть ссылка на багу (неважно, на каком языке) -- стараюсь и её добавить туда же. Но не мне учить legion@ оформлять патчи.
(В ответ на комментарий №53) > Виновником оказался CFI. > Compile with Control Flow Integrity to protect virtual calls and casts. > See http://clang.llvm.org/docs/ControlFlowIntegrity.html (ещё потормозив) Если правильно понимаю, на x86_64 его хорошо бы при этом включать -- пущай работает.
(В ответ на комментарий №54) > Похоже что в #49 [2] оно же! В хромиуме сделано вот так и это правильно: is_cfi = target_os == "linux" && !is_chromeos && target_cpu == "x64" && is_official_build Если у них он влючен везде, то да, он будет ломать. (В ответ на комментарий №55) > Вот, спасибо. Вы сообщили о проблеме в chromium и/или clang? Мантейнер clang извещён. Я считаю этого достаточно. > > Как то, что расписанные выше детали следует помещать в git лог коммита, > > который их вносит. > Тут скорее другой момент: в однострочном сообщении _можно_ просуммировать, > что было _сделано_ -- но _по возможности_ в многострочном сообщении коммита > стоит писать, _зачем_ или _почему_ было сделано: контекст и впрямь теряется > со временем. Если есть ссылка на багу (неважно, на каком языке) -- стараюсь > и её добавить туда же. Вот хочется ответить сразу и всем (постараюсь не очень грубо): То что сейчас пытается добраться до сизифа это промежуточная сборка, которую тестировал Глеб (спасибо ему кстати). Как только выяснилось, что это правильная сборка то я сразу отправил его так как пользователи не могут пользоваться хромиумом (это blocker). С другой стороны, сборка в сборочнице этого пакета занимает около 6 часов. Простите, но взвесив за и против я не стал пересобирать его лишний раз ради строчки в логе. > Как то, что расписанные выше детали следует помещать в git лог коммита, который > их вносит. Ну-ка наброшу. А я вот так не считаю. > Это важная информация и она не должна быть потеряна. > Тем более, что подобные проблемы могут выстрелить в других пакетах. Очень жаль если там мантейнеры будут влючать механизмы о которых не знают. Как я :)
Константин сейчас не онлайн, но вот от него дополнительная информация: Konstantin: https://github.com/0xcl/clang-cfi-bypass-techniques этот cfi там неспроста ) может, поэтому они и забили на i386 Konstantin: https://bugs.llvm.org/show_bug.cgi?id=35431 похоже это наше
