[Bug 228855] www/firefox: crashes on certain sites

2024-02-07 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228855

Mark Linimon  changed:

   What|Removed |Added

 Status|Open|Closed
 Resolution|--- |Overcome By Events

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2024-01-26 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #28 from Nuno Teixeira  ---
(In reply to Jesper Schmitz Mouridsen from comment #27)

Running firefox for 3 days without any kind of issues.
Thanks for awesome work!

Really curious about upstream feedback :)

Cheers

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2024-01-25 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #27 from Jesper Schmitz Mouridsen  ---
https://bugzilla.mozilla.org/show_bug.cgi?id=1876632 upstream bug

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2024-01-25 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #26 from Jesper Schmitz Mouridsen  ---
(In reply to Jesper Schmitz Mouridsen from comment #25)
Ok the difference in my understanding between arm64 and arm64/aarch64 on AMD64
the address pointer is always a valid firefoz jit region i.e 47th bit and above
are never set. This is not true for arm64 so MapAlignedPagesRandom returns null
when the last attempts are not in a validRange. Furthermore I cannot confirm
that linuxes randomizes mmap'ed virtual addresses, so TryToAlignChunk works
better there.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2024-01-22 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

Jesper Schmitz Mouridsen  changed:

   What|Removed |Added

 Attachment #247827|0   |1
is obsolete||

--- Comment #25 from Jesper Schmitz Mouridsen  ---
Created attachment 247860
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247860=edit
use MAP_ALIGNED instead of relocating

I still cannot find the difference between amd64 and arm64, but TryToAlignChunk
very often fails on both platforms apparently because aslr randomizes the
requested aligned addresses in a way so they are no longer aligned as desired,
so my idea is to use MAP_ALIGNED instead of trying to relocate. Thoughts?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2024-01-22 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #24 from Jesper Schmitz Mouridsen  ---
(In reply to Nuno Teixeira from comment #23)
Perfectly right I was hoping for a quick upstream commit..

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2024-01-22 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #23 from Nuno Teixeira  ---
(In reply to Jesper Schmitz Mouridsen from comment #22)

While jit patch isn't included upstream, we need to apply:

https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247827

+

patch-js_src_jit_arm64_vixl_MozCpu-vixl.cpp

--- js/src/jit/arm64/vixl/MozCpu-vixl.cpp.orig  2023-12-11 20:42:06 UTC
+++ js/src/jit/arm64/vixl/MozCpu-vixl.cpp

-#elif defined(__aarch64__) && (defined(__linux__) || defined(__android__))
+#elif defined(__aarch64__) && (defined(__linux__) || defined(__android__)||
defined(__FreeBSD__))

Right?

Cheers

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2024-01-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

Jesper Schmitz Mouridsen  changed:

   What|Removed |Added

 Attachment #247141|maintainer-approval?(gecko@ |
  Flags|FreeBSD.org)|
 Attachment #247141|0   |1
is obsolete||

--- Comment #22 from Jesper Schmitz Mouridsen  ---
Created attachment 247827
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247827=edit
align mmap

>From https://reviews.freebsd.org/rS343964 I concluded that MAP_FIXED simply
turns of randomization(?) with aslr enabled. 

With aslr enabled without the MAP_FIXED hack not all pages were aligned causing
calls to TryToAlignChunk which somehow causes failures. I cannot yet explain
why TryToAlignChunk fails. It did not seem to ever get called with aslr
disabled. Thus a second hackish attempt to fix running with aslr enabled on
aarch64, is attached, which tries to ensure alignment to the desired alignment,
if I did not misread the mmap man page. I marked the other attachment obsolete
because the jit part hopefully gets accepted by upstream.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-29 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #21 from Nuno Teixeira  ---
(In reply to Jesper Schmitz Mouridsen from comment #20)
Nice!

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-26 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #20 from Jesper Schmitz Mouridsen  ---
(In reply to Jesper Schmitz Mouridsen from comment #19)
upstream bug is here for the jit part
https://bugzilla.mozilla.org/show_bug.cgi?id=1871969

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-22 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #19 from Jesper Schmitz Mouridsen  ---
(In reply to Nuno Teixeira from comment #18)
the MAP_FIXED needs some testing and thoughts, the other one only applies to
aarch64 already..

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #18 from Nuno Teixeira  ---
Sugestion of adding uploaded patches
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247141 as EXTRA_PATCHES
only for aarch64 ARCH and bump PORTREVISION.

This way we prevent any side effects on other archs that do not match aarch64.

Any thoughts?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-19 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #17 from Nuno Teixeira  ---
(In reply to Nuno Teixeira from comment #16)
(...)

aslr on :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-19 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #16 from Nuno Teixeira  ---
(In reply to Jesper Schmitz Mouridsen from comment #15)

Excellent news!

- wirple.com (webgl benchmarking): OK
- mail.google.com: OK
- facebook.com: OK
- youtube.com: OK
- freebsd.org: OK
- sync (accounts.firefox.com): passwords and bookmarks: OK

- Very fast. Have the impression that have faster response compared to
qutebrowser and chromium.
- Ram: OK
- cpu: OK

I can run more tests if needed.

Very happy!
Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

maintainer-approval requested: [Bug 271081] www/firefox: crashes on arm64 with ASLR enabled : [Attachment 247141] allows running with aslr and fixes jit..

2023-12-18 Thread bugzilla-noreply 
Jesper Schmitz Mouridsen  has asked freebsd-gecko (Nobody)
 for maintainer-approval:
Bug 271081: www/firefox: crashes on arm64 with ASLR enabled
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

Attachment 247141: allows running with aslr and fixes jit..
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247141=edit



--- Comment #15 from Jesper Schmitz Mouridsen  ---
Created attachment 247141
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247141=edit
allows running with aslr and fixes jit..

The memory part MAP_FIXED is to avoid (desired != region) (do not know how that
relates to aslr but with this it runs with aslr), the jit code has to do some
cache sync in order to execute the wirte+exec pages, it was guarded out, and
the problem was masked under w^x because mprotect also does some cache
syncing.. ,thanks Kyle Evans.
Hopefully someone will pick this up for a test. Do not forget bug #275247 Only
tested on aarch64 rpi4 and rk3399.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-18 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

Jesper Schmitz Mouridsen  changed:

   What|Removed |Added

 Attachment #247095|0   |1
is obsolete||
 Attachment #247100|0   |1
is obsolete||
 Attachment #247141||maintainer-approval?(gecko@
  Flags||FreeBSD.org)

--- Comment #15 from Jesper Schmitz Mouridsen  ---
Created attachment 247141
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247141=edit
allows running with aslr and fixes jit..

The memory part MAP_FIXED is to avoid (desired != region) (do not know how that
relates to aslr but with this it runs with aslr), the jit code has to do some
cache sync in order to execute the wirte+exec pages, it was guarded out, and
the problem was masked under w^x because mprotect also does some cache
syncing.. ,thanks Kyle Evans.
Hopefully someone will pick this up for a test. Do not forget bug #275247 Only
tested on aarch64 rpi4 and rk3399.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #14 from Jesper Schmitz Mouridsen  ---
diff -r d80eefe94738 js/src/jit/arm64/vixl/MozCpu-vixl.cpp
--- a/js/src/jit/arm64/vixl/MozCpu-vixl.cpp Tue Nov 28 21:01:37 2023 +
+++ b/js/src/jit/arm64/vixl/MozCpu-vixl.cpp Mon Dec 18 08:06:04 2023 +0100
@@ -110,7 +110,7 @@
   FlushInstructionCache(GetCurrentProcess(), address, length);
 #elif defined(XP_DARWIN)
   sys_icache_invalidate(address, length);
-#elif defined(__aarch64__) && (defined(__linux__) || defined(__android__))
+#elif defined(__aarch64__) && (defined(__linux__) || defined(__android__) ||
defined(__FreeBSD__))
   // Implement the cache synchronisation for all targets where AArch64 is the
   // host, even if we're building the simulator for an AAarch64 host. This
   // allows for cases where the user wants to simulate code as well as run it

This one works for me as a single patch (i.e all other attempts can be
disregarded) did only a sparse test on an incremental build but all cache
related code was guarded out. Still needs +noaslr.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

Kyle Evans  changed:

   What|Removed |Added

 CC||kev...@freebsd.org

--- Comment #13 from Kyle Evans  ---
The problem with these last reproducers seems to be insufficient barrier
between writes to the mapped page and executing code out of it; it seems like
it'd be unlikely for a project like firefox to get it wrong, but maybe they're
doing the same (or perhaps some other kind of caching)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #12 from Jesper Schmitz Mouridsen  ---
Further investegation:

allow_wx=1 (e.g not enforced might to misbehave)

https://gist.github.com/jsm222/38279218adf608b48985c174cedad014

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

Jesper Schmitz Mouridsen  changed:

   What|Removed |Added

 Attachment #247087|0   |1
is obsolete||

--- Comment #11 from Jesper Schmitz Mouridsen  ---
Created attachment 247100
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247100=edit
prentents always w^x something might be wrong with allow_wx ?

This runs both with kern.elf64.allow_wx=0 and kern.elf64.allow_wx=1. 
But unpatched is does not run with kern.elf64.allow_wx=1 (Which it should if i
do not mixup the values)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #10 from Jesper Schmitz Mouridsen  ---
(In reply to Nuno Teixeira from comment #9)
Try this one 

 /*
  * The original fdlibm code used statements like:
diff -r d80eefe94738 modules/libpref/init/StaticPrefList.yaml
--- a/modules/libpref/init/StaticPrefList.yaml  Tue Nov 28 21:01:37 2023 +
+++ b/modules/libpref/init/StaticPrefList.yaml  Sun Dec 17 14:50:57 2023 +0100
@@ -7662,7 +7662,7 @@
 # or executable but never both at the same time. OpenBSD defaults to W^X.
 - name: javascript.options.content_process_write_protect_code
   type: bool
-#if defined(XP_OPENBSD)
+#if defined(XP_OPENBSD) || defined(XP_FREEBSD)
   value: true
 #else
   value: false

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #9 from Nuno Teixeira  ---
Created attachment 247095
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247095=edit
prepared patch to use in www/firefox/files/

reverse applied patch prepared to use in www/firefox/files/

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #8 from Nuno Teixeira  ---
(In reply to Jesper Schmitz Mouridsen from comment #7)

Hello Jasper,

It seems that firefox 121 is already patched as I did tried apply uploaded
patch (reverse (or previouly applied) patch detected).

I will test 121.0,2 (11 Dec 2023) and share results.

Cheers

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-12-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #7 from Jesper Schmitz Mouridsen  ---
Created attachment 247087
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247087=edit
backouts breakage on aarch64 freebsd

Only for testing a better patch should be made.. Still run with nosalr

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-11-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #43 from Tomoaki AOKI  ---
(In reply to Ken DEGUCHI from comment #42)

Built with default llvm15 on poudriere jail and also running fine with -O3.
It should be the problem related with llvm13 or wasi-*13.

I'll see some more upgrades of firefox, and if there are no more crash (on me
or on some others) within the period, I'll close this PR.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-11-20 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #42 from Ken DEGUCHI  ---
(In reply to Ken DEGUCHI from comment #41)

I built firefox-120.0_2,2 with LLVM-16 since wasi now supports LLVM12 or later.
As a result, it is working fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-11-15 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

Jesper Schmitz Mouridsen  changed:

   What|Removed |Added

 CC||j...@freebsd.org

--- Comment #6 from Jesper Schmitz Mouridsen  ---
(In reply to Nuno Teixeira from comment #5)

lldb attached to tab proccess (use MOZ_DEBUG_CHILD_PROCESS=20) the number is
seconds..
output also in [1] 

 frame #0: 0x08a54e146010
->  0x8a54e146010: subsp, x28, #0x8
0x8a54e146014: strx30, [x28, #-0x8]!
0x8a54e146018: subsp, x28, #0x8
0x8a54e14601c: strx29, [x28, #-0x8]!
(lldb) bt
* thread #1, name = 'WebExtensions', stop reason = signal SIGILL: illegal trap
  * frame #0: 0x08a54e146010
frame #1: 0x08a54e1167a0
frame #2: 0x4a0b6db4 libxul.so`js::jit::MaybeEnterJit(JSContext*,
js::RunState&) + 576
frame #3: 0x49a0e4c4 libxul.so`js::RunScript(JSContext*,
js::RunState&) + 604
frame #4: 0x49a0e8e4
libxul.so`js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&,
js::MaybeConstruct, js::CallReason) + 1036
frame #5: 0x49a0ed80 libxul.so`js::Call(JSContext*,
JS::Handle, JS::Handle, js::AnyInvokeArgs const&,
JS::MutableHandle, js::CallReason) + 212
frame #6: 0x49a698a0 libxul.so`JS::Call(JSContext*,
JS::Handle, JS::Handle, JS::HandleValueArray const&,
JS::MutableHandle) + 236
frame #7: 0x46f8f254
libxul.so`mozilla::dom::MessageListener::ReceiveMessage(mozilla::dom::BindingCallContext&,
JS::Handle, mozilla::dom::ReceiveMessageArgument const&,
JS::MutableHandle, mozilla::ErrorResult&) + 788
frame #8: 0x4874d3fc
libxul.so`mozilla::dom::JSActor::CallReceiveMessage(JSContext*,
mozilla::dom::JSActorMessageMeta const&, JS::Handle,
JS::MutableHandle, mozilla::ErrorResult&) + 496
frame #9: 0x4874d688
libxul.so`mozilla::dom::JSActor::ReceiveMessage(JSContext*,
mozilla::dom::JSActorMessageMeta const&, JS::Handle,
mozilla::ErrorResult&) + 252
frame #10: 0x4874fb50
libxul.so`mozilla::dom::JSActorManager::ReceiveRawMessage(mozilla::dom::JSActorMessageMeta
const&, mozilla::Maybe&&,
mozilla::Maybe&&) + 704
frame #11: 0x48652e00
libxul.so`mozilla::dom::WindowGlobalChild::RecvRawMessage(mozilla::dom::JSActorMessageMeta
const&, mozilla::Maybe const&,
mozilla::Maybe const&) + 368
frame #12: 0x4873d910
libxul.so`mozilla::dom::PWindowGlobalChild::OnMessageReceived(IPC::Message
const&) + 4140
frame #13: 0x486bfaa0
libxul.so`mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&) +
700
frame #14: 0x464cdf50
libxul.so`mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*,
IPC::Message const&) + 200
frame #15: 0x464cd090
libxul.so`mozilla::ipc::MessageChannel::DispatchMessage(mozilla::ipc::ActorLifecycleProxy*,
mozilla::UniquePtr>) + 324
frame #16: 0x464cd408
libxul.so`mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::ActorLifecycleProxy*,
mozilla::ipc::MessageChannel::MessageTask&) + 264
frame #17: 0x464cd8fc
libxul.so`mozilla::ipc::MessageChannel::MessageTask::Run() + 148
frame #18: 0x45f607f4 libxul.so`mozilla::RunnableTask::Run() + 32
frame #19: 0x45f5dc14
libxul.so`mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock
const&) + 1600
frame #20: 0x45f5cc20
libxul.so`mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock
const&) + 52
frame #21: 0x45f5ced0
libxul.so`mozilla::TaskController::ProcessPendingMTTask(bool) + 80
frame #22: 0x45f62dc8
libxul.so`mozilla::detail::RunnableFunction::Run()
+ 24
frame #23: 0x45f7060c libxul.so`nsThread::ProcessNextEvent(bool,
bool*) + 968
frame #24: 0x45f74d2c libxul.so`NS_ProcessNextEvent(nsIThread*,
bool) + 92
frame #25: 0x464d092c
libxul.so`mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) + 232
frame #26: 0x464874d8 libxul.so`MessageLoop::Run() + 92
frame #27: 0x48ab4aa8 libxul.so`nsBaseAppShell::Run() + 48
frame #28: 0x49941c64 libxul.so`XRE_RunAppShell() + 100
frame #29: 0x464874d8 libxul.so`MessageLoop::Run() + 92
frame #30: 0x49941a20 libxul.so`XRE_InitChildProcess(int, char**,
XREChildData const*) + 1184
frame #31: 0x00132574 firefox-bin`main + 780
frame #32: 0x40500578 libc.so.7`__libc_start1(argc=22,
argv=0xe5d8, env=0xe690, cleanup=,
mainX=(firefox-bin`main)) at libc_start1.c:157:7
frame #33: 0x00132134 firefox-bin`_start at crt1_s.S:60

[1] https://gist.github.com/jsm222/e6199a03142f5716921c82c3d2f3ddc5

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-28 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #41 from Ken DEGUCHI  ---
(In reply to Tatsuki Makino from comment #40)

I tried the following,

/usr/bin/proccontrol -m aslr -s disable /usr/local/lib/firefox/firefox

However, firefox crashed the same. The error message was also the same.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-27 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #40 from Tatsuki Makino  ---
By the way, it seems that the issue of crashing due to ASLR is prevalent these
days.
It has been reported that this also occurs in firefox with arm64 (bug 271081).
There are examples where disabling ASLR is a workaround even for amd64 (bug
268318).
Does it relate to this?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-27 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

Tomoaki AOKI  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2747
   ||19

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-27 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

Tomoaki AOKI  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2745
   ||30

--- Comment #39 from Tomoaki AOKI  ---
(In reply to Ken DEGUCHI from comment #38)

And maybe Bug 274530, too.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-27 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #38 from Ken DEGUCHI  ---
I think this is the same bug #274719.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-20 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #37 from Tatsuki Makino  ---
Even though the graphics seem to be the cause, it is difficult to identify the
cause.
It may be due to over-optimization or CPU features enabled on other ports.

My /etc/make.conf has the following part.

.if\
!empty(.CURDIR:tA:M/usr/ports/graphics/mesa-dri) ||\
!empty(.CURDIR:tA:M/usr/ports/graphics/mesa-libs) ||\
0
.undef CPUTYPE
.endif

Although written in somewhat abbreviated form, some ports are prevented from
having -mach= added by this.

There may be origins that don't already exist, but in my environment, this
applies to graphics/dri, graphics/gbm, graphics/libEGL, graphics/libGL,
graphics/libglapi, graphics/libglesv2, graphics/libosmesa, graphics/mesa-dri
and graphics/mesa-libs.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #36 from Tomoaki AOKI  ---
firefox 119.0 is out, but unfortunately still crashes with SIGSEGV on built
with -O3 binary.
The binary built with -O0 using patch on Comment #32 runs fine but slow.
Note that the patch applies with offset -9 lines due to the commit ports
eb9f07125e7dba4ff8542632ee636970b272 to /usr/ports/Mk/bsd.gecko.mk, but
actually no problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-15 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #35 from Tomoaki AOKI  ---
(In reply to Tatsuki Makino from comment #34)

Found this [1] by Texas Instruments for their arm processors.
Not sure if it's generic enough that is applicable to llvm/clang13 on FreeBSD,
notably other than arm arch.

Oh...too excessibly many even for -O1. We should try narrowing down possibly
affected options to try. Firefox is too large to try every options. :-(

Maybe what is affecting this would be something related with alignment and/or
bounds of objects, including segments, structs, arrays and something more.

At least for me, the failure mode is SIGSEGV, usualy means out of bounds
accesses.

[1]
https://software-dl.ti.com/codegen/docs/tiarmclang/compiler_tools_user_guide/compiler_manual/using_compiler/compiler_options/optimization_options.html

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-10-14 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #5 from Nuno Teixeira  ---
(In reply to Nuno Teixeira from comment #4)
(...)

**proccontrol

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-10-14 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #4 from Nuno Teixeira  ---
(In reply to Graham Perrin from comment #3)

118.0.1 15.0-CURRENT: procconf -m aslr -s disable firefox

https://people.freebsd.org/~eduardo/logs/firefox/error-sync-1697099126473_118.0.1%2C2.txt

Never tried build firefox with aslr off, should it make any difference?

Thanks

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-09 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #34 from Tatsuki Makino  ---
(In reply to Ken DEGUCHI from comment #33)

If the problem is caused by -O0 to -O1, then the cause exists in the
optimization of -O1.
Since -O1 is a set of -ffoo, -fbar and -fhoge, if it can be identified that a
problem exists in -fhoge, it can be solved by using -fno-hoge.
Additionally, the scope of the code to be changed by such optimization can be
limited and found.
But, while there is a list of -ffoo enabled by -O1 for gcc, there does not seem
to be such a list for llvm+clang.
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-09 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #33 from Ken DEGUCHI  ---
(In reply to Tomoaki AOKI from comment #32)

Thank you very much. It worked out that way.

However, I don't know why firefox is terminating with different optimization
options.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-10-07 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #3 from Graham Perrin  ---
(In reply to Nuno Teixeira from comment #2)

Would a backtrace from a debug build help? 

(If you attempt a debug build, is result truly a debug build?
)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-06 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #32 from Tomoaki AOKI  ---
(In reply to Ken DEGUCHI from comment #30)

firefox 118.0.1 built with -O0 is running for me.

% pkg version -v | rg 'firefox'  
firefox-118.0.1_1,2=   up-to-date with index

For your info:
I've setting the option using the patch below. This seems not to be erroneously
overridden. It seems that -O0 is overridden on sub (child) make with other
method I've tried.
Not uploaded as usual, as this is not at all an ideal solution.
Note that I revert this as soon as the upgrade is finished and apply again on
next upgrade.


--- a/Mk/bsd.gecko.mk
+++ b/Mk/bsd.gecko.mk
@@ -213,7 +213,7 @@
 MOZ_EXPORT+=  
MOZ_GOOGLE_SAFEBROWSING_API_KEY=AIzaSyBsp9n41JLW8jCokwn7vhoaMejDFRd1mp8

 .if ${PORT_OPTIONS:MOPTIMIZED_CFLAGS}
-CFLAGS+=   -O3
+CFLAGS+=   -O0
 MOZ_EXPORT+=   MOZ_OPTIMIZE_FLAGS="${CFLAGS:M-O*}"
 MOZ_OPTIONS+=  --enable-optimize
 .else

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-10-04 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

--- Comment #2 from Nuno Teixeira  ---
Firefox 118.0.1 crashes with and without aslr.
Any clues?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-03 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #31 from Tomoaki AOKI  ---
(In reply to Ken DEGUCHI from comment #30)

Possibly.

I'm using Quadro P1000 with x11/nvidia-driver, and with internal GPU disabled
via UEFI firmware configuration. ThinkPad P52 with Core(TM) i7-8750H CPU,
nvidia Quadro P1000 dGPU and 4k panel.

HW probe is uploaded as below. (Old upload but exactly same HW, except external
ones connected via USB.)

http://bsd-hardware.info/?probe=676f16ac86

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-10-03 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #30 from Ken DEGUCHI  ---
On my environment, firefox 118.0.1 crashes even with the option "-O0".

I think it is a graphics related error. I am running an NVIDIA Geforce GTX 1650
with x11/nvidia-driver.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-25 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #29 from Tomoaki AOKI  ---
firefox 118.0 is out, but unfortunately, the situation does not change.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #28 from Tomoaki AOKI  ---
www/firefox 117.0.1 is out, so I've tested without luck except with -O0.
-O3 (default, with OPTIMIZED_CFLAGS enabled) crashes as before.
Unsetting CPUTYPE didn't help.
-O2 and -O1 are untested. So as disabling OPTIMIZED_CFLAGS.

  *Applied previous patch to Mkbsd.gecko.mk modifies -O3 for OPTIMIZED_CFLAGS
   to -O0.

The next steps could be to try using llvm15 in conjunchtion with proposed wasi
updates, but not yet successfully build with it.

And according to Bug 273766, any version before 117.0.1 has critical
vunlerability, so I've accepted the slowness and switched to 117.0.1 with -O0.
But it's certainly NOT ideal. It should work with -O3 sanely. So keep this
opened until actually resolved.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-12 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #27 from Tomoaki AOKI  ---
(In reply to Tomoaki AOKI from comment #26)

Finished building "-O1" pkg.
This crashes even with blank profile and cache. So only "-O0" works.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-12 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #26 from Tomoaki AOKI  ---
(In reply to Tatsuki Makino from comment #24)

Currently, confirmed that -O0 in CFLAGS fixed the crash even with working
profile and cache, but slow. It would be llvm13/clang13 problem with
optimization, which bites firefox 117 but not 116 and earlier.

I'll report back if -O1 works or not. Now building with -O1.


Some details:
First, I've tested clearling (actually, moved) cache. It is still under
~/.cache/mozilla/firefox. It didn't help even with blank profile.

As I'm not sure how I can force -O0, to surely pick within poudriere build,
added "CFLAGS+= -O0" line in www/firefox/Makefile, which failed because "-O0
-O3" in the commandline invoked by make. Maybe the latter "-O3" was used.

Next, turned OPTIMIZED_CFLAGS off, with reverting the above-mentioned change.
This binary crashes, maybe because actually "-O2" was used.

So I've turned OPTIMIZED_CFLAGS on again, and patched Mk/bsd.gecko.mk with the
patch below. With this, "-O2 -O0" was used.
This worked with blank profile and cache. So made both blank again and copied
working ones there, still works! But slow.

Now -O3 and -O2 are known to crash. So buiding with -O1, modifying the patch
below.
Looking into running poudriere build log, "-O2 -O1" is used.


--- a/Mk/bsd.gecko.mk
+++ b/Mk/bsd.gecko.mk
@@ -213,7 +213,7 @@
 MOZ_EXPORT+=  
MOZ_GOOGLE_SAFEBROWSING_API_KEY=AIzaSyBsp9n41JLW8jCokwn7vhoaMejDFRd1mp8

 .if ${PORT_OPTIONS:MOPTIMIZED_CFLAGS}
-CFLAGS+=   -O3
+CFLAGS+=   -O0
 MOZ_EXPORT+=   MOZ_OPTIMIZE_FLAGS="${CFLAGS:M-O*}"
 MOZ_OPTIONS+=  --enable-optimize
 .else

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #25 from Ken DEGUCHI  ---
I tried to make firefox with "-O0" set in CFLAGS. In this case, firefox does
not crash.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-10 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #24 from Tatsuki Makino  ---
(In reply to Tomoaki AOKI from comment #20)

It would seem that it is "failing normally (正常に失敗)".

If the surviving processes are using profiles, we should also consider using
killall firefox to terminate all processes.
In rare cases, a process may remain unreachable from the debugger. (e.g. It is
encountered by apache httpd.)

Off topic, but it seems to me that the profile evacuation needs to be done in
two places.
~/.mozilla/firefox and ~/.cache/mozilla/firefox
I don't know where ~/.cache is these days :) It gets lost because of
XDG_RUNTIME_DIR.

In this case, it is better to include -g in CFLAGS instead of using the DEBUG
option.
If make patch has already been run and make clean has not been run, lldb can
find the source.
For step execution and breakpoints to work properly, it is better if the
optimization is -O0.

Well, for some people, it may be easier to look directly at the source instead
of using the debugger, if the backtrace is successful in identifying where the
problem occurs :)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-10 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #23 from Tomoaki AOKI  ---
(In reply to Graham Perrin ◐ from comment #22)

Starting from obtaining 3rd backtrace uploaded, I always mv my working (for
116.*) ~/.mozilla/firefox to different directory name and create blank
~/.mozilla/firefox.
So nothing there initially.

Currently, the procedure to create uploaded backtrace files are as follows.
Copy & paste the command line and outputs to editors/leafpad window and save
it.

`pkg version -v | rg 'firefox'`
`lldb -o r -- /usr/local/bin/firefox --safe-mode`

Click "Open" button when prompted. Then, usually firefox 117 crashes within a
few seconds.
Cannot obtain backtrace as I already reported on Comment 19.
So quit from lldb and run lldb again as follows.

`lldb --core ~/firefox.core --file /usr/local/lib/firefox/firefox`
`bt all` to obtain backtrace and quit lldb.
>From terminal window, invoke `firefox --safe-mode &`.
Click "Open" button when prompted. Then, usually firefox 117 crashes within a
few seconds.


After those, new (maybe half-done) profile is generated.
I usually keep the latest one as ~/.mozilla/firefox-dummy and switch back mv'ed
working profile, deinstall firefox and forcibly install 116 using kept pkg.

With this in mind,

% grep -C 3 -i locked ~/.mozilla/firefox-dummy/profiles.ini

[Install4D4513703FF8A42E]
Default=7b1lfd0r.default-release
Locked=1

[Profile0]
Name=default-release
% cat ~/.mozilla/firefox-dummy/installs.ini
[4D4513703FF8A42E]
Default=7b1lfd0r.default-release
Locked=1

%

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-10 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

Graham Perrin ◐  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #22 from Graham Perrin ◐  ---
Without attempting to run Firefox: 

grep -C 3 -i locked ~/.mozilla/firefox/profiles.ini

cat ~/.mozilla/firefox/installs.ini

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-10 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #21 from Tomoaki AOKI  ---
As www/firefox was bumped because of lang/rust update, tried building
www/firefox with DEBUG option enabled, resulted in build faulure as below.
Building without DEBUG option was fine. But unfortunately, still crashes with
SIGSEGV.


/usr/local/bin/clang++13 -std=gnu++17 -o util.o -c 
-I/wrkdirs/usr/ports/www/firefox/work/.build/dist/stl_wrappers
-I/wrkdirs/usr/ports/www/firefox/work/.build/
dist/system_wrappers -include
/wrkdirs/usr/ports/www/firefox/work/firefox-117.0/config/gcc_hidden.h
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-stro
ng -fstack-clash-protection -ftrivial-auto-var-init=pattern -DDEBUG=1
-DANGLE_PLATFORM_EXPORT= -D__NDK_FPABI__= -DANGLE_SKIP_DXGI_1_2_CHECK
-DANGLE_ENABLE_KEYED
MUTEX -DANGLE_TRANSLATOR_ESSL_ONLY -DANGLE_DISABLE_POOL_ALLOC
-DANGLE_ENABLE_APPLE_WORKAROUNDS -DANGLE_ENABLE_ESSL -DANGLE_ENABLE_GLSL
-DANGLE_ENABLE_HLSL -DANG
LE_ENABLE_SHARE_CONTEXT_LOCK=1 -DANGLE_VMA_VERSION=2003000
'-DCR_CLANG_REVISION="llvmorg-16-init-6578-g0d30e92f-2"'
-DDYNAMIC_ANNOTATIONS_ENABLED=0 -DNOMINMAX -
DUNICODE -DWINVER=0x0A00 -D_ATL_NO_OPENGL -D_CRT_NONSTDC_NO_WARNINGS
-D_CRT_RAND_S -D_CRT_SECURE_NO_DEPRECATE -D_HAS_EXCEPTIONS=0
-D_SCL_SECURE_NO_DEPRECATE -D_
SECURE_ATL -D_UNICODE -D_WINSOCK_DEPRECATED_NO_WARNINGS
-I/wrkdirs/usr/ports/www/firefox/work/firefox-117.0/gfx/angle/targets/translator
-I/wrkdirs/usr/ports/ww
w/firefox/work/.build/gfx/angle/targets/translator
-I/wrkdirs/usr/ports/www/firefox/work/firefox-117.0/gfx/angle/checkout/include
-I/wrkdirs/usr/ports/www/firef
ox/work/firefox-117.0/gfx/angle/checkout/src
-I/wrkdirs/usr/ports/www/firefox/work/firefox-117.0/gfx/angle/checkout/src/common/third_party/base
-I/wrkdirs/usr/p
orts/www/firefox/work/.build/dist/include -I/usr/local/include/nspr
-I/usr/local/include -I/usr/local/include/nss -I/usr/local/include/nspr
-I/wrkdirs/usr/ports
/www/firefox/work/.build/dist/include/nss -I/usr/local/include
-I/usr/local/include/libpng16 -I/usr/local/include/pixman-1
-I/usr/local/include -DMOZILLA_CLIENT
 -include /wrkdirs/usr/ports/www/firefox/work/.build/mozilla-config.h
-DLIBICONV_PLUG -isystem /usr/local/include -fno-sized-deallocation
-fno-aligned-new -O2 -
pipe -march=haswell -O3 -DLIBICONV_PLUG -fstack-protector-strong -isystem
/usr/local/include -fno-strict-aliasing -DLIBICONV_PLUG -isystem
/usr/local/include -f
no-exceptions -fPIC -fno-rtti -fno-exceptions -fno-math-errno -pipe -gdwarf-4
-O2 -O3 -fno-omit-frame-pointer -funwind-tables -Wall
-Wbitfield-enum-conversion -
Wdeprecated-this-capture -Wempty-body -Wformat-type-confusion
-Wignored-qualifiers -Wpointer-arith -Wshadow-field-in-constructor-modified
-Wsign-compare -Wtauto
logical-constant-in-range-compare -Wtype-limits
-Wno-error=tautological-type-limit-compare -Wunreachable-code
-Wunreachable-code-return -Wunused-but-set-paramet
er -Wno-invalid-offsetof -Wclass-varargs -Wempty-init-stmt
-Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis
-Wno-range-loop-analysis -Wc++2a-
compat -Wenum-compare-conditional -Wenum-float-conversion -Wno-error=deprecated
-Wno-error=deprecated-anon-enum-enum-conversion
-Wno-error=deprecated-enum-enum-
conversion -Wno-error=deprecated-this-capture -Wcomma -Wimplicit-fallthrough
-Wstring-conversion -Wno-inline-new-delete -Wno-error=deprecated-declarations
-Wno-
error=array-bounds -Wno-error=free-nonheap-object -Wno-error=atomic-alignment
-Wformat -Wformat-security -Wno-psabi -Wthread-safety
-Wno-error=builtin-macro-red
efined -Wno-unknown-warning-option -Wno-final-dtor-non-final-class
-Wno-implicit-const-int-float-conversion -Wno-range-loop-construct
-I/usr/local/include -D_TH
READ_SAFE -msse2 -fno-strict-aliasing -ffp-contract=off  -MD -MP -MF
.deps/util.o.pp  
/wrkdirs/usr/ports/www/firefox/work/firefox-117.0/gfx/angle/checkout/src/
compiler/translator/util.cpp
clang-13: warning: argument unused during compilation:
'-fstack-clash-protection' [-Wunused-command-line-argument]
gmake[4]: Leaving directory
'/wrkdirs/usr/ports/www/firefox/work/.build/gfx/angle/targets/translator'
gmake[3]: Leaving directory '/wrkdirs/usr/ports/www/firefox/work/.build'
gmake[2]: ***
[/wrkdirs/usr/ports/www/firefox/work/firefox-117.0/config/recurse.mk:34:
compile] Error 2
gmake[2]: Leaving directory '/wrkdirs/usr/ports/www/firefox/work/.build'
gmake[1]: ***
[/wrkdirs/usr/ports/www/firefox/work/firefox-117.0/config/rules.mk:361: all]
Error 2
gmake[1]: Leaving directory '/wrkdirs/usr/ports/www/firefox/work/.build'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make: stopped in /usr/ports/www/firefox
=>> Cleaning up wrkdir
===>  Cleaning for firefox-117.0_2,2
build of www/firefox | firefox-117.0_2,2 ended at Sun Sep 10 16:00:48 JST 2023
build time: 00:38:38
!!! build failure encountered !!!

-- 
You are receiving this mail because:
You are the assignee for

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-08 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #20 from Tomoaki AOKI  ---
And as appears in the 3rd backtrace uploaded, `c` also fails.
Maybe we should set so-called breakpoint somewhere firefox starts generating
core, but I'm not enough understood how and where to set it. :-(

Enabling DEBUG option needed? But in some cases, especially in race conditions,
setting it could cause problems dissapear, with the cost of larger binary and
slowness.


% lldb -o r -- /usr/local/bin/firefox --ProfileManager --no-remote
--private-window
(lldb) target create "/usr/local/bin/firefox"
Current executable set to '/usr/local/bin/firefox' (x86_64).
(lldb) settings set -- target.run-args  "--ProfileManager" "--no-remote"
"--private-window"
(lldb) r
JavaScript error: resource://gre/modules/XULStore.sys.mjs, line 60: Error:
Can't find profile directory.
Process 21967 exited with status = -1 (0x) lost connection
Process 21967 launched: '/usr/local/bin/firefox' (x86_64)
(lldb) c
error: Process must be launched.
(lldb) q

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-08 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #19 from Tomoaki AOKI  ---
(In reply to Tatsuki Makino from comment #18)

Sorry.
Unfortunately, bt all just after crash cannot be obtained like below.

% lldb -o r -- /usr/local/bin/firefox --safe-mode
(lldb) target create "/usr/local/bin/firefox"
Current executable set to '/usr/local/bin/firefox' (x86_64).
(lldb) settings set -- target.run-args  "--safe-mode"
(lldb) r
Process 26896 exited with status = -1 (0x) lost connection
Process 26896 launched: '/usr/local/bin/firefox' (x86_64)
(lldb) bt all
error: Command requires a process which is currently stopped.
(lldb) q

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-07 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #18 from Tatsuki Makino  ---
(In reply to Tomoaki AOKI from comment #13)

Those are just suggestions to see if there are any problems when using GPUs.
I don't know how to use --headless either :)
However, it seems to us that the problem is the part about the GUI.

Then, my explanation about lldb in ML was not enough.
Type c into lldb only if the program stops at an irrelevant place, if the
program stops with a crash, it should be typed bt all immediately.
For example, the following

> lldb -o r -- /tmp/a.out 
(lldb) target create "/tmp/a.out"
Current executable set to '/tmp/a.out' (x86_64).
(lldb) r
Process 6041 stopped
* thread #1, name = 'a.out', stop reason = signal SIGSEGV: invalid address
(fault address: 0x0)
frame #0: 0x002018dd a.out`main at test.c:4:11
   1int
   2main()
   3{
-> 4int ga = *((int *)0);
   5return 0;
   6}
Process 6041 launched: '/tmp/a.out' (x86_64)
(lldb) bt all
* thread #1, name = 'a.out', stop reason = signal SIGSEGV: invalid address
(fault address: 0x0)
  * frame #0: 0x002018dd a.out`main at test.c:4:11
frame #1: 0x002016d0 a.out`_start + 256

When c is typed here, the program runs to the point of dumping core and exits.

(lldb) c
Process 6041 resuming
Process 6041 exited with status = 11 (0x000b) 
(lldb) q

If q is typed instead of c, the program is in the middle of execution and will
be forced to terminate.

(lldb) q
Quitting LLDB will kill one or more processes. Do you really want to proceed:
[Y/n]

I think the backtrace we get after reloading the core is still a little out of
place.
So, sorry, but would you please collect some more backtraces?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-07 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #17 from Tomoaki AOKI  ---
(In reply to Maxnix from comment #16)

Unfortunately, already tested and reported at Comment #7, without luck.

In fact, that test was a paranoid, as the untouched setting was as below.

% sysctl -a | fgrep allow_wx
kern.elf32.allow_wx: 1
kern.elf64.allow_wx: 1

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-06 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

Maxnix  changed:

   What|Removed |Added

 CC||maxnix@gmail.com

--- Comment #16 from Maxnix  ---
I had a similar issue too. For what is worth I observed this behaviour with
kern.elf64.allow_wx=0, which IIRC is the default on 13.2-RELEASE. To workaround
this without disabling W^X I enabled W^X mappings just for Firefox:

elfctl +wxneeded /usr/local/lib/firefox/firefox

The downside of this is that everytime Firefox is upgraded/reinstalled the
above command had to be re-executed.

HTH

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-03 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #15 from Tomoaki AOKI  ---
Created attachment 244608
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=244608=edit
Non-crashed transcripts on stable/14 from inside lldb, firefox --headless

Non-crashed transcripts on stable/14 from inside lldb, firefox --headless by
invoking `lldb -o r -- /usr/local/bin/firefox --headless`.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-03 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #14 from Tomoaki AOKI  ---
Created attachment 244607
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=244607=edit
Crash backtrace all on stable/14 inside lldb, firefox --safe-mode.

Crash backtrace (bt all) obtained on lldb by invoking `lldb -o r --
/usr/local/bin/firefox --safe-mode`.
Clicked OK button on displayed panel, then, crashed (core dumped).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-03 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #13 from Tomoaki AOKI  ---
(In reply to Tatsuki Makino from comment #12)

Here,
  *Mate desktop on X, but Wayland-related ports are pulled in as dependencies.
  *Login to command line and start Mate with startx.
  *x11/nvidia-driver (latest) as display driver. Currently, 535.98.
  *No *drm*-kmod ports installed. (nvidia descrete graphics mode).

And
  firefox --safe-mode: Crashes with core after pressing OK button.
  firefox --healdess : Looks running, but don't know how to use it.

I'll upload bt all of `firefox --safe-mode` on lldb and transcripts of `firefox
--headless` later.

If drm kmods are now-mandatory from firefox117, this means I can no longer use
firefox until K[P|B]I of linuxkpi is enough stabilized (no longer need to wait
for updates of kmods) to avoid no/broken screen issues. With this aspect,
nvidia-driver is almost stable enough, but no drm functionality alone.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-02 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

Tatsuki Makino  changed:

   What|Removed |Added

 CC||tatsuki_mak...@hotmail.com

--- Comment #12 from Tatsuki Makino  ---
I'll write it again here, these are not affected.
firefox-117.0_1,2
+ 12.4-STABLE 53c5e2732978
+ Just an X window system (wayland is not used)
+ Radeon (Caicos)

By the way, does the problem occur when booting in safe mode or headless?

firefox --safe-mode
firefox --headless

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-02 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

Tomoaki AOKI  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2734
   ||97
   Severity|Affects Only Me |Affects Some People

--- Comment #11 from Tomoaki AOKI  ---
Added Bug 273497 to "See Also" field, witch is ossibly a duplicate of this.

And changed "Importance" field to "Affects Some People", as at least one more
here, maybe two or even more people, are affected.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-01 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #10 from Tomoaki AOKI  ---
(In reply to Tomoaki AOKI from comment #9)

Sorry, forgot to write URL of ML archive.

[1] https://lists.freebsd.org/archives/freebsd-ports/2023-August/004359.html

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-09-01 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #9 from Tomoaki AOKI  ---
Created attachment 244552
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=244552=edit
Crash backtrace all on stable/14 from inside lldb.

As per advice/request from Tatsuki Makino on FreeBSD-ports ML [1], uploading
outputs by`bt all` using core obtained from firefox running under lldb.

`lldb -o r -- /usr/local/bin/firefox`

then bt all under

`lldb --core ~/firefox.core --file /usr/local/lib/firefox/firefox`

debugger session.

Running firefox from command line after those resulted in crash after a few
seconds (startup and untouched), Outputs from firefox are included.

Note that this time,
  *ports tree are updated to commit fb0373a15c107e3b50a5706d018aa35ad9892afc,
   including devel/glib20 update.

  *Check for OPTIONS, disabled now-non-default LIBPROXY and rebuilt firefox
117.

LIBPROXY option is dropped from default at commit
1bfb54119658886bda56773f280c32805ef4b089 (2018-11-20 18:55:42 +) by
jbeich@.
But unfortunately, options framework does not have the functionality to show
that each option is set to default or not, thus I didn't noticed the change for
such a long time.
Now the difference from default is PULSEAUDIO alone is intentionally set in
AUDIO group.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-08-31 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

Ken DEGUCHI  changed:

   What|Removed |Added

 CC||kdegu...@sz.tokoha-u.ac.jp

--- Comment #8 from Ken DEGUCHI  ---
I have the same situation too, Firefox 117 crashes on FreeBSD
13.2-STABLE(commit 472f6bfcae188be8686c2a4ddf8384199a105786), but Firefox 116
does not.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-08-30 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

Ed Maste  changed:

   What|Removed |Added

 Blocks||259968


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259968
[Bug 259968] ASLR by default tracking PR
-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-08-30 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #7 from Tomoaki AOKI  ---
Created attachment 244471
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=244471=edit
Crash backtrace on stable/14 from inside lldb.

As per advice by Tatsuki Makino on FreeBSD-ports ML ([6] on Comment5), obtained
core by running firefox inside lldb with `lldb -o r -- /usr/local/bin/firefox
--ProfileManager --no-remote --private-window` and obtained backtrace using the
dumped core as usual.

This time,
  with blank profile,
  with blank /usr/local/lib/compat/pkg/
  with `elfctl -e +wxneeded /usr/local/lib/firefox/firefox` as adviced for
others
  in Forums [1],
following invoking `firefox &` inside terminal emulator. (Maybe half-done
profile generated after this.)

[1]
https://forums.freebsd.org/threads/issues-with-running-firefox-after-major-release-upgrade.90117/#post-620305

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-08-30 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #6 from Tomoaki AOKI  ---
And found I'm not alone.

Similar (maybe the same) issue is reported at Forums.freebsd.org. [1]

[1]
https://forums.freebsd.org/threads/issues-with-running-firefox-after-major-release-upgrade.90117/

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-08-30 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #5 from Tomoaki AOKI  ---
For records not to be missed:
 Related posts on FreeBSD-ports ML. Excluding earlier / cross posts
 on dev-commits-ports-main ML.

[1] https://lists.freebsd.org/archives/freebsd-ports/2023-August/004318.html

[2] https://lists.freebsd.org/archives/freebsd-ports/2023-August/004320.html

[3] https://lists.freebsd.org/archives/freebsd-ports/2023-August/004321.html

[4] https://lists.freebsd.org/archives/freebsd-ports/2023-August/004323.html

[5] https://lists.freebsd.org/archives/freebsd-ports/2023-August/004337.html

[6] https://lists.freebsd.org/archives/freebsd-ports/2023-August/004338.html

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-08-28 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #4 from Tomoaki AOKI  ---
Additional note.
I've checked, to be sure, no pkgs for non-14 base is remaining with a stupid
script below. At first run, some pkgs for old base remained, so I've checked if
I no longer use it, or no ports I need requires it directly or indirectly and
deinstalled them.

After deinstalling, I've deleted firefox-117* from poudriere repo and rebuilt
it to be sure.


#!/bin/sh

CURVERS=14
TMPLIST=/tmp/pkglist

pkg version -o | cut -f 1 -w > ${TMPLIST}

cat ${TMPLIST} | while read PACKAGE
do
  ARCH=`pkg query %q ${PACKAGE}`
  if [ ${CURVERS} != `echo ${ARCH} | cut -f 2 -d :` ]
  then
echo Port ${PACKAGE} : ${ARCH}
  fi
done

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-08-28 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #3 from Tomoaki AOKI  ---
Created attachment 244409
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=244409=edit
Crash backtrace on stable/14

I must report a bad news.

This SIGSEGV is reproduced on clean stable/14.
Clean here means:

 *Base is built using blank /usr/obj,
 *Ports with old ABI/KBI are rebuilt on new poudriere jail / installed
  or otherwise deinstalled,
 *After that, `make delete-old-libs` is finished,
 *All contents in /usr/local/lib/compat/pkg are moved outside
/usr/local/lib[32],
  /usr/lib[32] and /lib, thus should not pulled in.

Crashed both with existing profile (OK for 116.*) and with blank profile.

Attached is with blank profile.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-08-22 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #2 from Tomoaki AOKI  ---
Forgot to mention.

stable/13 is at commit 47048a611dd2606fe93dd59ca9e3f7ec5d756390.
main is at commit 0d30f3afa62b4740810006476eb9de0c480619a1.
ports tree is at commit 14b2446e1843cc77a95256502edd10830be51a0b.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-08-22 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

--- Comment #1 from Tomoaki AOKI  ---
Created attachment 244282
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=244282=edit
Backtrace (by lldb) obtained on main

Uploaded backtrace obtained on main at commit
0d30f3afa62b4740810006476eb9de0c480619a1.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-08-22 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291

Bug ID: 273291
   Summary: www/firefox: Crashes on start after upgrading from
116.0.3_1,2 to 117.0,2
   Product: Ports & Packages
   Version: Latest
  Hardware: Any
OS: Any
Status: New
  Keywords: crash
  Severity: Affects Only Me
  Priority: ---
 Component: Individual Port(s)
  Assignee: ge...@freebsd.org
  Reporter: junch...@dec.sakura.ne.jp
  Assignee: ge...@freebsd.org
 Flags: maintainer-feedback?(ge...@freebsd.org)

www/firefox crashes on start after upgrading from 116.0.3_1,2 to 117.0,2.
Happenes both on stable/13 and on main, amd64.
No options changed. Simpy reverting back to 116.0.3_1,2 fixed the issue.
(Need to delete compatibility.ini file.)

On stable/13, revert is done with pkg delete and pkg add using backup pkg.
Both pkg was built with poudriere. So some dependencies could have different
version.

On main, revert is done with pkg delete, `git checkout 
57c756243c6d5879be226182b8309b8d83680899` and `pkg_replace -N www/firefox`.
(Not using poudriere on main. Unfortunately, backup pkg was not found on
expected place. But this is a completely unrelated problem with firefox)
So all other components 100% matches with both version of firefox.

-- 
You are receiving this mail because:
You are the assignee for the bug.

maintainer-feedback requested: [Bug 273291] www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to 117.0,2

2023-08-22 Thread bugzilla-noreply 
Bugzilla Automation  has asked freebsd-gecko (Nobody)
 for maintainer-feedback:
Bug 273291: www/firefox: Crashes on start after upgrading from 116.0.3_1,2 to
117.0,2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273291



--- Description ---
www/firefox crashes on start after upgrading from 116.0.3_1,2 to 117.0,2.
Happenes both on stable/13 and on main, amd64.
No options changed. Simpy reverting back to 116.0.3_1,2 fixed the issue.
(Need to delete compatibility.ini file.)

On stable/13, revert is done with pkg delete and pkg add using backup pkg.
Both pkg was built with poudriere. So some dependencies could have different
version.

On main, revert is done with pkg delete, `git checkout 
57c756243c6d5879be226182b8309b8d83680899` and `pkg_replace -N www/firefox`.
(Not using poudriere on main. Unfortunately, backup pkg was not found on
expected place. But this is a completely unrelated problem with firefox)
So all other components 100% matches with both version of firefox.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-06-15 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

Nuno Teixeira  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2709
   ||12

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-06-15 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

Nuno Teixeira  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2683
   ||18

--- Comment #1 from Nuno Teixeira  ---
(In reply to Mark Johnston from comment #0)

Hello Mark,

I'm testing firefox-114.0.1 on 13-STABLE with:

$ proccontrol -m aslr -s disable firefox

and it runs fine without problems.

Recent discussion on:
https://lists.freebsd.org/archives/dev-commits-ports-all/2023-June/067113.html

What should be done here?

- Disable aslr at build time via an option
- Show message at install time about disabling aslr at runtime with
proccontrol, for aarch64 and let user use it if he having problems
- Fix it upstream, optimal solution :)

I'm new to aarch64 and I did found some dificulties to get into aslr
connection.
I remember that some users at forums having same problem with no answer at all.

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

[Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-04-26 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

Graham Perrin  changed:

   What|Removed |Added

 CC||ge...@freebsd.org
   Keywords||crash
   Assignee|b...@freebsd.org|ge...@freebsd.org
URL||https://www.freshports.org/
   ||www/firefox/
  Flags||maintainer-feedback?(gecko@
   ||FreeBSD.org)
Summary|firefox crashes on arm64|www/firefox: crashes on
   |with ASLR enabled   |arm64 with ASLR enabled
 Status|New |Open

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.

maintainer-feedback requested: [Bug 271081] www/firefox: crashes on arm64 with ASLR enabled

2023-04-26 Thread bugzilla-noreply 
Graham Perrin  has asked freebsd-gecko (Nobody)
 for maintainer-feedback:
Bug 271081: www/firefox: crashes on arm64 with ASLR enabled
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271081

[Bug 243618] www/firefox: crashes during file save dialogue

2022-03-28 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243618

gja...@narod.ru changed:

   What|Removed |Added

 Resolution|--- |Overcome By Events
 Status|Open|Closed

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 243618] www/firefox: crashes during file save dialogue

2022-03-28 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243618

--- Comment #7 from Graham Perrin  ---
(In reply to gja822 from comment #6)

Thank you, would you like to close the bug? Overcome by events, I guess.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 243618] www/firefox: crashes during file save dialogue

2022-03-26 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243618

--- Comment #6 from gja...@narod.ru ---
(In reply to Graham Perrin from comment #5)
no, recently it's O.K.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 228855] www/firefox: crashes on certain sites

2021-12-18 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228855

--- Comment #18 from Graham Perrin  ---
Is this still reproducible? 

Food for thought: bug 260387 comment 7 with regard to limits.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 243618] www/firefox: crashes during file save dialogue

2021-12-18 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243618

--- Comment #5 from Graham Perrin  ---
(In reply to Graham Perrin from comment #4)

> … very rarely, I get a crash at save time when I attempt to 
> create a new folder. …

No such crash in recent months. 

(In reply to gja822 from comment #0)

Is this bug still reproducible?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 243618] www/firefox: crashes during file save dialogue

2020-10-10 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243618

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #4 from Graham Perrin  ---
If it helps to narrow this: very rarely, I get a crash at save time when I
attempt to create a new folder. When a crash occurs in this situation, a
subsequent run of Firefox is crash-free.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

[Bug 243618] www/firefox: crashes during file save dialogue

2020-04-22 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243618

--- Comment #3 from gja...@narod.ru ---
(Debug is ON for glib and OFF for firefox due to build system limitations - not
enough space on a partiotion to build.)

Now it was during attempt to download any of files from the page:
https://live.nspu.ru/videos/video/5517/?show-files=1

With the outpit:

/usr/local/bin/gdb91 /usr/local/lib/firefox/firefox
GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD]
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.3".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/lib/firefox/firefox...
(No debugging symbols found in /usr/local/lib/firefox/firefox)
(gdb) r
Starting program: /usr/local/lib/firefox/firefox 
warning: File "/usr/local/lib/gcc10/libstdc++.so.6.0.28-gdb.py" auto-loading
has been declined by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/local/lib/gcc10/libstdc++.so.6.0.28-gdb.py
line to your configuration file "/home/yury/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/yury/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
[Detaching after fork from child process 51303]
[New LWP 100993 of process 37346]
[New LWP 100994 of process 37346]
[New LWP 100995 of process 37346]
[New LWP 100996 of process 37346]
[New LWP 100998 of process 37346]
[New LWP 101000 of process 37346]
[New LWP 101001 of process 37346]
[New LWP 101002 of process 37346]
[New LWP 101005 of process 37346]
[New LWP 101006 of process 37346]
[New LWP 101007 of process 37346]
[New LWP 101008 of process 37346]
[New LWP 101010 of process 37346]
[New LWP 101012 of process 37346]
[New LWP 101020 of process 37346]
[New LWP 101021 of process 37346]
[New LWP 101026 of process 37346]
[New LWP 101027 of process 37346]
[New LWP 101029 of process 37346]
[New LWP 101030 of process 37346]
[New LWP 101031 of process 37346]
[New LWP 100728 of process 37346]
[New LWP 101042 of process 37346]
[New LWP 101047 of process 37346]
[New LWP 101049 of process 37346]
[New LWP 101052 of process 37346]
[New LWP 101053 of process 37346]
[New LWP 101054 of process 37346]
[New LWP 101055 of process 37346]
[New LWP 101057 of process 37346]
[New LWP 101058 of process 37346]
[New LWP 101060 of process 37346]
[LWP 101055 of process 37346 exited]
[LWP 101054 of process 37346 exited]
[LWP 101053 of process 37346 exited]
[LWP 101021 of process 37346 exited]
[New LWP 101062 of process 37346]
[New LWP 101063 of process 37346]
[New LWP 101068 of process 37346]
[New LWP 101071 of process 37346]
[New LWP 101072 of process 37346]
[New LWP 101074 of process 37346]
[New LWP 101075 of process 37346]
[New LWP 101079 of process 37346]
[New LWP 101080 of process 37346]
[New LWP 101082 of process 37346]
[New LWP 101083 of process 37346]
[New LWP 101085 of process 37346]
[Detaching after fork from child process 80297]
[New LWP 101112 of process 37346]
[New LWP 101169 of process 37346]
[New LWP 101173 of process 37346]
[New LWP 101176 of process 37346]
[New LWP 101178 of process 37346]
[New LWP 101179 of process 37346]
[New LWP 101180 of process 37346]
[New LWP 101181 of process 37346]
[New LWP 101182 of process 37346]
[New LWP 101183 of process 37346]
[New LWP 101184 of process 37346]
[New LWP 101185 of process 37346]
[New LWP 101186 of process 37346]
[LWP 101029 of process 37346 exited]
[New LWP 100289 of process 37346]
[LWP 101072 of process 37346 exited]
[Detaching after fork from child process 88515]
console.error: "Could not write session state file " (new Error("_initWorker
called too early! Please read the session file from disk first.",
"resource:///modules/sessionstore/SessionFile.jsm", 375))

[Bug 243618] www/firefox: crashes during file save dialogue

2020-04-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243618

--- Comment #2 from gja...@narod.ru ---
(In reply to Jan Beich from comment #1)
Rebuilt devel/glib20 with DEBUG ON. (Not able to build www/firefox with DEBUG
for now, unfortunately.)

The bug happen not so frequently (and I do not "save as" too many things).
Under devel/gdb (with DEBUG in glib20) I get this now:

[New LWP 101670 of process 80790]
[New LWP 101672 of process 80790]
[New LWP 101673 of process 80790]
[New LWP 101674 of process 80790]
[LWP 101668 of process 80790 exited]
[LWP 101672 of process 80790 exited]
[LWP 101673 of process 80790 exited]
[LWP 101675 of process 80790 exited]
[LWP 101670 of process 80790 exited]
[New LWP 101099 of process 80790]
[LWP 101099 of process 80790 exited]
--Type  for more, q to quit, c to continue without paging--r

Thread 1 received signal SIGSEGV, Segmentation fault.
0x000810688ee6 in bool
js::gc::IsAboutToBeFinalizedInternal(JSObject**) () from
/usr/local/lib/firefox/libxul.so
(gdb) where
#0  0x000810688ee6 in bool
js::gc::IsAboutToBeFinalizedInternal(JSObject**) () at
/usr/local/lib/firefox/libxul.so
#1  0x00081043b980 in js::PreliminaryObjectArray::sweep() ()
at /usr/local/lib/firefox/libxul.so
#2  0x00081043d7dd in js::ObjectGroup::sweep(js::AutoSweepObjectGroup
const&) () at /usr/local/lib/firefox/libxul.so
#3  0x00081066ef47 in js::gc::GCRuntime::sweepTypeInformation(JSFreeOp*,
js::SliceBudget&) () at /usr/local/lib/firefox/libxul.so
#4  0x0008106808fc in
sweepaction::SweepActionSequence::run(js::gc::SweepAction::Args&) () at
/usr/local/lib/firefox/libxul.so
#5  0x00081067d682 in
sweepaction::SweepActionForEach::run(js::gc::SweepAction::Args&) ()
at /usr/local/lib/firefox/libxul.so
#6  0x0008106808fc in
sweepaction::SweepActionSequence::run(js::gc::SweepAction::Args&) () at
/usr/local/lib/firefox/libxul.so
#7  0x00081067d429 in
sweepaction::SweepActionForEach::run(js::gc::SweepAction::Args&) ()
at /usr/local/lib/firefox/libxul.so
#8  0x00081066fd53 in
js::gc::GCRuntime::performSweepActions(js::SliceBudget&) () at
/usr/local/lib/firefox/libxul.so
#9  0x000810671839 in js::gc::GCRuntime::incrementalSlice(js::SliceBudget&,
mozilla::Maybe const&, JS::GCReason,
js::gc::AutoGCSession&) () at /usr/local/lib/firefox/libxul.so
--Type  for more, q to quit, c to continue without paging--
#10 0x000810672b50 in js::gc::GCRuntime::gcCycle(bool, js::SliceBudget,
mozilla::Maybe const&, JS::GCReason) ()
at /usr/local/lib/firefox/libxul.so
#11 0x00081067364a in js::gc::GCRuntime::collect(bool, js::SliceBudget,
mozilla::Maybe const&, JS::GCReason) ()
at /usr/local/lib/firefox/libxul.so
#12 0x000810673c9b in js::gc::GCRuntime::gcSlice(JS::GCReason, long) ()
at /usr/local/lib/firefox/libxul.so
#13 0x00080e095daf in InterSliceGCRunnerFired(mozilla::TimeStamp, void*) ()
at /usr/local/lib/firefox/libxul.so
#14 0x00080d128650 in mozilla::IdleTaskRunner::Run() ()
at /usr/local/lib/firefox/libxul.so
#15 0x00080d13b928 in nsThread::ProcessNextEvent(bool, bool*) ()
at /usr/local/lib/firefox/libxul.so
#16 0x00080d13ea8b in NS_ProcessNextEvent(nsIThread*, bool) ()
at /usr/local/lib/firefox/libxul.so
#17 0x00080d5660fb in
mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () at
/usr/local/lib/firefox/libxul.so
#18 0x00080d52f427 in MessageLoop::Run() ()
at /usr/local/lib/firefox/libxul.so
#19 0x00080f42a369 in nsBaseAppShell::Run() ()
at /usr/local/lib/firefox/libxul.so
#20 0x00081006a958 in nsAppStartup::Run() ()
--Type  for more, q to quit, c to continue without paging--
at /usr/local/lib/firefox/libxul.so
#21 0x000810125942 in XREMain::XRE_mainRun() ()
at /usr/local/lib/firefox/libxul.so
#22 0x000810125ef6 in XREMain::XRE_main(int, char**,
mozilla::BootstrapConfig const&) () at /usr/local/lib/firefox/libxul.so
#23 0x0008101261ee in XRE_main(int, char**, mozilla::BootstrapConfig
const&) () at /usr/local/lib/firefox/libxul.so
#24 0x010287d0 in main ()
(gdb) c
Continuing.
[LWP 101674 of process 80790 exited]

Thread 1 received signal SIGSEGV, Segmentation fault.
0x0008020a73da in thr_kill () from /lib/libc.so.7
(gdb) с
Continuing.
[LWP 101413 of process 80790 exited]
[LWP 101408 of process 80790 exited]
[LWP 101412 of process 80790 exited]
[LWP 100857 of process 80790 exited]
[LWP 101409 of process 80790 exited]
[LWP 100843 of process 80790 exited]
[LWP 101417 of process 80790 exited]
[LWP 101426 of process 80790 exited]
[LWP 101415 of process 80790 exited]
[LWP 101422 of process 80790 exited]
[LWP 101414 of process 80790 exited]
[LWP 101421 of process 80790 exited]
[LWP 100834 of process 80790 exited]
[LWP 101429 of process 80790 exited]
[LWP 100862 of process 80790 exited]
[LWP 101423 of process 80790 exited]
[LWP 100603 of process 80790 exited]
[LWP 101456 of process 80790 exited]
[LWP 101434 of process 80790 exited]
[LWP 101435 of process 80790

[Bug 243618] www/firefox: crashes during file save dialogue

2020-03-29 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243618

--- Comment #1 from Jan Beich  ---
Backtrace looks incomplete. Rebuild devel/glib20 with WITH_DEBUG=1. Better
rebuild www/firefox and *all* library dependencies WITH_DEBUG=1.

Can you reproduce using only binary packages? Back up and reinstall everything
from packages. If still occurs this maybe a devel/glib20 bug.

In case it's an upstream issue does bug 244793 help?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

[Bug 243639] www/firefox - crashes on latest version after upgrade

2020-01-27 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243639

Jan Beich  changed:

   What|Removed |Added

   See Also|https://bugs.freebsd.org/bu |
   |gzilla/show_bug.cgi?id=2436 |
   |29  |

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

[Bug 243639] www/firefox - crashes on latest version after upgrade

2020-01-27 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243639

Jan Beich  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |DUPLICATE

--- Comment #7 from Jan Beich  ---
Let's discuss possible fixes in one place.

*** This bug has been marked as a duplicate of bug 243629 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

[Bug 243639] www/firefox - crashes on latest version after upgrade

2020-01-27 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243639

--- Comment #6 from Walter Schwarzenfeld  ---
Correct: ports rr524241.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

[Bug 243639] www/firefox - crashes on latest version after upgrade

2020-01-27 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243639

--- Comment #5 from Walter Schwarzenfeld  ---
Sqlite3 reverted to 3.30.1 with r524241.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

[Bug 243639] www/firefox - crashes on latest version after upgrade

2020-01-26 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243639

--- Comment #4 from a...@neu.net ---
I think Craig is right, I just did pkg delete -f sql and then pkg install sql. 
I now have sqlite3-3.30.1 installed and Firefox starts successfully.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

[Bug 243639] www/firefox - crashes on latest version after upgrade

2020-01-26 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243639

--- Comment #3 from Craig Leres  ---
(In reply to andy from comment #2)
svn up -r516357 /usr/local/poudriere/ports/current-patched/databases/sqlite3
poudriere bulk -C -j 11release -p current databases/sqlite3

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

[Bug 243639] www/firefox - crashes on latest version after upgrade

2020-01-26 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243639

--- Comment #2 from a...@neu.net ---
Hi Craig:

Would please post the exact commands/procedure you used to downgrade sqlite3 to
3.30.1 (r516357).  I would like to try it.  Thank you.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

[Bug 243639] www/firefox - crashes on latest version after upgrade

2020-01-26 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243639

Craig Leres  changed:

   What|Removed |Added

 CC||le...@freebsd.org

--- Comment #1 from Craig Leres  ---
Created attachment 211090
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=211090=edit
stacktrace

In my case both firefox and thunderbird were borked.

First I tried reinstalling all packages. Next, seeing sqlite3 in the stacktrace
(attached) I tried downgrading databases/sqlite3 to 3.30.1 (r516357) which
fixed both.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

maintainer-feedback requested: [Bug 243639] www/firefox - crashes on latest version after upgrade

2020-01-26 Thread bugzilla-noreply 
Walter Schwarzenfeld  has asked freebsd-gecko
mailing list  for maintainer-feedback:
Bug 243639: www/firefox - crashes on latest version after upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243639
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

[Bug 243639] www/firefox - crashes on latest version after upgrade

2020-01-26 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243639

Walter Schwarzenfeld  changed:

   What|Removed |Added

 CC||ge...@freebsd.org,
   ||w.schwarzenf...@utanet.at
  Flags||maintainer-feedback?(gecko@
   ||FreeBSD.org)
   Assignee|ports-b...@freebsd.org  |ge...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

[Bug 243639] www/firefox - crashes on latest version after upgrade

2020-01-26 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243639

Walter Schwarzenfeld  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2436
   ||29

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-gecko@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-gecko
To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"

  1   2   >