GSoC 2020 Devlog. Week 2

If you missed my devlog on the previous week, you can find it here.

In this week, I was given a test case where the code from MDEV-515 branch fails. Although I like hard tasks, this one is a really tough: I must debug a huge bunch of code without having a stacktrace.

The thing is I have only this output:

create table t1 (a char(10), unique (a));
insert into t1 values ('a   ');
insert into t1 values ('a ');
ERROR 23000: Duplicate entry 'a' for key 'a'
insert into t1 values ('a '),('a  '),('a   '),('a         ');
ERROR 23000: Duplicate entry 'a' for key 'a'
insert into t1 values ('a     ');

innodb.mdev-515-fail1 'innodb'           [ fail ]
mysqltest: At line 28: query 'insert into t1 values ('a     ')' succeeded - should have failed with errno 1062...

My mentors are currently working hard on MariaDB 10.5.4 release, so I tried to do it on my own for a while.

So, I was busy with debugging the code and trying to understand what goes wrong while running the test. And you know, I've learned a lot in that 7 days.

Lessons learned

1. LLDB does not support signal handling in .lldbinit. Unlike GDB, it sets signal handling options per-process.
2. Debugging the server in IDE is a bit nasty. If a test includes server restart with new launch flags, it's even nastier.
3. MariaDB codebase is really hard to understand. Even for INSERT operation you go through, like, 10+ nested function calls, including the SQL layer.
   Oh, and have I mentioned multithreading? You might get a headache if you debug the code for the first time. If you need to debug multithreaded code, prepare for guaranteed headache.
4. Even MariaDB developers sometimes don't know how does some parts of the code work. For example,
   
   /* FIXME: What's this ? */
   thr->lock_state = QUE_THR_LOCK_ROW;
   
   was_lock_wait = row_mysql_handle_errors(
         &err, trx, thr, &savept);
   
   thr->lock_state = QUE_THR_LOCK_NOLOCK;
   
   Do you know the answer to the question above? You don't? Heikki, Marko and me neither. And that's totally understandable. Heikki had written this a long time ago and one day he couldn't find out when, where and why he had done it.
5. There was a trick for data structures corruption detection. You could add some fields with magic numbers and set their values on allocation. It's simple and somewhat genius: if there was a real corruption (or access to a structure which was not allocated), the numbers won't match on assertion. Don't try this at home, folks! There are much more reliable tools for the same case, one of them is ASAN.
6. Debugging such big projects becomes even more painful when you do it on a garbage hardware. I might use mozilla-rr to simplify the process, but it gives overhead I can't afford for now.
   Maybe I should post donation links 🙂 (don't want to be a beggar, though.)
7. 8G is a new 640K.
   8 gigs of RAM now are not enough for running IDE and browser simultaneously. Sometimes even excluding browser. Don't want to be a killjoy nor a whiner, but c'mon, I remember the times when 1 gigabyte for running basically everything with bells and whistles was overkill.
   (no, I don't use Chrome 😉)
8. Speaking of bright side, I saw a discussion between Sergei Golubchik (VP of MariaDB Server Engineering) and Michael Widenius aka Monty (CTO of MariaDB Corporation, there is an article on Wikipedia about him) in maria-developers mailing list. Although Sergei and Michael know each other since not later than 1998, it was somewhat adorable to see this:

And traditional postscript in one picture, of course: