Process: launchd [1603]
Path: /Applications/Waterfox.app/Contents/MacOS/waterfox
Identifier: org.waterfoxproject.waterfox classic
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: launchd [116]
Date/Time: 2020-04-08 12:14:43.290 -0400
OS Version: Mac OS X 10.7.5 (11G63)
Report Version: 9
Interval Since Last Report: 15449570 sec
Crashes Since Last Report: 397
Per-App Crashes Since Last Report: 6
Anonymous UUID: F974C764-CDFE-437F-9527-970AAB24F6E3
Crashed Thread: Unknown
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007fff5fc01028
Backtrace not available
Unknown thread crashed with X86 Thread State (64-bit):
rax: 0x0000000000000055 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000000
rdi: 0x0000000000000000 rsi: 0x0000000000000000 rbp: 0x0000000000000000 rsp: 0x0000000000000000
r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000000
r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000
rip: 0x00007fff5fc01028 rfl: 0x0000000000010203 cr2: 0x00007fff5fc01028
Logical CPU: 0
Binary images description not available
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 1
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 10824
thread_create: 0
thread_set_state: 0
Model: MacBook3,1, BootROM MB31.008E.B02, 2 processors, Intel Core 2 Duo, 2.2 GHz, 4 GB, SMC 1.24f3
Graphics: Intel GMA X3100, GMA X3100, Built-In, 144 MB
Memory Module: BANK 0/DIMM0, 2 GB, DDR2 SDRAM, 667 MHz, 0x7F7F7F7F7F9B0000, 0x4354323536363441433636372E4D31364648
Memory Module: BANK 1/DIMM1, 2 GB, DDR2 SDRAM, 667 MHz, 0x7F7F7F7F7F9B0000, 0x4354323536363441433636372E4D31364648
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x88), Broadcom BCM43xx 1.0 (5.10.131.36.15)
Bluetooth: Version 4.0.8f17, 2 service, 11 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: FUJITSU MHY2160BH, 160.04 GB
Parallel ATA Device: MATSHITADVD-R UJ-857E
USB Device: Built-in iSight, apple_vendor_id, 0x8501, 0xfd400000 / 2
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x8205, 0x1a100000 / 2
USB Device: Dell USB Mouse, 0x413c (Dell Inc.), 0x3200, 0x1d100000 / 2
USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0229, 0x5d200000 / 3
USB Device: IR Receiver, apple_vendor_id, 0x8242, 0x5d100000 / 2
A regression of THIS maybe?
browser.tabs.remote.force-disable true2020.04Any better?
It was already true & makes no difference.
Error code from another mac -
Process: launchd [604] Path: /Applications/Waterfox Classic.app/Contents/MacOS/waterfox Identifier: org.waterfoxproject.waterfox classic Version: ??? (???) Code Type: X86-64 (Native) Parent Process: launchd [134]
Date/Time: 2020-04-09 14:00:47.140 +0200 OS Version: Mac OS X 10.7.5 (11G63) Report Version: 9 Sleep/Wake UUID: 74A8E82D-4155-45EA-84A8-464844B01EA6
Interval Since Last Report: 11894790 sec Crashes Since Last Report: 2974 Per-App Crashes Since Last Report: 43 Anonymous UUID: 11AABF9C-DD11-4089-AD8E-27F4A28001C9
Crashed Thread: Unknown
Exception Type: EXCBADACCESS (SIGSEGV) Exception Codes: KERNINVALIDADDRESS at 0x00007fff5fc01028
Backtrace not available
Unknown thread crashed with X86 Thread State (64-bit): rax: 0x0000000000000055 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000000 rdi: 0x0000000000000000 rsi: 0x0000000000000000 rbp: 0x0000000000000000 rsp: 0x0000000000000000 r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000000 r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 rip: 0x00007fff5fc01028 rfl: 0x0000000000010203 cr2: 0x00007fff5fc01028 Logical CPU: 1
Binary images description not available
External Modification Summary: Calls made by other processes targeting this process: taskforpid: 1 threadcreate: 0 threadsetstate: 0 Calls made by this process: taskforpid: 0 threadcreate: 0 threadsetstate: 0 Calls made by all processes on this machine: taskforpid: 1196 threadcreate: 0 threadset_state: 0
Model: iMac5,1, BootROM IM51.0090.B09, 2 processors, Intel Core 2 Duo, 2 GHz, 3 GB, SMC 1.8f2 Graphics: ATI Radeon X1600, ATY,RadeonX1600, PCIe, 128 MB Memory Module: BANK 0/DIMM0, 1 GB, DDR2 SDRAM, 667 MHz, 0xCE00000000000000, 0x4D3420373054323836345148332D43463720 Memory Module: BANK 1/DIMM1, 2 GB, DDR2 SDRAM, 667 MHz, 0x7F7F7F7F7F9B0000, 0x4354323536363441433636372E4D31364648 AirPort: spairportwirelesscardtypeairportextreme (0x14E4, 0x87), Broadcom BCM43xx 1.0 (5.10.131.36.15) Bluetooth: Version 4.0.8f17, 2 service, 18 devices, 1 incoming serial ports Network Service: Ethernet, Ethernet, en0 Network Service: AirPort, AirPort, en1 Serial ATA Device: WDC WD3200AVJS-63B6A0, 320,07 GB Parallel ATA Device: MATSHITADVD-R UJ-85J USB Device: Built-in iSight, applevendorid, 0x8501, 0xfd400000 / 2 USB Device: EyeTV DTT Dlx, 0x0fd9, 0x0020, 0xfd500000 / 3 USB Device: 2.4G Keyboard Mouse, 0x062a (ProVision Technology, Inc.), 0x4101, 0x3d100000 / 2 USB Device: Bluetooth USB Host Controller, applevendorid, 0x8206, 0x7d100000 / 2 USB Device: IR Receiver, applevendor_id, 0x8240, 0x7d200000 / 3
Any progress or info needed? Le'me know if ya needa tester.
[crickets]...
Will this be addressed in this release month or skipped until the NEXT release or even later?
Classic 2020.4 launch attempt in Mac OS X 10.10.5: "[..] This Application requires at least Mac OS 10.11" ... !! As a matter of fact, the WF icon inside the dmg is already crossed with a line, indicating it can't be launched.
2020.3.1 still launches fine in 10.10.5. Min version in Classic 2020.4 info.plist is 10.5.... (should thus be 10.11, but obviously the deciding version restriction is somewhere else).
Min version in Classic 2020.4 info.plist is 10.5
That's been wrong for a long time. Support for Leopard & Snow Leopard has been abandoned for years. The .plist entry should be 10.7 if it gets fixed & is ever able to boot that is!
Conclusion is: WF Classic must be compiled on lower Osx (Lion) for compatibility ...
almost.. In Xcode it's well possible to compile for a lower version macOS/ OS X by adding both, the older SDKs AND the correct target(s) settings. However I don't even know if the macOS port is done in Xcode.
.. I said it before, I'll say it again!
I CAN TEST THE RELEASE BEFORE IT"S RELEASED & FAILS!
... Will the next release launch??
I just created a local build targeting exactly this.
index e85576a1cc..9a2ae82853 100644
--- a/.mozconfig
+++ b/.mozconfig
@@ -2,7 +2,7 @@
# macOS Specific Options
if test `uname -s` = Darwin; then
-ac_add_options --enable-optimize="-O2 -march=core2 -mtune=core2 -w"
+ac_add_options --enable-optimize="-O2 -march=core2 -mtune=core2 -mmacosx-version-min=10.10 -w"
ac_add_options --enable-eme=widevine
ac_add_options --enable-ccache=sccache
ac_add_options --enable-macos-target=10.9
And it worked. In fact I built mine with 10.13 SDK and it still works fine (till now). I have 10.10.5. Feel free to change that flag to 10.7 and see what happens.
Another test without the above changes on 10.15.1 suggest the flag above being superfluous at least when not cross-compiling under Linux (Apple Clang vs. LLVM.org Clang).
@pjpreilly Download. I don't currently have 10.7, but it ran just fine on 10.9-10.15.
10.7 as well as 10.8 are the problem versions. 10.7 LINK HERE if you want you can install the os on a usb for testing.
FWIW your 2020.5 test build successfully launches & runs on 10.7.5.
@CL-Jeremy it still crashes when a download is attempted though & probably has other known issues too.
Are you gonna:
* Did you mistag @pjenvey in your previous comment?
* Did you mistag @pjenvey in your previous comment?
Yes, sorry about that. I believed the issue owner should be at the top of the popup list. That wasn't the case and I was unable to tag you without typing the full ID. GitHub bug?
it still crashes when a download is attempted though & probably has other known issues too.
I'm currently not aware of any issues since I have not been tracking regressions of Waterfox on older platforms.
Are you gonna:
1. Add an issues section to your fork?
This is not possible on GitHub AFAIK. Nor do I see a need.
2. Use the 10.7 install image for testing?
No, but I do have an ancient backup from 2014 (10.8.3) to test on. A virtual machine could be another choice. That said, things have always been complicated with Macs (had some experience with building Arctic Fox for 10.6 machines on premise). I'll see what I can do at the moment.
Thanks for the effort .... The other issues are opening a Preference pane and then raising a hidden dock or accessing Dashboard(I use hot corners) will cause the browser to crash. Even more serious is enabling DRM plugin which causes a Kernel Panic. 10.8 should be sufficient to test since I believe 10.7 & 10.8 are experiencing the same issues. Let me know when you need something tested or more information.
Another test without the above changes on 10.15.1 suggest the flag above being superfluous at least when not cross-compiling under Linux (Apple Clang vs. LLVM.org Clang).
@pjpreilly Download. I don't currently have 10.7, but it ran just fine on 10.9-10.15.
All good in Mac OS Yosemite 10.10.5 incl. downloads. Thank you pjpreilly!
Another test without the above changes on 10.15.1 suggest the flag above being superfluous at least when not cross-compiling under Linux (Apple Clang vs. LLVM.org Clang).
@pjpreilly Download. I don't currently have 10.7, but it ran just fine on 10.9-10.15.
On 10.7.5 same things like prev. rel. - start ok, download crash, add new tab & clear history freezing os
On 10.7.5 same things like prev. rel. - start ok, download crash, add new tab & clear history freezing os
cannot test on Yosemite 10.10.5 right now because it'll take me a while before I have access to that MacBook again.
cannot test on Yosemite 10.10.5 right now
I believe 10.7 & 10.8 are the ones with the problems.... 10.9 & above are fine.
cannot test on Yosemite 10.10.5 right now
I believe 10.7 & 10.8 are the ones with the problems.... 10.9 & above are fine.
10.10.5 is my daily driver. I only use 10.13.0 and 10.15.1 for building purposes. I came for this issue since the last cross-compiled release obviously missed the flag/environment variable for deployment target but otherwise runs fine. Yes, I am constantly experiencing the same crash on 10.8.3, but even so it doesn't happen all the time (not if the MIME format is unknown or generic, for example, though not 100% sure). What I am sure about is, when it's possible to do a right click and choose to save the linked target as
Also weird: https://duden.de did not hang while searching for a word. It happens all the time on 10.10.
Edit: I lied. I was running a build from last year to test the problem mentioned here, but it automatically upgraded to 2020.3.1 and I didn't notice at first, and forgot about the whole thing after a day or two.
Also weird:
For me this sight on 10.7 will chug through a GB of ram in a short time... seems javascript processing has some issue too.
2020.5 is a known failure too now!!
Ok. Here are my 2垄, as a OS X 10.8 user.. I'm still stuck on the 2020.03 release as it is actually the last one that launches on 10.8 (presumably the same for 10.7). Though, it's worth noting that while the 2020.03 release is the last to actually launch and seems to perform faster, it has some glaring crashers which were not there in prior versions. Some of the big ones being:
So, looking at the post-2020.03 releases, the situation is worse. Both the 2020.04 and 2020.05 releases of "Waterfox Classic" will not even launch on 10.8.5.
For example, here's output from me trying to launch 2020.05 from the shell, as when launching it from the Finder, it silently fails:
0% /Applications/Waterfox\ Classic.app/Contents/MacOS/waterfox-bin --ProfileManager
XPCOMGlueLoad error for file /Applications/Waterfox Classic.app/Contents/MacOS/XUL:
dlopen(/Applications/Waterfox Classic.app/Contents/MacOS/XUL, 265): Symbol not found: _kCFURLQuarantinePropertiesKey
Referenced from: /Applications/Waterfox Classic.app/Contents/MacOS/XUL
Expected in: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
in /Applications/Waterfox Classic.app/Contents/MacOS/XUL
Couldn't load XPCOM.
255%
It looks like it can't find the _kCFURLQuarantinePropertiesKey symbol in /System/Library/Framework/CoreFoundation.framework/versions/A/CoreFoundation.
I can only assume this is a symbol that exists in newer versions of CoreFoundation. At a guess, the build is not targeting the 10.7 and higher SDKs. Hope that helps.
@rorya : what about https://github.com/CL-Jeremy/Waterfox/releases/tag/upre-2020.05-classic?
@LeeBinder yeah, that one does launch on 10.8 and seems to function about the same as 2020.03. It looks like the crashers mentioned in my last post are unchanged with this one though. Thanks.
... & yet they spend time on a logo design when this issue lingers! Go figure!
what?
0% /Applications/Waterfox\ Classic.app/Contents/MacOS/waterfox-bin --ProfileManager
XPCOMGlueLoad error for file /Applications/Waterfox Classic.app/Contents/MacOS/XUL:
dlopen(/Applications/Waterfox Classic.app/Contents/MacOS/XUL, 265): Symbol not found: _kCFURLQuarantinePropertiesKey
That one indeed seems to come from the Swift era, so the error is to be expected.
I haven't had much success in getting compilation done fully under 10.8. Building Rust from source errored out many times. I'll probably try doing it on a virtual machine this time.
@CL-Jeremy thanks for making the 10.7+ compatible build. What is the reason the official build won't run on those.. is it a matter of the person who builds it, use an older version of OSX to build it? Are there any downsides to that, for example, would it be a tradeoff by risking forward compatibility in newest OSX releases? or maybe a loss of certain features in newer releases? I figured this was mostly an SDK targeting problem, but it sounds like it might be more nuanced than that. Thanks for helping us 10.7+ users stay in business B)
@CL-Jeremy thanks for making the 10.7+ compatible build. What is the reason the official build won't run on those.. is it a matter of the person who builds it, use an older version of OSX to build it? Are there any downsides to that, for example, would it be a tradeoff by risking forward compatibility in newest OSX releases? or maybe a loss of certain features in newer releases? I figured this was mostly an SDK targeting problem, but it sounds like its more nuanced than that. Thanks for helping us 10.7+ users stay in business B)
I'm not quite sure about the exact reason. The official 2020.04 release was built with the exact same set of macOS-specific options, albeit cross-compiled on Linux. The only changes are in regard to the LLVM-Clang version the author uses for the build, where for some reason the correctly set environment variable did not result in working binaries. The SDK requirement has always been OS X 10.11 since the creation of the current repo from upstream.
But the crashing-on-download bug is a totally different issue that seems unrelated, which has happened sporadically over multiple past versions on 10.7/10.8. I am only performing some trial-and-errors currently so can't really say anything meaningful about the bug itself.
Edit: I finally got Rust and Cargo 1.32.0 to build properly on 10.8 (with MacPorts Rust 1.31.1) and built the exact same code base as last time, this time against 10.9 SDK (Xcode 5.1.1) with locally built MacPorts Clang 8.0.1. The symptoms remained exactly the same as mentioned above. (The toolchain has been working fine for other stuff - hopefully the version of Cargo doesn't cause problems with dependencies, i. e. Cargo.lock is respected). Well, it's fun enough that the build worked at all with 10.9 SDK. Next try could be to link against 10.8 SDK and see if that helps, but I'm highly skeptical about that. Has there been any UI-related patches since 2020.03.x?
Edit 2: okay in this regard it's a dupe of #1059. Silly of me only realizing this now.
So it seems that the patch by @tmkk was indeed the secret sauce. That issue really should have caught more attention, if only there were more legacy Mac users to help.
The new test build could be downloaded here. The relevant commit is https://github.com/CL-Jeremy/Waterfox/commit/16872538bcf14d59034b74c1819a998914964a59.
So it seems that the patch by @tmkk was indeed the secret sauce.
What issues need verifying?
So it seems that the patch by @tmkk was indeed the secret sauce.
What issues need verifying?
4. Download issue?
Hold on...
We are already hijacking this thread with discussions on other issues. I'm posting download link here since this issue has attracted more attention than others, and people are giving nice feedback here.
This build is a temporary solution for the regression of the author's build system from release 2020.03.1 to 2020.04, which is not reflected in this repo (other than .mozbuild) and likely also not an issue of Waterfox itself. The Download dialog crash has now been found to be unrelated to the toolchain used to compile it but rather some known API compatibility with some basic platform-specific implementations. I've already referred to that issue and further discussions should go there (I've already got confused with the emerging occasion of that issue and carried out some futile tests as a result).
In reply to your other issues:
1 & 2 still cause a KP on 10.7.5
3 & 4 look to be fixed.
.. Do you have 10.7.5 to stage 1 & 2?
@CL-Jeremy Just posting a followup, to update you and the rest of us pre-10.9 users, on my testing of your latest 2020.05 "r2" ( https://github.com/CL-Jeremy/Waterfox/releases/download/upre-r2-2020.05-classic/waterfox-classic-upre-r2-2020.05.en-US.mac.dmg ) build. I am running right now, where I'm writing this, on a pretty large, <100 view session, I'd guess.
So I've done a little testing and It appears here on OSX 10.8.5, this one has fixed these 2020.04 & 05 crashers for me:
Many thanks for your work on this. This is a big improvement.. this one may now finally be back to the 2020.03 release's levels of reliability.
2020.6 is doomed also.......
Oh man, 2020.7.1 also? It's said to "increase compatibility with older Mac OS X", but obviously not with 10.7/8 .. :(
Oh man, 2020.7.1 also? It's said to "increase compatibility with older Mac OS X", but obviously not with 10.7/8 .. :(
Nope, this has nothing to do with the code. It's either a bug in the latest LLVM/Clang or @MrAlex94 has to verify the build script yet again. Note that on Linux than it might be that different settings are needed than mine, which are used to build natively on macOS.
It's the issue below:
Classic 2020.4 launch attempt in Mac OS X 10.10.5: "[..] This Application requires at least Mac OS 10.11" ... !! As a matter of fact, the WF icon inside the dmg is already crossed with a line, indicating it can't be launched.
I have updated the files on the CDN with a fixed version. I have played around on a 10.7 VM and there is no longer any crashing. 10.7 should now be here to stay (unless a security patch comes and breaks things).
Very cool, thank you @MrAlex94 ! Just wondering - it's already mid August and you're still sticking with 2020.07 for the release name. I guess you're also working on a 2020.08 release still THIS month with a specific set of fixes which are not fully final yet and did not want to mix them up with this 2020.07.02 (intermediate) release?
Still issues with video playing...
Most helpful comment
I have updated the files on the CDN with a fixed version. I have played around on a 10.7 VM and there is no longer any crashing. 10.7 should now be here to stay (unless a security patch comes and breaks things).