# Why did threaded perl wreck my desktop?



## IT-Doody (May 6, 2014)

My FreeBSD 9.2 has been running like a Swiss watch up until now. I update ports regularly and read /usr/ports/UPDATING. Ironically that's what got me in big trouble yesterday. I remembered reading this in UPDATING a while back:





> 20131120:
> AFFECTS: users of lang/perl5.12 lang/perl5.14 lang/perl5.16 and lang/perl5.18
> AUTHOR: mat@FreeBSD.org
> 
> ...


I knew I've built perl5 before without threads and even remember faintly some advice against doing it, but if that's what _the man_ says then I wanted to be up to date. I proceeded to rebuild perl5.16 recursing its dependencies. If I recall correctly doxygen and qjson failed to build, but I figured I'd deal with them later. As soon as kdelibs was rebuild the system went bonkers with everything segfaulting and core dumping. I thought a simple reboot would take care of it by loading the newly built modules and libraries, but I was gravely mistaken. On next boot  kdm complained about some error and X server wouldn't load. I figured I'd just roll everything back so I rebuilt perl5.16 recursively again, but to no avail. Upon next two boot ups I was greeted by plasma desktop crash report and on subsequent attempts the machine would reboot spontaneously while trying to load the desktop, corrupting the filesystem as well. I thought I was facing a complete system re-install, but I decided to try a less drastic measure. I booted to single user mode, ran `fsck` without journal and rebuilt everything from /var/db/pkg that contained 'kde'. Luckily that did the trick.
Have I done something wrong here and could this disaster have been avoided? I'd like to learn something from this mishap other then never to re-configure perl again.


----------

