Apple brengt macOS 14 Sonoma-update uit die Java-crashes moet verhelpen

Apple heeft maandag macOS Sonoma 14.4.1 uitgebracht. De update lost een aantal bugs met macOS Sonoma 14.4 op, waaronder een bug die Java-apps laat crashen. Ook voor macOS Ventura is een patch uitgebracht.

De update voor Sonoma lost volgens Apple een probleem op waardoor USB-hubs die op een extern beeldscherm zijn aangesloten, niet worden herkend. Daarnaast wordt een probleem verholpen waardoor Audio Unit-plug-ins voor professionele muziekapps niet geopend kunnen worden. Ten slotte wordt een probleem opgelost dat apps met Java onverwachts doet stoppen.

Apple brengt met macOS Sonoma 14.4.1 ook twee veiligheidsoplossingen uit. Daarmee worden twee ‘klikloze’ exploits opgelost. Die maken het mogelijk om op afstand code uit te voeren zodra een gecompromitteerde afbeelding wordt geopend. Voor gebruikers die nog niet hebben geüpgraded naar Sonoma, heeft Apple deze patch ook uitgebracht voor macOS Ventura.

Reacties (62)

[dwizsel]

Ik vroeg me al af waarom IntelliJ om de zoveel tijd plots crashte. Ik was de oorzaak al aan het zoeken bij IntelliJ zelf maar het ligt dus aan MacOS... Goed dat het opgelost is!

[Gropah]

Mocht je wat uitleg willen waarom intellij (en andere java apps) crashden.

tldr; Apple besloot om na het beschikbaar stellen van de laatste beta een signal aan te passen, waarmee ze ook (op dit punt) niet meer voldoen aan de POSIX standaard.

[ari3]

Enshitification en vendor-lockin van Apple: iets wat ontwikkelt wordt op een Apple OS kan niet zonder rework naar een BSD of Linux OS overgezet worden.

Ik hoop dat Apple die wijziging terugdraait en signals gewoon POSIX-compliant maakt/houdt. Wat in elk geval niet mag is de JVM aanpassen om dit soort fratsen te faciliteren. Afwijken van POSIX maakt applicaties moeilijk(er) porteerbaar en scriptbaar.

[latka]

Lol. Wat roken ze daar bij Apple: SIGSEGV in SIGKILL omzetten tussen de laatste beta en de RC versie. Dat is een beetje als een auto bouwen en testen en dan 1 dag voor het in de showroom zetten de wielen vervangen door bakstenen en dan klagen dat de wegligging zo beroerd is.

[angulardragon03]

Was eigenlijk niet zo - ze hebben het in beta 4 toegevoegd, maar Oracle heeft deze beta dus niet getest .
(Er is wat C broncode in de oorspronkelijke Oracle bugreport waarmee je dit kan zien)

[RetepV]

Op zich is er wel wat voor te zeggen om SIGSEGV en SIGBUS niet meer te honoreren. Deze signals zeggen iets over low-level systeemzaken (resp. aanspreken van beschermd geheugen en aanspreken van niet-bestaand geheugen). Die horen niet thuis in een gevirtualiseerd systeem, waar er een HAL (Hardware Abstraction Layer) is. Strict gesproken behoren die signals in de HAL te blijven en niet in de applicatielaag terecht te komen.

Ook ombuigen van die signals naar een SIGKILL is in dit licht niet zo gek. Als een applicatie boven op een HAL draait, dan zou het onmogelijk moeten zijn om beschermd of niet-bestaand geheugen te adresseren. Sowieso zou een goed geschreven programma dat nooit per ongeluk doen, alleen expres (maar dan praat je al over een poging om te hacken).

SIGKILL is iets anders. Nadat een app een SIGKILL krijgt, krijgt je app nog even de tijd om wat administratie te doen zodat het de volgende keer weer goed zal opstarten en er geen cruciale informatie verloren gaat. Ik gebruik dat vaak in mijn iOS apps, waar het OS je app zelfs zonder enige fatsoenlijke reden een SIGKILL kan sturen omdat het vindt dat er geheugen vrijgemaakt moet worden.

SIGSEGV en SIGBUS zijn hooguit handig om zelf wat memory management op app-niveau te gaan doen. Waarom zou je dat nog doen als de HAL zelf daar al heel goed in is? Sowieso: als een userland app een SIGSEGV of SIGBUS kan uitlokken, dan is er imo toch al iets mis met de A van de HAL.

