Comments (15)
I face the same issue in my local (MacOS 11.7, Gradle 8.8)
from gradle.
This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary.
This might be tied to #28259
@hoc081098 Can you share a JVM crash log when this happens?
from gradle.
I tried reproducing the problem by assuming it's a null-pointer issue. I tried passing nullptr
to the FileEvent
constructor here:
And also to ErrorEvent
here:
I managed to crash the JVM, but this produced a somewhat different stack trace. So it's unlikely that such a nullptr
issue is behind the problem:
C [libsystem_platform.dylib+0x1904] _platform_strlen+0x4
C [libnative-platform-file-events.dylib+0x6038] std::__1::char_traits<char>::length[abi:ue170006](char const*)+0x18
C [libnative-platform-file-events.dylib+0x6d54] std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::basic_string[abi:ue170006]<0>(char const*)+0x38
C [libnative-platform-file-events.dylib+0x4900] std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::basic_string[abi:ue170006]<0>(char const*)+0x24
C [libnative-platform-file-events.dylib+0xfe60] Server::handleEvents(unsigned long, char**, unsigned int const*, unsigned long long const*)+0x38
C [libnative-platform-file-events.dylib+0xfad0] handleEvent
from gradle.
I managed to reproduce on GitHub with a fork: https://github.com/lptr/kmp-viewmodel/actions/runs/9468537930
Crash logs: https://github.com/lptr/kmp-viewmodel/actions/runs/9468537930/artifacts/1590291032
It is an identical crash to #29482 with the same stacktrace, even though this happens on some machine under VMWare, while #29482 happens on a Mac mini.
from gradle.
Both of these are x86 machines, while IIRC, we only test on M1 Macs... 🤔
from gradle.
The crash on GitHub looks fully reproducible, 2 out of 2.
from gradle.
I couldn't reproduce on my M1 mac:
$ sw_vers
ProductName: macOS
ProductVersion: 14.5
BuildVersion: 23F79
$ system_profiler SPHardwareDataType
Hardware:
Hardware Overview:
Model Name: MacBook Pro
Model Identifier: MacBookPro18,2
Model Number: Z14V001TCD/A
Chip: Apple M1 Max
I also could not reproduce using an Intel Mac mini:
$ sw_vers
ProductName: macOS
ProductVersion: 14.5
BuildVersion: 23F79
$ system_profiler SPHardwareDataType
Hardware:
Hardware Overview:
Model Name: Mac mini
Model Identifier: Macmini8,1
Processor Name: 6-Core Intel Core i7
Processor Speed: 3.2 GHz
Also failed to reproduce with an M1 Mac mini running 13.5.1:
$ sw_vers
ProductName: macOS
ProductVersion: 13.5.1
BuildVersion: 22G90
$ system_profiler SPHardwareDataType
Hardware:
Hardware Overview:
Model Name: Mac mini
Model Identifier: Macmini9,1
Model Number: Z12N00006D/A
Chip: Apple M1
from gradle.
Looks to be working on GitHub with macos-12
and macos-13
, fails consistently with macos-11
:
https://github.com/lptr/kmp-viewmodel/actions/runs/9469263655/job/26087535440
from gradle.
With --no-watch-fs
the build works fine even on macos-11
: https://github.com/lptr/kmp-viewmodel/actions/runs/9469336253/job/26087758352
So that is a workaround we can offer for Gradle 8.8. Another workaround of course is to upgrade to macOS 12+. Unless there's a need for a specific macOS version, it's probably a good idea to use macos-latest
in GitHub workflows anyway.
That said...
It looks like there's some issue in macOS 10 and 11 with something the new file-system watching code we've introduced in #28259 relies on. It also seems that whatever the problem was has been fixed in macOS 12 and later. This might be something with the new GCD-based APIs for file-event subscriptions, or perhaps the issue is with the C++17 features we started using. 🤷 There certainly has been some back-and-forth with std::variant
in macOS 10.13 IIRC...
I see the following options going forward:
-
Revert #28259 and go back to the non-GCD watching.
We've introduced the GCD/C++17 watching in Gradle 8.8 because in macOS 13 the previous method of setting up file event listeners was deprecated. Reverting it would risk that a future macOS version will remove the deprecated APIs. This is not really an option.
-
Assuming the problem is with C++17 support, rewrite the code so we don't need to depend on C++17, but keep using the new GCD-based APIs for file watching.
This would be a significant amount of work, and would make our code worse, so I'm not a fan. That said, theoretically this could serve as a long-term solution.
-
Keep the code as is, but disable file-system watching automatically on macOS 11 and before.
This would be relatively simple to implement. We already do something similar with Alpine Linux (see #28258). It would be quite hard to test this, though, as we don't currently have means to run tests on macOS 11. We could rely on GitHub Actions, but integrating that into our testing is non-trivial.
-
Only document that macOS 11 and before do not support file-system watching, and ask users to run with
--no-watch-fs
manually.
Given the fact that macOS 11 (not to mention 10) has already reached end-of-life, I would definitely not invest into 2). 1) is not really an option. It's kind of tempting to choose 4)...
I can try to implement 3), but for the testing aspect it would still be a non-trivial change. OTOH, running tests on various macOS versions using GitHub sounds like a good feature to add. 🤔
If we choose to implement the auto-disabling feature, we'll need to release 8.8.1 with it.
from gradle.
We could implement the auto-disabling in https://github.com/gradle/native-platform, and then we could use its build to run tests using GitHub. That might be easier to integrate than if we tried to do the same with the gradle/gradle
build... 🤔
from gradle.
- It was reproduced by hoc081098/kmp-viewmodel#286.
- Here is the log: https://github.com/hoc081098/kmp-viewmodel/actions/runs/9435562255/job/25989141804?pr=286.
Could maintainers of Gradle please check it? Thank you so much 🙇 !
from gradle.
Relevant logs from #29482:
--------------- S U M M A R Y ------------
Command Line: --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED -Xmx2048m -Dfile.encoding=UTF-8 -Duser.country=IL -Duser.language=en -Duser.variant -javaagent:/Users/jenkins/.gradle/wrapper/dists/gradle-8.8-bin/dl7vupf4psengwqhwktix4v1/gradle-8.8/lib/agents/gradle-instrumentation-agent-8.8.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 8.8
Host: "Macmini6,2" x86_64 2300 MHz, 8 cores, 8G, Darwin 19.6.0, macOS 10.15.7 (19H2026)
Time: Mon Jun 10 15:58:33 2024 IDT elapsed time: 40.560627 seconds (0d 0h 0m 40s)
--------------- T H R E A D ---------------
Current thread is native thread
Stack: [0x0000700001aea000,0x0000700001b6a000], sp=0x0000700001b67298, free space=500k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libnative-platform-file-events.dylib+0x0] __dso_handle+0x0
C [libnative-platform-file-events.dylib+0x15c27] void std::__1::__variant_detail::__ctor<std::__1::__variant_detail::__traits<FileEvent, ErrorEvent, PoisonPill> >::__generic_construct[abi:v160006]<std::__1::__variant_detail::__copy_constructor<std::__1::__variant_detail::__traits<FileEvent, ErrorEvent, PoisonPill>, (std::__1::__variant_detail::_Trait)1> const&>(std::__1::__variant_detail::__ctor<std::__1::__variant_detail::__traits<FileEvent, ErrorEvent, PoisonPill> >&, std::__1::__variant_detail::__copy_constructor<std::__1::__variant_detail::__traits<FileEvent, ErrorEvent, PoisonPill>, (std::__1::__variant_detail::_Trait)1> const&)+0x47
C [libnative-platform-file-events.dylib+0x15b8a] std::__1::__variant_detail::__copy_constructor<std::__1::__variant_detail::__traits<FileEvent, ErrorEvent, PoisonPill>, (std::__1::__variant_detail::_Trait)1>::__copy_constructor(std::__1::__variant_detail::__copy_constructor<std::__1::__variant_detail::__traits<FileEvent, ErrorEvent, PoisonPill>, (std::__1::__variant_detail::_Trait)1> const&)+0x2a
C [libnative-platform-file-events.dylib+0x15b4d] std::__1::__variant_detail::__assignment<std::__1::__variant_detail::__traits<FileEvent, ErrorEvent, PoisonPill> >::__assignment(std::__1::__variant_detail::__assignment<std::__1::__variant_detail::__traits<FileEvent, ErrorEvent, PoisonPill> > const&)+0x1d
C [libnative-platform-file-events.dylib+0x15b1d] std::__1::__variant_detail::__move_assignment<std::__1::__variant_detail::__traits<FileEvent, ErrorEvent, PoisonPill>, (std::__1::__variant_detail::_Trait)1>::__move_assignment(std::__1::__variant_detail::__move_assignment<std::__1::__variant_detail::__traits<FileEvent, ErrorEvent, PoisonPill>, (std::__1::__variant_detail::_Trait)1> const&)+0x1d
C [libnative-platform-file-events.dylib+0x15aed] std::__1::__variant_detail::__copy_assignment<std::__1::__variant_detail::__traits<FileEvent, ErrorEvent, PoisonPill>, (std::__1::__variant_detail::_Trait)1>::__copy_assignment(std::__1::__variant_detail::__copy_assignment<std::__1::__variant_detail::__traits<FileEvent, ErrorEvent, PoisonPill>, (std::__1::__variant_detail::_Trait)1> const&)+0x1d
C [libnative-platform-file-events.dylib+0x15abd] std::__1::__variant_detail::__impl<FileEvent, ErrorEvent, PoisonPill>::__impl(std::__1::__variant_detail::__impl<FileEvent, ErrorEvent, PoisonPill> const&)+0x1d
C [libnative-platform-file-events.dylib+0x15a8d] std::__1::__variant_detail::__impl<FileEvent, ErrorEvent, PoisonPill>::__impl(std::__1::__variant_detail::__impl<FileEvent, ErrorEvent, PoisonPill> const&)+0x1d
C [libnative-platform-file-events.dylib+0x15a5d] std::__1::variant<FileEvent, ErrorEvent, PoisonPill>::variant(std::__1::variant<FileEvent, ErrorEvent, PoisonPill> const&)+0x1d
C [libnative-platform-file-events.dylib+0x15a2d] std::__1::variant<FileEvent, ErrorEvent, PoisonPill>::variant(std::__1::variant<FileEvent, ErrorEvent, PoisonPill> const&)+0x1d
C [libnative-platform-file-events.dylib+0x15a01] void std::__1::allocator<std::__1::variant<FileEvent, ErrorEvent, PoisonPill> >::construct[abi:v160006]<std::__1::variant<FileEvent, ErrorEvent, PoisonPill>, std::__1::variant<FileEvent, ErrorEvent, PoisonPill> const&>(std::__1::variant<FileEvent, ErrorEvent, PoisonPill>*, std::__1::variant<FileEvent, ErrorEvent, PoisonPill> const&)+0x21
C [libnative-platform-file-events.dylib+0x13805] void std::__1::allocator_traits<std::__1::allocator<std::__1::variant<FileEvent, ErrorEvent, PoisonPill> > >::construct[abi:v160006]<std::__1::variant<FileEvent, ErrorEvent, PoisonPill>, std::__1::variant<FileEvent, ErrorEvent, PoisonPill> const&, void>(std::__1::allocator<std::__1::variant<FileEvent, ErrorEvent, PoisonPill> >&, std::__1::variant<FileEvent, ErrorEvent, PoisonPill>*, std::__1::variant<FileEvent, ErrorEvent, PoisonPill> const&)+0x25
C [libnative-platform-file-events.dylib+0x133ef] std::__1::deque<std::__1::variant<FileEvent, ErrorEvent, PoisonPill>, std::__1::allocator<std::__1::variant<FileEvent, ErrorEvent, PoisonPill> > >::push_back(std::__1::variant<FileEvent, ErrorEvent, PoisonPill> const&)+0x6f
C [libnative-platform-file-events.dylib+0x1336d] std::__1::queue<std::__1::variant<FileEvent, ErrorEvent, PoisonPill>, std::__1::deque<std::__1::variant<FileEvent, ErrorEvent, PoisonPill>, std::__1::allocator<std::__1::variant<FileEvent, ErrorEvent, PoisonPill> > > >::push[abi:v160006](std::__1::variant<FileEvent, ErrorEvent, PoisonPill> const&)+0x1d
C [libnative-platform-file-events.dylib+0xd9d2] BlockingQueue<std::__1::variant<FileEvent, ErrorEvent, PoisonPill> >::enqueue(std::__1::variant<FileEvent, ErrorEvent, PoisonPill> const&)+0x32
C [libnative-platform-file-events.dylib+0xd809] Server::handleEvents(unsigned long, char**, unsigned int const*, unsigned long long const*)+0xb9
C [libnative-platform-file-events.dylib+0xd441] handleEventsCallback(__FSEventStream const*, void*, unsigned long, void*, unsigned int const*, unsigned long long const*)+0x41
C [FSEvents+0x2993] implementation_callback_rpc+0xb19
C [FSEvents+0x1dfe] _Xcallback_rpc+0xe9
C [FSEvents+0x1cf7] FSEventsD2F_server+0x37
C [FSEvents+0x1c61] __create_d2f_port_source_block_invoke+0xe8
C [libdispatch.dylib+0x2658] _dispatch_client_callout+0x8
C [libdispatch.dylib+0x4818] _dispatch_continuation_pop+0x19e
C [libdispatch.dylib+0x144be] _dispatch_source_invoke+0x824
C [libdispatch.dylib+0x7af6] _dispatch_lane_serial_drain+0x107
C [libdispatch.dylib+0x85d6] _dispatch_lane_invoke+0x16b
C [libdispatch.dylib+0x11c09] _dispatch_workloop_worker_thread+0x254
C [libsystem_pthread.dylib+0x2a3d] _pthread_wqthread+0x122
C [libsystem_pthread.dylib+0x1b77] start_wqthread+0xf
from gradle.
If the two issues are the same problem, then we have a reproducer both on macOS 10.15.7 (#29482) and macOS 11.7.10 (this issue)
from gradle.
GitHub build for native-platform
:
Not sure when I'll have the time to finish this, but it runs now.
from gradle.
Looks like #29514 fixes the problem: https://github.com/lptr/kmp-viewmodel/actions/runs/9479024243/job/26116663434#step:7:34
Disabling file system watching on macOS 11.7.10, as it is only supported for macOS 12+
Using 3 worker leases.
Configuration on demand is an incubating feature.
Received JVM installation metadata from '/Users/runner/hostedtoolcache/Java_Zulu_jdk/21.0.3-9/x64': {JAVA_HOME=/Users/runner/hostedtoolcache/Java_Zulu_jdk/21.0.3-9/x64, JAVA_VERSION=21.0.3, JAVA_VENDOR=Azul Systems, Inc., RUNTIME_NAME=OpenJDK Runtime Environment, RUNTIME_VERSION=21.0.3+9-LTS, VM_NAME=OpenJDK 64-Bit Server VM, VM_VERSION=21.0.3+9-LTS, VM_VENDOR=Azul Systems, Inc., OS_ARCH=x86_64}
Watching the file system is configured to be enabled if available
File system watching is inactive
from gradle.
Related Issues (20)
- Publish latest commit included in the nightly build HOT 1
- Discourage or deprecate detached configurations HOT 6
- CachingTaskInputFileCollection loose relative path sensitivity
- Create release notes for the new Java compiler integration with the Problems API
- Wrong information about removing unintentional subprojects HOT 3
- Formatting should be the same with JDK8 compiler reports as with other compilers HOT 1
- Allow configurations to be safely resolved from outside of owning scope HOT 1
- Gradle 7+ "force" changes cause a different resolution behavior HOT 3
- Deprecate running Gradle on JVM versions < 17
- Add mechanism for different package managers to contribute their installed JVM toolchains HOT 2
- Task dependency inference doesn't work for named domain object containers HOT 1
- Idea plugin is not IP compatible when configured directly
- `unreportedProblemInCurrentCall` error when using configure action
- Allow Configuration Cache for TAPI requests without Isolated Projects HOT 1
- Problem description copied from the CC report is noisy and ill-formatted HOT 2
- Let providers handle task and transform dependencies uniformly everywhere
- API for adding LICENSE.txt file to published JAR (and other artifacts) HOT 3
- Simple custom interceptors for bytecode upgrade don't allow to upgrade any type
- Gradle build fails with an error on sync with Configuration Cache
- GradleRunner race condition: Cannot access input property 'sources' of task HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gradle.