Bug 37211

(В ответ на комментарий №0)

С пустым профилем тоже падает?

(В ответ на комментарий №1)
> (В ответ на комментарий №0)
> 
> С пустым профилем тоже падает?

Да, падает.

Снёс ~/.mozilla/seamonkey

После неудачного старта файлы в каталогах:
$ ls ~/.mozilla/seamonkey/
5x11frvd.default  profiles.ini

$ ls ~/.mozilla/seamonkey/5x11frvd.default/
compatibility.ini  times.json

Здесь пишут, что это воспроизводится при сборке gcc-6 c флагами по умолчанию:

https://bugzilla.mozilla.org/show_bug.cgi?id=1337263:

> - It doesn't happen with GCC 5 with default build flags.
> - It happens with GCC 6 with default build flags
> - It doesn't happen with GCC 6 with MOZ_OPTIMIZE_FLAGS="-O3 -fno-schedule-insns" in js/src/old-configure.in

Created attachment 8467 [details]
Фикс падения на armh

Created attachment 8468 [details]
seamonkey.spec

1. Делаю пересборку в текущем окружении p9 (gcc8, флаги по умолчанию) - через минуту-две всё-равно падает, но уже не пишет, где именно.

2. Пытаюсь запилить патч с исправленными параметрами, но с ним сборка ломается вот с таким сообщением:

make[2]: Entering directory '/usr/src/RPM/BUILD/seamonkey-2.49.4/objdir'
STOP!  /usr/src/RPM/BUILD/seamonkey-2.49.4/mozilla/old-configure.in has changed, and your configure is out of date.
Please rerun autoconf and re-configure your build directory.

Куда ещё копнуть, понять не могу.

p.s. патч и спек приложил.