Dus ik vind de beslissing helemaal niet zo gek, eigenlijk. Als er een SIGSEGV of SIGBUS wordt gegenereerd, stuur je een SIGKILL naar de app. De app kan dan snel zijn administratie doen, dood gaan en dan opnieuw starten. Als er een SIGSEGV of SIGBUS wordt gegenereerd, is er sowieso iets niet ok.

[Gropah]

Als je het nu nieuw zou ontwerpen zou het wellicht wel gek zijn. Maar dit is iets wat over meerdere OS'en gaat, en wat al sinds de jaren 80 zo is volgens mij, en dus onderdeel van POSIX. Daarom zijn applicatie's er vanuit gegaan dat het werkt zoals het nu werkt (deels ook vanwege performance). Dat zomaar aanpassen, is echt niet ok.

[RetepV]

Helemaal mee eens hoor. Je bent helemaal POSIX of niet.

Ik vraag me af wat dit gaat doen voor de status van Macos als "UNIX® Certified Product".

Op opengroup zie ik vooralsnog alleen Macos Sonoma 14.0 staan.

https://www.opengroup.org/openbrand/register/

POSIX.1-2017 is onderdeel van de certificatie.

https://pubs.opengroup.or...s/9699919799.2018edition/

[Reactie gewijzigd door RetepV op 22 juli 2024 23:50]

[DDX]

Zijn er nog mensen die java apps gebruiken dan ?

[OverSoft]

Ja. Veel ontwikkel tools draaien op Java, zoals alle Jetbrains ontwikkelomgevingen (zoals PHPStorm, Pystorm, Webstorm, Android Studio, etc...), daarnaast is Android ontwikkeling vrijwel volledig afhankelijk van Java ontwikkel en compile tools.

[jctjepkema]

Eclipse is ook geschreven in java als ik het goed heb. Ook een veel gebruikte omgeving, zei het niet in een ander jasje zoals sommige fabrikanten doen, denk aan STM32CubeIde.

[Jeanpaul145]

Het verbaast me dat het nog veel wordt gebruikt.
In het begin van de 2010s was er wel wat alternatief maar niet extreem veel, en dat is nu anders.
Daarbij waren mijn ervaringen met Eclipse altijd om te huilen. Constant crashes, configuraties die vanzelf kapot gingen (zonder Eclipse te updaten overigens), noem het maar.
De enige reden dat ik destijds niet naar 1 van de alternatieven overstapte was dat er een plugin van de groep van m'n universiteit was die een beetje hard nodig was voor m'n studie.
Gelukkig ben ik sindsdien allang daarvan af, en het leven is alleen maar beter geworden sinds ik Eclipse bij het grofvuil heb gedaan

[Reactie gewijzigd door Jeanpaul145 op 22 juli 2024 23:50]

[jctjepkema]

wat een vreselijke IDE is dat zeg. Ik heb er ook helemaal niks mee, en alleen maar slechte ervaringen gehad. Debuggen van ST chips gaat er heel erg fijn in, vandaar dat wij het nog wel eens gebruiken, maar op mijn werk hebben we de overstap gemaakt naar VSCode met een reeks plugins en devcontainers. Dat laatste was een grote wens vanuit mij. We hebben hiermee bij iedereen de image en bouwomgeving op dezelfde versie, met een mooie integratie met debuggen. Dat werkt wel ontzettend mooi.

Met VSCode heb ik ook nog wel eens crashes, gek genoeg heb ik die vooral op WIndhoos en niet tot nauwelijks op Linux of MacOS. Maar eclipse nooit meer.

[Jeanpaul145]

Ik dreig hier m'n leeftijd te tonen, maar denk er eens over na om Emacs of Neovim te proberen.

Neovim is zoals de naam doet vermoeden een nieuwe implementatie van vim (wat weer een herimplementatie was van vi). Ideaal voor quick edits en voor mensen die een modal interface heerlijk vinden.

Emacs is echter een interessante. De core is hetzelfde als 30 naar geleden (het is wss 1 van de langstlopende software projecten met een commit history ter wereld, langer dan zelfs de Linux kernel), maar er zijn zoveel innovaties bijgekomen dat het bijna onherkenbaar is geworden. Het is veel sneller dankzij native Elisp compilation, tree-sitter support doet weg met regexes voor syntax highlighting en is daarmee veel flexibeler en sneller, er zijn themes, er zijn meerdere "stores" (MELPA) voor extensies (tussen aanhalingstekens omdat alles free als in freedom én beer is), je kan natively compiled shared object files loaded als je dat wil, het heeft een debugger, de lijst gaat maar door. En oja, het is ook platformonafhankelijk én stabiel
Het kan zich qua features prima meten met de rest en is daarmee gewoon een modern stuk software.

