The nature of C# locking issues explained

Sometimes in the life of a programmer everything seems peachy, C#/DotNet provide relatively easy multi threading capabilities which 99.9% of the time work just fine as explained everywhere online.

However when things get a bit serious as these online explanations tend to be off by a small bit, only that small bit creates havoc….

Imagine having to debug code within a lock() statement that crashes with exceptions like “Collection was modified; enumeration operation may not execute” which seemingly bypass any locking in place.
These are not fun to deal with as everyone will for some reason stubbornly tell you that that is not possible and you are simply lacking a lock somewhere and just moving on like they have just shed divine light.

First of all lets get the common misconception cleared that it is impossible for a single thread to execute code in parallel and even worse that events will always be fired with a new thread affinity. This is just plain wrong!

Create a simple empty form with the following code in the shown event:

And paste the following somewhere below:

If what everybody proclaims is right this code should just lock up the UI and neatly print “A”, “B” in sequence when triggered.
This is where the bad news starts, it doesn’t, simply clicking the button a few times very easily prints “A”, “A”, “B”, “B”.
So with a few lines of code we have disproved two very stubborn myths in one blow.

Now for a somewhat more sensible approach:

This properly locks up the UI as expected (it’s example code, not release code) and can even be used for some more interesting purposes when multi threading.

Please don’t be like all the other assholes online who proclaim that this doesn’t happen in normal production code (or even worse that a simple lock() should always be sufficient as events have different thread affinities).
Simply imagine a simple asynchronous communication protocol between two programs or a server and a client, having simple locks can seriously fuck up your day with some long debugging ahead.

MariaDB + Debian

For MariaDB fans there are some changes coming in the current Debian testing/unstable, which will hit mainstream sometime this year (I guess).
A lot of things compiled against libmariadbclient.so.18 will start failing, most of which can be solved with a simple symlink except a few…

Opendmarc wil fail to compile:
opendkim: malloc.c:3757: _int_malloc: Assertion `(unsigned long) (size) >= (unsigned long) (nb)' failed.

Spamassassin will fail to run
spamd[27186]: at /usr/share/perl5/Mail/SpamAssassin/Conf/SQL.pm line 138.
spamd[27186]: spamd: service unavailable: Error fetching user preferences via SQL
spamd[3690]: config: failed to load user (dmarc@black-mail.nl) scores from SQL database: install_driver(mysql) failed: Attempt to reload DBD/mysql.pm aborted.
spamd[3690]: Compilation failed in require at (eval 1409) line 3, line 2.

The opendkim one is pretty vague and seemingly unhelpfull but a bit of digging will reveal the following:
Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so' for module DBD::mysql: /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so: symbol mysql_options4, version libmariadbclient_18 not defined in file libmariadbclient.so.18 with link time reference at /usr/lib/x86_64-linux-gnu/perl/5.24/DynaLoader.pm line 187.
at /usr/sbin/opendmarc-import line 22.
Compilation failed in require at /usr/sbin/opendmarc-import line 22.

Hey, now we have a finger to point, Perl::DBD:
ldd /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so
/usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so: /lib/libmariadbclient.so.18: no version information available (required by /usr/lib/x86_64-linux-gnu/perl5/5.24/auto/DBD/mysql/mysql.so)
linux-vdso.so.1 (0x00007ffdca9bc000)
libmariadbclient.so.18 => /lib/libmariadbclient.so.18 (0x00007faf4fe63000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faf4fac5000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007faf4f8ab000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007faf4f68e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007faf4f48a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faf4f184000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007faf4ef18000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007faf4ea85000)
/lib64/ld-linux-x86-64.so.2 (0x000056045c708000)

For some reason no symlinking will solve this, but no worries, simply get the source, unpack it and run:
perl Makefile.PL
make
make install
make clean

After this things should work smoothly, but keep in mind to keep the package up date date and remove the manually installed files should Debian fix this.

Corrupting bash on Windows

Let’s asume bash is allready installed:
sudo apt-get install bb

If you are root exit to the normal user, bb won’t launch as root.

bb -loop -dim -bold -reverse -normal -boldfont -extended -inverse

After a while (especially during the heavier animations) the line width wil vary and result in some weird looking stuff.