[toggle ads]

Odi's astoundingly incomplete notes

New Entries

Crashes after updating microcode-data

Today Gentoo released the Intel Microcode update: sys-apps/microcode-data-20150121
After installation immediately a lot of applications crashed with the following log:
kernel: traps: NetworkManager[1308] trap invalid opcode ip:7f8bba0b093a sp:7fffd40a22e8 error:0 in libpthread-2.20.so[7f8bba0a5000+16000]

Some research revealed that this machine has an Intel Haswell CPU with buggy TSX. And the microcode update fixes this by effectively disabling TSX. This in itself is not a problem yet.

The most popular code that uses TSX is libpthread of glibc. And I had used an too old gcc version to compile glibc, with -march=native in CFLAGS. Unfortunately this gcc version enables TSX (hle, rtm) with the native optimizations enabled. So everything crashed at once.

The fix was to simply recompile glibc with gcc-4.8.4:
# gcc-config -l
 [1] x86_64-pc-linux-gnu-4.8.4 *
# emerge -1 glibc
You can check if gcc disables hle and rtm on your Haswell CPU correctly:
$ gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
-march=core-avx2 -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=core-avx2 -fstack-protector

posted on 2015-04-15 14:30 CEST in Code | 0 comments | permalink

Do not use Xerces, Xalan any more!

For years Java developers were used to require Apache Xerces and Xalan for their XML stuff. But those times are over. All this stuff is no longer necessary in modern JDKs (since at least 1.6 basically) and it does more harm than good to have these jars in your classpath or endorsed libs!

The problem is that the Internet is littered with references to Xerces and that even their Website is totally misleading. If you read that stuff you would believe that this is actually usefull code. But it isn't any more!

The first sentence on the website is "Welcome to the future!". But that's from at least 2010! The classes in xml-apis.jar are from 2009! All the code is build for JDK 1.3! Come on! Anybody who is still running 1.3 already has a lot of problems with the memory model / thread synchronization, let alone security issues! xml-apis contains ancient versions of JDK standard classes. For instance XMLStreamException doesn't even initialize the Exception's cause field, getting you nothing but incomplete stack traces.

I really wonder why this project can't get around to admit that it is effectively dead. They should really put a big fat warning on their website:


But no! All that 20 year old documentation still tells people to put that crap into the endorsed folder of the JDK where it will turn a perfectly good XML infrastructure into a jurassic version of itself.

These people don't realize how much worldwide developer time they are wasting by keeping this outdated website up!

Please also note that Xerces has security issues when exposed unconfigured to the Internet (webservices!), whereas JDK's built-in JAXP has sane defaults.

If your project still has Xerces, you should migrate away from it now. Chances are that you hard-coded some stuff on top of Xerces (like validation, feature strings, parser options, etc.). Use the modern JAXP equivalents!
posted on 2015-03-09 11:55 CET in Code | 0 comments | permalink

git: Dangerous default settings in Eclipse

When Eclipse imports a GIT repository, it sets some defaults that I can only describe as outright dangerous:

This setting means that each pull operation will fetch changes for all remote branches and merge them. This is totally unintuitive: it modifies stuff outside of the currently check-out branch. And it is the oposite of the command line git behaviour: you need explicitly specify if you wanted to fetch different branches (git fetch origin somebranch:somebranch)

If you happen to work with many work directories (one for each branch) that are based on the same git repository (git-new-workdir), that one click can get you into a lot of trouble if you are not ready to pull everywhere.

posted on 2015-03-03 19:00 CET in Code | 0 comments | permalink

Recent Gentoo is safe from GHOST

I ain't afraid of no GHOST.

According to Heise the GHOST vulnerability only affects glibc before 2.18. Uptodate Gentoo installations run 2.19 and are not affected.
# equery l glibc
 * Searching for glibc ...
[IP-] [  ] sys-libs/glibc-2.19-r1:2.2

posted on 2015-01-28 14:09 CET in Code | 0 comments | permalink

Gentoo to require initramfs

A Portage news item announces today that Gentoo is about to upgrade to udev-217. This upgrade will eliminate the userspace firmware loader. The change requires not only a kernel config change (CONFIG_FW_LOADER_USER_HELPER=N). It also may require an initramfs, if the kernel has drivers built-in that want to load firmware before the root filesystem is mounted. Examples of such drivers are: iwlwifi (Intel WiFi chips) or bnx2 (Broadcom NetXtreme II). Without userspace fw loading these drivers will fail to load their firmware. The standard solution to this problem is to use an initramfs.

A module-less initramfs is sufficient for that case (modules are built-in already), and it can easily be shared among different kernels.

posted on 2014-11-10 10:30 CET in Code | 0 comments | permalink

interactive diff merge on the console

To quickly compare and merge files ver1 and ver2 and save the result as merged:
sdiff -s -o merged ver1 ver2
It's the command that Gentoo's etc-update uses.
posted on 2014-09-18 18:20 CEST in Code | 0 comments | permalink

Gentoo fails to build dev-libs/boost-1.52.0-r7

If you get this:
ln -f -s 'libboost_wave.so.1.52.0' 'stage/lib/libboost_wave.so'

...failed updating 1 target... 

Then put this into your /etc/portage/package.use:
# boost 1.52 is broken with current icu
<dev-libs/boost-1.53 -icu

posted on 2014-08-02 12:31 CEST in Code | 1 comments | permalink
Just to ser how it is done. Nice work.

iOS and hostapd

If you want iOS devices to connect to your hostapd AP, then you must not configure SHA256. Unbelievable, Apple! You get offered a choice between two options and you just decide to fail?!?

#wpa_key_mgmt=WPA-PSK WPA-PSK-SHA256

posted on 2014-07-30 22:35 CEST in Code | 0 comments | permalink

How not to design an API

Reading up on how to remotely connect to a JMX port, I wonder how one can possibly design such a horrible API. According to that document you need to create an URI string and pass that to the API. The URI string looks like this:
Utterly unintuitive, error prone and unreadable. And why assemble an URI string, pass it through an underpowered API and then parse that apart in the implementation again? Like somebody deliberately wanted to piss people off.

It could have been as simple as this:
JMXConnectorFactory.connect(host, port);
Because that's all people normally do! Yes, there may be one person in the Universe that wants to exchange the RMI transport with something else. But the API makes everybody pay with that:
MXServiceURL u = new JMXServiceURL(
  "service:jmx:rmi:///jndi/rmi://" + hostName + ":" + portNum +  "/jmxrmi");
  JMXConnector c = JMXConnectorFactory.connect(u);

posted on 2014-07-14 09:59 CEST in Code | 0 comments | permalink

Preventing systemd on Gentoo

With the latest upower upgrade portage may pull in systemd. If you are like me and think that systemd has grown beyond what it should do and you don't want it, do this:

Then replace upower with the compatibility layer:
emerge -C sys-power/upower
emerge -1 sys-power/upower-pm-utils

posted on 2014-06-03 13:25 CEST in Code | 1 comments | permalink
Thank you! I really don't like systemd and the attitude of its developers. It just seems horrible all around, so thanks for helping me not install it on Gentoo!