[jctjepkema]

ik ga mij maar eens verdiepen in emacs

Het is qua footprint al een stuk kleiner dan vscode maar voorlopig kunnen en willen wij niet zonder de docker integratie van VSCode wat mij doet vermoeden dat we daar voorlopig nog wel even aan vast zitten.

[OverSoft]

VSCode draait op Electron, wat in feite gewoon een Javascript applicatie in een volledige Chromium browser is, wat ook ernstig overkill is.

Eclipse is ook achterhaald, maar de Jetbrains suite werkt wel echt fijn.

[jctjepkema]

ja fair point, ook absoluut overkill. Toch heeft dat deel van javascript ook wel voordelen, zoals dat het daardoor prima in een browser kan draaien. Zo heb ik een server op mijn build-server draaien waar ik op in kan loggen.

[OverSoft]

Je snapt dat dat met Java ook het geval is he?

[jctjepkema]

Je bedoelt dat ik dan naar de webpagina van mijn server kan gaan en de java window in beeld kan krijgen in mijn browser? Ik wist niet dat zoiets zou kunnen.

Of bedoel je dat ik met ssh de window op mijn lokale systeem kan zien?

[OverSoft]

Dat eerste. Java is inherent een verbonden platform. De meeste UI libraries zijn direct uitwisselbaar tussen een native GUI of een web omgeving.

Uiteraard moeten de ontwikkelaars van de IDE dat wel ondersteunen.

[jctjepkema]

Tsja, zolang dat niet ondersteund wordt aan die kant, en er wel zoiets is als dit: https://github.com/gitpod-io/openvscode-server

Dan kies ik toch voor vscode, zeker met de configuraties die ik heb aangemaakt en in al mijn projecten gebruik.

[OverSoft]

Dus wordt het ondersteund door VSCode.

Maar goed, ieder zijn voorkeur natuurlijk. Ik zit zelf helemaal ingebakken in Jetbrains IDE's.

[jctjepkema]

Maar je zegt zelf eerder dat electron apps een combo zijn van een chromium browser met javascript. Dat is als ik het goed zeg, wezenlijk anders dan java.
Chromium is volgens mij in c/c++ en assembly geschreven.

Ach, maar goed dat ik vooral embedded electronica SW schrijf en niets met Java doe, ik begrijp er duidelijk niks van.

[OverSoft]

Ja, dat is wezenlijk anders, dat klopt. Daar zei ik ook niets over. Ik bedoelde dat de ontwikkelaars van VSCode zelf het web gedeelte ondersteunen.

Electron is een combinatie van Chromium + Node.js. (waarin een JavaScript + HTML5 app draait)
Het is relatief eenvoudig (tenzij er spannende dingen gebeuren via de Node.js API) om de app uit de engine te trekken en deze zelf te hosten en te benaderen via een browser.

Java is... Java. (waarin een Java applet draait)
De Java app zelf bepaalt wat de UI is. Deze kan een "fysieke" lokale GUI zijn, maar ook een webpagina.
Bij veel GUI libraries kun je simpelweg met 1 flag de app als web applicatie publiceren, maar dit MOET de ontwikkelaar zelf doen (tenzij je bytecode gaat recompilen).

[OverSoft]

Er is geen 1 Java GUI, je kan gewoon een GUI library kiezen.

Jetbrains applicaties werken exact hetzelfde als native applicaties.

[vgroenewold]

Niet echt veel dan, ik ken JavaFX (erg meh gezien er nauwelijks ontwikkeling is) en het standaard gebeuren. Het is wel aan te passen zodat het er modern uitziet.

[OverSoft]

Swing, JavaFX, AWT, SWT, LibGDX, Spring, Play, Grails, JSF, Google Web Toolkit

Om er maar een paar te noemen.

[Single_Core]

momenteel denk ik niet dat je het verschil zal merken tussen die apps en native apps. Die werkt volledig normaal en vlot.

[_Pussycat_]