(In reply to comment #6)
> 1. Делаю пересборку в текущем окружении p9 (gcc8, флаги по умолчанию) - через
> минуту-две всё-равно падает, но уже не пишет, где именно.

Не на выполнении JS? #37449
>
> 2. Пытаюсь запилить патч с исправленными параметрами, но с ним сборка ломается
> вот с таким сообщением:
> 
> make[2]: Entering directory '/usr/src/RPM/BUILD/seamonkey-2.49.4/objdir'
> STOP!  /usr/src/RPM/BUILD/seamonkey-2.49.4/mozilla/old-configure.in has
> changed, and your configure is out of date.
> Please rerun autoconf and re-configure your build directory.

Запуск autoconf в .spec есть, он что-то пишет?

P.S.

(In reply to comment #7)
> (In reply to comment #6)
> Запуск autoconf в .spec есть, он что-то пишет?

У меня mozilla/old-configure автоматически перегенеряется из перезаписанного mozilla/old-configure.in самим make -f client.mk build.
Специально вставлять autoconf не надо.

(В ответ на комментарий №7)
> (In reply to comment #6)
> > 1. Делаю пересборку в текущем окружении p9 (gcc8, флаги по умолчанию) - через
> > минуту-две всё-равно падает, но уже не пишет, где именно.
> 
> Не на выполнении JS? #37449

Похоже да. По крайней мере на тесте для воспроизведения бага он падает. 
Пересобрал с использованием gcc4.9, работает чуть дольше, но в итоге падает. Тест также не проходит.
А когда подоспеет обновлённая версия?

(In reply to comment #9)
> (В ответ на комментарий №7)
> > (In reply to comment #6)
> > > 1. Делаю пересборку в текущем окружении p9 (gcc8, флаги по умолчанию) - через
> > > минуту-две всё-равно падает, но уже не пишет, где именно.
> > 
> > Не на выполнении JS? #37449
> 
> Похоже да. По крайней мере на тесте для воспроизведения бага он падает. 
> Пересобрал с использованием gcc4.9, работает чуть дольше, но в итоге падает.
> Тест также не проходит.

С js-ProxyObject-New-null-pointer.patch из #37499 тоже падает?
https://bugzilla.altlinux.org/attachment.cgi?id=8442:

--- mozilla/js/src/vm/ProxyObject.cpp   2019-11-15 11:11:26.000515546 +0100
+++ mozilla/js/src/vm/ProxyObject.cpp   2019-11-15 11:13:20.623414171 +0100
@@ -47,7 +47,7 @@
     if (options.singleton()) {
         MOZ_ASSERT(priv.isGCThing() && priv.toGCThing()->isTenured());
         newKind = SingletonObject;
-    } else if ((priv.isGCThing() && priv.toGCThing()->isTenured()) ||
+    } else if ((priv.isGCThing() && (priv.toGCThing() && priv.toGCThing()->isTenured())) || // <- FIXME: is priv.toGCThing() == 0 ever expected when we get here?
                !handler->canNurseryAllocate() ||
                !handler->finalizeInBackground(priv))
     {

> А когда подоспеет обновлённая версия?

На http://www.seamonkey-project.org/ 2.49.5 пока последняя, тоже на базе Firefox/52 (сборка gcc-8/9 на x86_64 обсуждалась в https://bugzilla.altlinux.org/show_bug.cgi?id=37449)

(В ответ на комментарий №10)
> 
> С js-ProxyObject-New-null-pointer.patch из #37499 тоже падает?
> https://bugzilla.altlinux.org/attachment.cgi?id=8442:
Да, на тестовом примере падает. Добавил только этот патч + сборка gcc4.9.
Похоже пора разворачивать систему с debuginfo :)

> > А когда подоспеет обновлённая версия?
> 
> На http://www.seamonkey-project.org/ 2.49.5 пока последняя, тоже на базе
> Firefox/52 (сборка gcc-8/9 на x86_64 обсуждалась в
> https://bugzilla.altlinux.org/show_bug.cgi?id=37449)

Я не написал в начале... Экспериментирую с версией 2.49.4-alt1 - последняя, доступная на packages.altlinux.org. Под новой как раз подразумевал 2.49.5.

(In reply to comment #11)
>... Под новой как раз подразумевал 2.49.5.

С патчами из #37449 (https://bugzilla.altlinux.org/attachment.cgi?id=8442)
2.49.5 собирается gcc-8/9 под p9/sisyphus x86_64 и работает у меня без видимых ошибок. 

Имеет смысл собрать 2.49.5 под arm с debuginfo и искать похожий backtrace на https://crash-stats.mozilla.com/

Если есть инструкция, как запустить p9/arm в qemu, могу очень небыстро посмотреть тоже.

(В ответ на комментарий №12)
> (In reply to comment #11)
> >... Под новой как раз подразумевал 2.49.5.
> 
> С патчами из #37449 (https://bugzilla.altlinux.org/attachment.cgi?id=8442)
> 2.49.5 собирается gcc-8/9 под p9/sisyphus x86_64 и работает у меня без видимых
> ошибок. 
> 
> Имеет смысл собрать 2.49.5 под arm с debuginfo и искать похожий backtrace на
> https://crash-stats.mozilla.com/
Ок, для начала тогда стяну исходники с сайта и попробую собрать, а там видно будет.

> Если есть инструкция, как запустить p9/arm в qemu, могу очень небыстро
> посмотреть тоже.
Вроде где-то есть... У меня asus C201 на rk3288, на нём и балуюсь.

Однако 2.49.5 запускается, но падает на тесте из #37449, как и предыдущая сборка.
При случае копну поглубже...

(In reply to comment #14)
> Однако 2.49.5 запускается, но падает на тесте из #37449, как и предыдущая сборка.

А если патч из #c10 приложить?

(В ответ на комментарий №15)
> (In reply to comment #14)
> > Однако 2.49.5 запускается, но падает на тесте из #37449, как и предыдущая сборка.
> 
> А если патч из #c10 приложить?

Я взял спек и патчи из #37449. Только чтобы избавится от "your configure is out of date." добавил "rm -f mozilla/configure" перед вызовом configure.

(In reply to comment #16)

debuginfo?

(В ответ на комментарий №17)
> (In reply to comment #16)
> 
> debuginfo?

Там по зависимостям для половины системных либ debuginfo надо ставить, а тут пока с местом проблемы...

Добрался до debuginfo, но тут вскрылась какая-то другая проблема, как будто в gdb:

......
[New LWP 28195]
[New LWP 28174]
Reading symbols from /usr/lib/seamonkey/seamonkey-bin...
Reading symbols from /usr/lib/debug/usr/lib/seamonkey/seamonkey-bin.debug...
../../gdb/dwarf2read.c:6263:29: runtime error: reference binding to misaligned address 0x0020e599 for type '<unknown>', which requires 2 byte alignment
0x0020e599: note: pointer points here
......

(In reply to comment #19)
> Reading symbols from /usr/lib/debug/usr/lib/seamonkey/seamonkey-bin.debug...
> ../../gdb/dwarf2read.c:6263:29: runtime error: reference binding to misaligned
> address 0x0020e599 for type '<unknown>', which requires 2 byte alignment
> 0x0020e599: note: pointer points here
> ......

Проще оставить до выхода 2.53.1, обещают  beta 1 к 2019-12-24: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1600521

Created attachment 8501 [details]
backtrace.txt

После обновления gdb до 8.3 удалось снять backtrace:

Thread 12 "JS Helper" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xac9f9440 (LWP 10928)]
0xb5cab668 in js::jit::MacroAssemblerARM::ma_mov(js::jit::ImmGCPtr, js::jit::Register) ()
   from /usr/lib/seamonkey/libxul.so

(В ответ на комментарий №21)
> 
> 0xb5cab668 in js::jit::MacroAssemblerARM::ma_mov(js::jit::ImmGCPtr,
> js::jit::Register) ()
>    from /usr/lib/seamonkey/libxul.so

ARM-специфическое. Кстати, обещанного под Xmas 2.53.1 таки еще нет.

Пакет seamonkey не собран под архитектуру armh

Проверил на x86_64 - ошибка не воспроизводится