151–160 of 160 posts
Earlier quoted context omitted.
> There was no conceivable version of a road system where that behavior would ever be okay. That doesn't mean it doesn't happen. Are you suggesting that the approach taken here was at one point a documented acceptable approach, according to Apple?
According to UNIX, which MacOS is certified of being.
Earlier quoted context omitted.
It said it affected back to Java 8, so seems like this design has been there for a while, and since older versions are EOL, any Java level fix would not be patched back.
I wonder what that means for the Android SDK, which AFAIK requires an ancient Java8 runtime for the command line SDK tools on macOS.
And on the SDK side, they need to use whatever InteliJ requires.
Earlier quoted context omitted.
So MacOS is trying to be smart, changes their API, and now we're blaming the JVM for doing something we don't understand? At least they could have provided a path back to the old behavior.
macOS is trying to keep its systems safe. Can’t leave the back door open for few who were used to it.
> macOS on Apple silicon processors (M1, M2, and M3) includes a feature which controls how and when dynamically generated code can be either produced (written) or executed on a per-thread basis. […] With macOS 14.4, when a thread is operating in the write mode, if a memory access to a protected memory region is attempted, macOS will send the signal SIGKILL instead. This isn’t just any old thread triggering SIGKILL, i…
Or in apple vernacular, it should just work.
This also bothers me on Android. Sometimes, an app update may break something and prevent me from using it. But Google doesn't allow me to reinstall a previously published version from the Play Store. If I don't have to (or can't easily) do without that application until a fix might be released, my only option is to find an older release on some shady mirror site.
Earlier quoted context omitted.
>It's not a problem that breaks all JVM based software instantly. Do you know how long it takes to reproduce? The OP was light on details here. I assume that a memory access issue with the JIT would pop up pretty quickly, though.
I'm running an Eclipse development environment that's regularly compiling a huge codebase. Had 2 crashes this week after updating so less than once a day. That's assuming it isn't an Eclipse bug ;)
Earlier quoted context omitted.
I'm running an Eclipse development environment that's regularly compiling a huge codebase. Had 2 crashes this week after updating so less than once a day. That's assuming it isn't an Eclipse bug ;)
Just being curious: With or without having created a hs_err_pid .log? Why do I ask: Ten days now on 14.4. and cannot see any change in Eclipse and Tomcat behaviour.
Earlier quoted context omitted.
As Linus famously said: Shut. Up. Don’t break userspace and then blame the user. https://lkml.org/lkml/2012/12/23/75
Linux did break adobe flash when it used memmove like memcopy after fixing a kernel bug. Can't think of any other examples though.
It is always funny to Me when Apple zealots come into threads blaming everyone but Apple that software broke. Complaining Java doesn’t follow Apple standards or some crap. Then 9 days later Apple issues a fix because they did indeed break it.
Can you tell from this or any other Oracle bug whether Apple is bending its rules for Java? I can't tell either way.