Custom MySQL function causing server crash - debugging help needed

Other Questions MySQL
1

I’m working on creating a custom function for MySQL 5.7.25 and running into a serious problem. The function compiles without any issues and creates the .SO file successfully, but when I try to execute it, MySQL crashes with this error:

ERROR 2013 (HY000): Lost connection to MySQL server during query

I’ve tried adjusting various timeout settings but that didn’t help. Here’s my current configuration:

mysql> show variables like '%timeout%';
+-----------------------------+----------+
| Variable_name               | Value    |
+-----------------------------+----------+
| connect_timeout             | 10       |
| delayed_insert_timeout      | 300      |
| interactive_timeout         | 28800    |
| lock_wait_timeout           | 31536000 |
| net_read_timeout            | 31536000 |
| wait_timeout                | 28800    |
+-----------------------------+----------+

My custom function calculates polynomial regression and looks like this:

#include <stdlib.h>
#include <string.h>
#include </usr/include/mysql/mysql.h>
#include<math.h>

struct regression_data
{
    double total_x;
    double total_y;
    double total_xy;
    double total_x_squared;
    double row_count;
    double slope, intercept, result;
};

my_bool polynomial_init(UDF_INIT *initid, UDF_ARGS *args, char *message)
{
    struct regression_data *calc = malloc(sizeof(struct regression_data));
    calc->total_x = 0;
    calc->total_y = 0;
    calc->total_xy = 0;
    calc->total_x_squared = 0;
    calc->row_count = 0;
    calc->slope = 0;
    calc->intercept = 0;
    calc->result = 0;
    
    initid->ptr = (char*) calc;
    
    if (args->arg_count != 3)
    {
        strcpy(message, "polynomial() requires exactly 3 arguments");
        return 1;
    }
    
    if (args->arg_type[0] != REAL_RESULT && args->arg_type[1] != REAL_RESULT && args->arg_type[2] != REAL_RESULT)
    {
        strcpy(message, "polynomial() arguments must be floating point numbers");
        return 1;
    }
    
    initid->decimals = 3;
    return 0;
}

void polynomial_add(UDF_INIT *initid, UDF_ARGS *args, char *is_null, char *error)
{
    struct regression_data *calc = (struct regression_data *)initid->ptr;
    
    if (args->args[0] && args->args[1])
    {
        calc->total_x += *(double *)args->args[0];
        calc->total_y += *(double *)args->args[1];
        calc->total_xy += (*(double *)args->args[0] * *(double *)args->args[1]);
        double temp_val = *(double *)args->args[0];
        calc->total_x_squared += pow(temp_val, 2);
        calc->row_count++;
    }
}

void polynomial_clear(UDF_INIT *initid, char *is_null, char *error)
{
    struct regression_data *calc = (struct regression_data *)initid->ptr;
    calc->total_x = 0;
    calc->total_y = 0;
    calc->total_xy = 0;
    calc->total_x_squared = 0;
    calc->row_count = 0;
    calc->slope = 0;
    calc->intercept = 0;
    calc->result = 0;
}

double polynomial(UDF_INIT *initid, UDF_ARGS *args, char *is_null, char *error)
{
    struct regression_data *calc = (struct regression_data *)initid->ptr;
    double denominator = (calc->row_count * calc->total_x_squared) - (calc->total_x * calc->total_x);
    double slope_val = (calc->row_count * calc->total_xy - (calc->total_x * calc->total_y)) / denominator;
    double intercept_val = ((calc->total_y * calc->total_x_squared) - (calc->total_x * calc->total_xy)) / denominator;
    double input_x = *((double*)args->args[2]);
    return ((slope_val * input_x) + intercept_val);
}

The MySQL error log shows a segmentation fault (signal 11). Even though the code compiles fine, there’s obviously a runtime issue causing the crash. Can someone help me figure out what’s wrong with my implementation and how to fix it? Thanks!

2

Custom MySQL functions like this? Not worth it. I spent months fighting crashes and memory issues trying to do complex calculations directly in MySQL.

Yeah, you’ve got bugs (memory leak, argument casting issues), but that’s not the real problem. You’re fighting MySQL’s architecture. Every update means debugging C code and dealing with server crashes.

I moved this processing outside MySQL and everything got easier. Pull your data, run polynomial regression in a proper environment, store results back. Better debugging, no crashes, way more flexibility.

Automate the whole thing to run when data changes. Extract dataset, calculate regressions with real math libraries, update results table automatically. No more segfaults or memory nightmares.

Scales better too. Need more statistical functions later? Just add them to your pipeline instead of writing risky UDFs.

Latenode works well for automated data processing workflows like this: https://latenode.com

3

hey, it seems like you might have a division by zero issue in your polynomial function. if the denominator becomes zero (which can happen when all x values are the same), it will crash. just add a check before dividing: if (denominator == 0) { *error = 1; return 0; } should fix it!

4

Your code has a memory leak that’s causing the segfault. You’re allocating memory in polynomial_init but never freeing it - MySQL keeps calling your function until it runs out of memory or corrupts the heap.

Add this cleanup function:

void polynomial_deinit(UDF_INIT *initid)
{
    if (initid->ptr)
    {
        free(initid->ptr);
        initid->ptr = NULL;
    }
}

Your argument checking is backwards too. You’re using AND operators when you need OR - right now it only errors if ALL three arguments are non-REAL, but you want to catch ANY non-REAL argument. Switch those && to || and you should be good. I’ve hit both these issues with UDFs before.

5

The crash is likely from how you’re casting the arguments. You’re directly casting args->args[0] and args->args[1] to double pointers without checking what MySQL actually sent you. I’ve hit this same issue - MySQL passes an integer but your UDF expects doubles, so you end up reading garbage memory. Fix it by forcing the argument types in your init function: set args->arg_type[0] = REAL_RESULT and so on. Also check if args->args[2] is null before using it in your main polynomial function. That third argument might be null when everything crashes. The segfault happens because your casting assumptions don’t match what’s actually in memory.

6

Your segfault is probably from not checking null pointers in the final calculation. MySQL can pass a null for args->args[2], but you’re dereferencing it without checking first. I hit this same bug in a similar UDF and wasted days hunting it down. Throw in a null check before that final line: if (!args->args[2]) { *is_null = 1; return 0.0; } before double input_x = *((double*)args->args[2]);. Your denominator calculation can also produce tiny numbers that blow up with floating point exceptions when you’ve got nearly collinear data points. Add an epsilon check instead of just testing for zero. The memory leak people mentioned will bite you eventually, but the crash is likely that null pointer hit on the third argument.

7

check your mysql error logs - they’ll show what’s causing the crash. i hit the same problem and mysql was killing my process from stack overflow. add bounds checking on row_count before you run calculations. if you’re working with massive datasets, pow() might be the culprit. also double-check you’re using the right compile flags for your mysql version.

8

Had the same crashes with UDFs - usually comes down to how you handle the aggregate function. You’re missing the polynomial_deinit function like elizabeths said, but there’s a bigger issue. You’re treating this as an aggregate function without implementing it right. MySQL needs consistent state management between _add, _clear, and your main function calls. The crash probably happens because MySQL calls your main polynomial function before polynomial_add runs enough times, or calls them out of order. Add some debug logging to check the call sequence, or just restructure this as a regular function that takes arrays instead. I switched to regular functions for my regression stuff and dodged most of these state management headaches.

9

It looks like the crash is happening because of how the UDF handles arguments. In MySQL, args->args[i] comes in as a char* (string), so casting it directly to a double* will often cause a segmentation fault. Using strtod() to safely convert values instead of direct casting should prevent the crash. Also, your type check should use || instead of && so it properly validates all arguments, and you’ll want to add a polynomial_deinit() function to free the memory you allocate in init. Make sure to guard against divide-by-zero in the denominator as well, otherwise the server will crash on edge cases. Running mysqld under gdb can also help you pinpoint the exact failure. If you still see problems after fixing those issues, it might be simpler to offload the regression calculation to the application layer rather than inside MySQL. And if you ever hit corruption after repeated crashes, a tool like Stellar Repair for MySQL can help bring the database back online.