Gebruik GANTTchart tegenwoordig, loopt onder Java, en is enorm lelijk en vrij langzaam (maar toch een goed genoeg gratis alternatief voor MS project voor mij).

[P1nGu1n]

Veel ontwikkelaars. Iedereen die een Jetbrains IDE gebruikt, zoals IntelliJ, WebStorm, PyCharm of CLion. Iedereen die Android apps ontwikkelt. Iedereen die Java backends of applicaties ontwikkelt.

[pBook]

JetBrains IDEs

[armageddon_2k1]

Is gewoon nog een van de meest gebruikte talen en platforms.

[McBacon]

Ghidra. ;]

[Cobalt]

Heel veel webapplicaties zijn in Java. Dan het deel wat op de server draait. En die ontwikkelaars draaien het op hun macbook

[Florimon]

Niet alleen webapplicaties. Je wil niet weten hoeveel backend Java applicaties er draaien bij alleen al alle banken in Nederland. Zelfde met de belastingdienst, telecomproviders, energie sector etc.

[TommieW]

Jazeker, hoewel niet altijd vrijwillig. Denk aan software van fabrikanten, zoals om kaarten van je navigatiesysteem te downloaden.

[Frame164]

Grote kans dat jouw bericht door heel veel Java applicaties is gegaan voordat het hier gepubliceerd werd.

[Cilph]

Tweakers draait op PHP maar mogelijk ergens wie weet. Het is wel correct dat veel webapplicaties werken met Java op de achtergrond.

[DDX]

Ja maar over het algemeen draaien die servers niet op macOS.

[Keypunchie]

Nee, maar veel van de ontwikkelaars van die webapplicaties hebben wel een Mac.

Daar zat de meeste pijn. In mijn directe omgeving wel een paar ontwikkelaars gehad "hmmm, waarom is mijn IDE gecrashed"?.

[mixp]

review: Tweakers 7: waarom een eigen Java-back-end?

Ook Java bij Tweakers dus

[pumpidumpi]

PHP kan in de Java vm draaien

[Ryur]

En de VOIP van ons werk draait ook op Java: Xelion.

[k995]

Ja, start een paar apps op mijn mac mini die dient als server.
Ja zou ik in docker containers kunnen doen (en heb ook even gedaan) maar dan moet ik uitzoeken hoe dat deftig werkt (updates, backups,...) en daar heb ik momenteel geen zin in.

[bzzzt]

Zijn er nog mensen die java apps gebruiken dan ?

Minecraft?

[tom.cx]

Zeker, mijn favoriete game, Minecraft, draait op java en ik heb dit weekend meerdere meldingen gehad over java crashes.

[jmvdkolk]

Java apps weet ik niet. Maar Java is één van de meest gebruikte programmeertalen in de wereld. De bancaire wereld is op dit moment druk bezig om van Cobol naar Java over te stappen. De keuze is gevallen op Java omdat er ontzettend veel developers voor te vinden zijn, en ook omdat het heel goed cross-platform is. Het gaat hier wel alleen om server applicaties. Het gaat niet om apps die jij zelf gebruikt.

[dvdmeer]

Ik hoop dat er ook snel een fix komt voor mijn bluetooth Logitech muis die nu regelmatig de connectie kwijt is. Als ik dan vervolgens naar mijn bluetooth instellingen ga, dan wordt de connectie weer hersteld en dan werkt deze weer een tijdje. Extreem irritant en op een of andere manier gaat dit fout sinds de 14.4 update.

[Sleepkever]

Je hebt best wel eens kans dat dat met dezelfde update verholpen is. Het probleem was het grootst onder Java maar speelde ook bij veel andere dingen. USB hubs, printers, usb hardware keys, etc. Dus ik zou de update zeker even proberen.

[jacobkap]

Ik heb dit probleem ook, maar dan met alle Bluetooth devices. Meerdere keren per dag, plots alle bluetooth devices disconnected. Koptelefoon, toetsenbord, muis. En de muis is zelfs nog Apple merk.

Oplossing voor mij is om Bluetooth volledig uit te zetten en weer aan te zetten. Maar inderdaad, vreselijk irritant.

[TheVivaldi]

Ik vraag me alleen af of dat dan aan Apple ligt. Ik heb datzelfde probleem namelijk sinds een tijdje op Linux, maar dan vooral met mijn Marshall Kilburn-speaker. Ligt het niet gewoon aan de ouderdom of iets dergelijks?

[jacobkap]

M1 MacBook Pro (2021), KeyChron toetsenbordje uit 2020 en een koptelefoon uit 2019. Lijkt me geen ouderdom. Bovendien een Apple Magic Mouse (v2 volgens mij). Lijkt me vreemd als het aan de ouderdom van mijn devices ligt, als het resultaat is dat letterlijk alles in 1x disconnect.

[Reactie gewijzigd door jacobkap op 22 juli 2024 23:50]

[StefandeGroot]

Deze had ik gisteravond meteen geïnstalleerd. Meteen spijt van. Mijn Samsung M7 monitor werkt nu niet meer via USB-C.

Via een omweg heb ik die nu werkende kunnen krijgen als tijdelijke oplossing. Hopelijk komt Apple snel met een bugfix om dit weer op te lossen.

[bones]

Hopelijk ook een patch die hoge cpu/fan noise fixed met google chrome. Voor de update nooit last gehad met google chrome. Na de update gaan de fans loeien zodra ik chrome open (zelfs met 1 tab).

[Dreamvoid]

Ik hoop dat ze ooit nog de langdurige bug met Samsung tv's kunnen oplossen, is nu al jaren een vervelende issue. Met een directe HDMI-HDMI verbinding wordt het scherm niet meer wakker nadat de Mac het scherm in standby zet, maar via een USB3->HDMI dongle gaat de tv wel aan. Diverse firmware updates van Samsung, diverse van Apple, maar niets helpt.

[latka]

USB3 naar HDMI dongle? Die ken ik niet. Of het is USB alternate Displayport naar HDMI of het is een GPU met een USB aansluiting. Ik vermoed het 1e. Daar heb ik ook verschillende ervaringen mee (oa. met een intel Nuc). Wat hielp was de USB naar Displayport te doen en dan verschillende Displayport naar HDMI oplossingen te gebruiken (beetje trial en error dus). In mijn geval niet met een Samsung maar met een Panasonic tv.

[Dreamvoid]

Het probleem is niet die dongle (USB-C docking station), daar werkt het juist wel mee - native HDMI port op de MIni naar HDMI op de tv geeft de bug.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 23:50]

[RetepV]

Pff, ik heb ook alleen maar problemen met het wakker maken van mijn Samsung monitor. Ik gebruik hem via een USB-C hub.

Als mijn Macbook wakker wordt en merkt dat het externe scherm er is, breidt hij de desktop uit naar het externe (Samsung) scherm).

Het Samsung scherm merkt dan dat er iets aan de hand is en wordt wakker. Maar het duurt even voordat de twee desktop gerendered wordt, een paar seconden. En intussen denkt het Samsung scherm: "meh, voor niks wakker geworden, ik ga weer slapen.". Scherm wordt zwart, en Macbook schakelt weer terug naar 1 monitor.

Vervolgens merkt mijn Macbook dat er toch wel echt een externe monitor aangesloten is en probeert het opnieuw. Vervolgens wordt het hele riedeltje opnieuw afgespeeld.

En dat gaat zo door tot mijn Samsung net even te lang doet over het weer in slaap vallen en mijn desktop dan eindelijk getoond wordt.

Ik kan de verbinding sneller forceren door tijdens het omschakelen naar uitgebreide desktop de Samsung wakker te houden door te blijven schakelen tussen HDMI1->HDMI2->DP->HDMI1->etc. Totdat de Macbook klaar is met omschakelen, en de monitor vanzelf naar HDMI1 springt (waar de Macbook op zit).

Ook nog een probleem dat als de monitor op DP verbonden is, ik dan wel 4K 60Hz heb, maar het scherm regelmatig een paar seconden zwart flitst. Heel irritant. Dus zit ik op HDMI met 4K 30Hz te werken (software development). Wel veel lag, maar minder irritant dan zwarte flitsen. Ik gebruik hem niet voor games.

Het probleem is volgens mij de Samsung. Goedkope kabels, dure kabels, niets helpt. Macbook 2016 heeft ongeveer dezelfde problemen als Macbook 2021. Maar geen van beide hebben problemen met monitoren van andere merken die ik geprobeerd heb.

[Helox-in-a-box]

De update voor Sonoma lost volgens Apple een probleem op waardoor USB-hubs die op een extern beeldscherm zijn aangesloten, niet worden herkend.

Verklaart waarom camera en keyboard het niet meer deden, alleen na een reboot enige tijd, mooi dat het is opgelost met deze update.