Elena Stepanova added a comment - 2015-12-01 23:23 robertalks , I've checked that neither 10.0, nor 5.5, nor MySQL up to and including 5.7 are able to start with a non-existing include directory. It appears to be reasonable, because there is no hardcoded magic about using it – the includedir directive is a part of the cnf file, so if it's there, its use is assumed to be intentional. When standard packages are installed, they use cnf file templates, which have this directive, but they also create the desired include directory, so there is no problem with them. Now, I don't know how your custom packaging/installation script works, but my best guess is that it uses some pre-created cnf files provided with the source code, but doesn't do the job required to make them actually usable. From the error message, it appears that you might be using support-files/rpm/my.cnf file (which is also strange since you're on Debian). Anyway, if you do not want to use the include dir, the solution is to generate your own cnf file rather than take an existing one.

Robert Milasan added a comment - 2015-12-02 09:33 OK, agreed, just that the my.cnf actually got copied when doing the default install, wasn't even able to replace it in time. My problem is that is 'stupid' to have a segfault, an error, agreed, but segfault due to missing directory, sounds like a bug. You can do what you want with the bug, close or fix a segfault, as you wish.

Elena Stepanova added a comment - 2015-12-02 13:32 - edited I agree, crashing is never the right thing to do. Apparently it's fixed in 5.7 – while 5.6 also segfaults, 5.7 instead produces the error message "Upgrade process encountered error and will not continue.". Stack trace from 10.0 commit 2553f143fdeb9068eb02a8fda58750c24071f5ef [New LWP 20305] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `client/mysql_upgrade --defaults-file=10.0/1.cnf --port=3306 --'. Program terminated with signal 11, Segmentation fault. #0 0x000000000041cd15 in free_defaults (argv=0x0) at 10.0/mysys/my_default.c:652 652 memcpy(&ptr, ((char *) argv) - sizeof(ptr), sizeof(ptr));   Thread 1 (Thread 0x7f02d1445720 (LWP 20305)): #0 0x000000000041cd15 in free_defaults (argv=0x0) at 10.0/mysys/my_default.c:652 #1 0x0000000000408a0f in free_used_memory () at 10.0/client/mysql_upgrade.c:183 #2 0x0000000000408b61 in die (fmt=0x0) at 10.0/client/mysql_upgrade.c:207 #3 0x000000000040a8b6 in main (argc=5, argv=0x7ffc792332e8) at 10.0/client/mysql_upgrade.c:1059 To reproduce, start the server (normally), and then run mysql_upgrade with --defaults-file=<filename> where <filename> contains a directive to include a non-existing folder, e.g. [mysqld] lock-wait-timeout=30   !includedir /home/elenst/nonexisting_include

Vicențiu Ciorbaru added a comment - 2016-02-14 14:18 The bug-fix can not be taken from upstream as it includes a complete refactoring of the related code. However, the fix is simple. We were freeing a null pointer (as can be seen in the stacktrace, where argv=0x0). free_defaults should check if the argv pointer is NULL.

Robert Milasan added a comment - 2016-02-14 15:46 Thanks, yes, a pointer should be checked before freeing

Vicențiu Ciorbaru added a comment - 2016-02-14 18:36 Fixed with: https://github.com/MariaDB/server/commit/2a4781789612c6c53cbe12c1426f93b15737a148