In deel 1 van deze blogreeks vertelde ik hoe ik Claude Code als mijn persoonlijke sysadmin gebruik. In deel 2 hielp Claude me met het oplossen van een probleem bij geïnstalleerde software, en dat ging erg goed! Maar het kan ook heel anders gaan...
Welke IDE gebruik jij? Sinds jaar en dag is deze vraag het perfecte beginpunt geweest om een ruzie te starten tussen twee developers.
Ik begon mijn IDE-reis bij BlueJ, net als mijn medestudenten. Of, wellicht, afhankelijk van je definitie van een IDE, begon ik rond 2001 al met RM2K. Ik eindigde uiteindelijk rond 2013 bij de JetBrains-producten. In de tussentijd had ik behoorlijk wat IDE's geprobeerd: Van CodeBlocks, Netbeans, Eclipse, Visual Studio tot natuurlijk Vim en Emacs. Ik heb zelfs een periode gehad waarin ik vooral text-editors gebruikte, zoals Sublime, Notepad++ en zelfs de originele Notepad. Puur om het zonder hulpmiddelen écht goed te leren.
Maar uiteindelijk eindigde ik dus bij de verschillende JetBrains-producten, zoals PHPStorm. Ik ben natuurlijk bekend met alle kritiek en pijnpunten die de software heeft, maar toch heb ik het altijd beschouwd als hele mooie, goedwerkend en krachtige software. De IDE was uiteraard niet perfect, maar wel ongelooflijk goed, en sloot regelmatig aan op mijn eigen werkwijze. En ik beschouw het echt wel als een knap stukje vakmanschap.
Ik vind het daarom jammer om te zien dat die vele gepolijste features langzaam hun nut verliezen en vervangen worden door AI. Waarschijnlijk is dat vergelijkbaar met de komst van de auto. Het was een technologische sprong voorwaarts, maar wel een teleurstelling voor alle zadel-liefhebbers, die hierdoor plotseling met een prachtig, maar overbodig product in hun handen stonden.
Soms moet je gewoon echt mee in de verandering, hoe jammer het ook is.
Ik gebruik dus bijvoorbeeld PHPStorm nog maar zelden. Ik open hem met name om wat code te lezen of te vergelijken. Misschien had PHPStorm het door, en werd ie jaloers. Want op een ochtend besloot-ie blijkbaar dat het genoeg was. Het ene moment stond PHPStorm nog open op mijn computer, en het andere moment was-ie verdwenen.
Mijn eerste gedachte was: Hm? Vreemd, ik zie PHPStorm nergens meer staan in de taakbalk? Zou ik het per ongeluk hebben afgesloten? Nou goed, even weer opnieuw starten dan.
Maar er gebeurde niks.
Dan maar een kijkje nemen in het syslog:
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0x00007dcd591bc0be, pid=9626, tid=9856
JRE version: OpenJDK Runtime Environment JBR-21.0.9+10-1163.94-jcef (21.0.9+10) (build 21.0.9+10-b1163.94)
Dat klinkt niet goed. Tijd dus om mijn persoonlijke sysadmin te vragen waarom PHPStorm zo boos is.
Claude debugging
Het krachtige aan Claude is de snelheid waarmee dit soort taken kunnen worden uitgevoerd (in vergelijking met de snelheid van een mens). In korte tijd ondernam Claude sequentieel de volgende stappen:
- De inhoud bekijken van de PHPStorm-cachedirectory
- Kijken of er nog andere PHPStorm-processen draaiden
- Die processen killen (wat vervolgens niet lukte, want het proces was verdwenen)
- De cache directory weggooien
Dit ging allemaal bijzonder snel. En daarna kondigde Claude vol vertrouwen aan dat-ie het probleem had gevonden (de cachedirectory was corrupt geraakt) en dat het nu opgelost was! Dat ging razendsnel, maar... die snelheid gaat niet altijd gepaard met de juiste conclusie.
Ik had al direct mijn twijfels bij die conclusie. En door de jaren heen heb ik wel geleerd om dat onderbuikgevoel veel waarde te geven, want dit is toch een intuïtie die je ontwikkelt op basis van veel ervaring. En mijn gut feeling werd bevestigd: PHPStorm startte nog steeds niet. Dus Claude wederom vriendelijk gevraagd om verder te onderzoeken.
Nee Claude, dat denk ik niet...
Parallel
Claude Code is niet alleen sequentieel snel, maar kan ook verschillende taken parallel uitvoeren. Na het stellen van de vraag had hij binnen de kortste keren van alles uitgevoerd:
**Actions taken (in parallel):**
- Read the crash log `/home/r/java_error_in_phpstorm_14477.log` (first 100 lines)
- Checked current PhpStorm processes
- Checked journal entries for PhpStorm from the last 5 minutes
**Findings:**
- The crash stack trace showed `LinuxIconThemeConfiguration.loadStateFromOs()` →
`X11UiUtil.getIconTheme()` → `ProcessImpl.forkAndExec()` → `jni_GetByteArrayElements` crash
- The journal revealed **three consecutive crashes** (pids 13622, 13829, 14477), all with the same SIGSEGV in `jni_GetByteArrayElements`
- A 4th launch (pid 15015) also crashed, this time in `libc.so.6` with timeout during error reporting
**Actions taken (in parallel):**
- Killed stuck process 15015
- Read the vmoptions file (`~/.config/JetBrains/PhpStorm2025.3/phpstorm64.vmoptions`)
- Read crash log for pid 15015
Wederom dus in snel tempo veel informatie verzameld. En het probleem was Claude nu helemaal
duidelijk: libc6 was upgraded from 2.39-0ubuntu8.6 to 2.39-0ubuntu8.7. JBR, JetBrains Runtime, de Java runtime van
JetBrains, had een bug waardoor het niet goed kon werken met deze runtime.
De conclusie: OpenJDK installeren, via de normale Ubuntu (apt) repository, want die is wel up-to-date. En dan een setting aanpassen, zodat PHPStorm die gebruikt. Dus, als je even toestemming wilt geven aan mij om OpenJDK te installeren?
Geen goed idee
Wacht even - ik denk dat Claude hier weer iets te hard van de stapel loopt.
Ten eerste heb ik wederom sterk mijn twijfels dat dit het probleem is. Mijn instinct zegt dat dit het niet op gaat lossen. Maar nog erger: deze wijziging gaat een bende aan zooi naar binnen brengen op mijn mooie schone systeem. Zie dat daarna maar weer op te ruimen.
Maar zelfs als het werkt: dan zit je alsnog met een OpenJDK-versie die minder goed samenwerkt met mijn IDE, want de JBR is hier specifiek voor gemaakt. En die IDE is de enige reden waarom ik überhaupt Java op dit systeem nodig heb, want ik doe (helaas) al jaren niks meer in Java. Dus zelfs áls het werkt, is het een situatie die je zo snel mogelijk weer ongedaan wilt maken.
Dit is hoe ik deze oplossing ervaar. Soms is de oplossing erger dan het probleem.
Nee, dit is dus geen goede oplossing. Ik zou dit zien als een extreem laatste redmiddel.
Laat ik het eerst eens even verifiëren. Claude, kan je eerst eens kijken wanneer die libc6 update was geweest? PHPstorm werkte vanmorgen immers nog. Ik had al de aanname gedaan dat de update dus ook precies toen was, maar we zijn bij Webenable goed bekend met de gevolgen van aannames.
Claude ging kijken, en dat is vreemd:
**Critical findings:**
- **libc6 was upgraded on Feb 5 at 06:52**, NOT today
- Machine has rebooted daily (Feb 6, 7, 8, 9)
- Current session booted at 04:50 today, 51 min uptime
**This undermines the libc theory** — if PhpStorm worked after the Feb 5 libc update, libc can't be the sole cause.
Wauw. Maar goed dat ik dus zelf had opgelet en nagedacht, in plaats van blindelings de suggestie (om OpenJDK te installeren) te accepteren. Want Claude had naast het geven van dit slechte advies, ook nog eens een behoorlijk voorbarige conclusie getrokken op basis van een onvolledig onderzoek.
Claude ging verder, en ontdekte toen... de echte dader!
**Reading the first crash log (pid 9626) revealed the actual cause:**
The crash originated NOT from `LinuxIconThemeConfiguration` but from:
com.augmentcode.intellij.sentry.SentryMetadataCollector.executeGitLsFilesCommand
The **Augment Code plugin** triggered the first crash by trying to run `git ls-files`.
Augment Code: de echte dader!?
Claude had de 'real culprit' ontdekt. Het was de plugin van Augment Code. Deze plugin voert bij het opstarten blijkbaar wat code uit, waardoor alles crasht.
Het is dus duidelijk wat er moet gebeuren. Dus ik verzocht Claude Code om de pijnlijke daad uit te voeren. Sorry Augment Code, het is niet anders: je moet weg.
Niet dat het hielp, want PHPStorm crashte daarna nog steeds.
**Finding:** Same crash even without Augment. The crash during restart is triggered by `LinuxIconThemeConfiguration.loadStateFromOs()` (not Augment). Augment caused the FIRST crash but the restart crashes are independent.
Dus ook dit was het probleem niet. Op naar de volgende conclusie dan maar weer.
De echte conclusie: wat de fork?
Ik gaf Claude weer de instructies om verder te zoeken. Die kwam er toen achter dat het forken in het algemeen niet goed lijkt te werken. Claude verifieerde dit door wat Java-code te schrijven, en die te laten forken (via de ProcessBuilder). Dit resulteerde in SIGSEGV (een interne Linux-foutmelding rondom geheugentoewijzing). Normale non-forking code werkte wel:
**Actions taken:**
- Killed process
- Checked dmesg for hardware/memory errors — none
- Checked kernel version and install date — 6.14.0-37-generic from Jan 26, unchanged
- Cleaned JVM temp files (`/tmp/hsperfdata_r/`) and stale sockets (`/run/user/1000/jb.station.ij.9626.sock`)
**Ran isolated JVM tests:**
- `java TestSimple` (no ProcessBuilder) — **WORKS**: prints `JVM works: 21.0.9`
- `java TestFork` (uses ProcessBuilder) — **CRASHES** with same SIGSEGV
**Conclusion so far:** The JBR's `forkAndExec` is broken. The JVM itself works for non-forking operations.
Het is dus duidelijk. Het probleem is gevonden en gereproduceerd - en blijkt diep binnen de Java-code zelf te zitten. De zoektocht was ten einde gekomen. Ja, dat dachten we de vorige vier keer ook, maar nu is het echt zo.
En de oplossing dan?
Oh, de oplossing? Ja, die was vrij simpel. Ik stelde aan Claude voor: zal ik anders even een reboot doen? Vond Claude een fantastisch idee!
Dus reboot gedaan. En daarna werkte alles weer. Zoals met veel problemen was het gewoon een kwestie van uit en aan zetten.
Het is ook begrijpelijk dat zoiets kan gebeuren. Systemen zoals dit zijn ongelofelijk ingewikkeld, en wie weet wat voor zeldzame situatie er ontstaan was in de interne state van mijn systeem, waardoor dit specifieke stukje niet meer werkte.
Conclusie van Claude:
A **reboot fixed the issue**. The `forkAndExec` crash was transient — something in the system state during the previous session caused the JBR to crash when forking processes, and it persisted until reboot.
Conclusie: zelf nadenken
Een traject als dit is dus behoorlijk leerzaam om op te reflecteren, en het geeft een hoop inzicht over de werking van deze generatie LLM's. Claude bedacht bijvoorbeeld niet zelf om eerst te kijken of het tijdstip van de crash en de timing van de updates wel overeenkwamen. Claude trok meteen een voorbarige conclusie en kwam met een vreselijk voorstel. Dit laat dus zien hoe belangrijk het is om zelf te blijven nadenken, en je eigen kennis en ervaring te blijven gebruiken.
Wat een domme LLM, hè!? Dom advies, voorbarige conclusies! Maar is dat zo? We kunnen de situatie ook omdraaien. Is het misschien niet zo dat ík gewoon te weinig context gaf, en de LLM verkeerd gebruikte omdat ik de limitaties van deze technologie nog niet goed genoeg ken?
Een LLM werkt namelijk binnen de context van de data die hij heeft, en extrapoleert die. Hoe meer (relevante) data je geeft, hoe beter deze extrapolatie werkt. Het was eigenlijk mijn taak om de LLM te presenteren met relevante informatie, zoals de tijdstippen en de situatie rondom de crashes - of een harness te hebben waarin de LLM zelf weet welke stappen hij uit moet voeren.
Bovendien hebben LLM's vaak ook de neiging om te vervallen in een soort tunnelvisie, waarbij ze koppig, hardnekkig en onuitputtelijk opereren binnen dat beperkte gebied, en niet zelf in staat zijn om een stapje terug te doen. Dit soort gedrag zien we bij de nieuwere modellen steeds minder terug.
Het lijkt niet altijd nodig te zijn om heel veel context te moeten geven: soms kun je geluk hebben, als toevallig de algemene system-prompt iets relevants hierover bevat, of het precies terugkomt in de trainingsdata, of toevallig het non-deterministische proces van het genereren van de token uitkomt op de juiste stap. Maar beter is het om te beseffen dat je de LLM sturing moet geven - en dat kan op veel manieren, ook dynamisch. Hoe minder sturing je geeft, hoe groter de kans op een verkeerd resultaat.
Het gebruik ervan vereist dus een bepaalde investering. Als je dat vooraf onvoldoende doet, moet het vaak alsnog achteraf. Wanneer je niet beseft dat dit nodig is, ontstaan er verkeerde verwachtingen. Deze factoren beïnvloeden daarom ook heel sterk de hype en de teleurstelling die mensen ervaren wanneer ze met deze technologie werken. En dat is wel jammer, want door deze technologie op de juiste manier te gebruiken kunnen er alsnog wonderen mee verricht worden.
