I’m currently trying to run some C code in Python 3.10.12 to be able to test some algorithms/visual effects without the need for real hardware. To do this I made a separate compilation that compiles the relevant code to a library which can then be imported into python using ctypes. After a lot of fighting with ctypes I got my lib integrated with the Python code.

I have now ran into a super weird issue that I’m getting a SIGSEGV on one of the effects.

So I did the reasonable thing and set up a GDB session to debug the code, and GDB indicates that the SIGSEGV is happening with the following message:

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x00007ffff7192870 in colour_random_offset_hue_gen_frame (buffer=0x7ffff719ad60 <led_buffer> "") at /home/jaxc/work/LED_glasses/effects/colours/random_hue.c:21
21          random = (random * 196314165) + 907633515;

The buffer originates from led_buffer which is defined as follows:

uint8_t led_buffer[FRAME_SIZE];

This seems super weird to be as this line does not affect the buffer (until a few lines later when I assign the value). The full function looks like this:

void colour_random_offset_hue_gen_frame(uint8_t buffer[FRAME_SIZE]) {

    uint16_t current_led = 0;
    for (uint16_t i = 0; i < FRAME_SIZE; i += 3) {
        struct colours pixel_hue;
        uint32_t random_hue = random % 1024;
        random = (random * 196314165) + 907633515;
        get_colour(&pixel_hue, random_hue, 0xff);

        buffer[i] = pixel_hue.green; /* Green value */
        buffer[i+1] = pixel_hue.red; /* Red value */
        buffer[i+2] = pixel_hue.blue; /* Blue value */

        current_led++;
    }
}

Compiling the code with -O0 flags gives the following assembly for the troubled row:

21          random = (random * 196314165) + 907633515;
   0x00007ffff7194a6f <+43>:    mov    0x5472(%rip),%rax        # 0x7ffff7199ee8
   0x00007ffff7194a76 <+50>:    mov    (%rax),%eax
   0x00007ffff7194a78 <+52>:    imul   $0xbb38435,%eax,%eax
   0x00007ffff7194a7e <+58>:    lea    0x3619636b(%rax),%edx
   0x00007ffff7194a84 <+64>:    mov    0x545d(%rip),%rax        # 0x7ffff7199ee8
=> 0x00007ffff7194a8b <+71>:    mov    %edx,(%rax)

And the fault happens at the last row (mov %edx,(%rax)). Even commenting out the rest of the code of the function results in the same assembly for that line of code.

I tried to isolate the issue by making a main that just has this code, but it works without segfaults, so I suspect the python integration somehow does something. I also tested this online:
https://onlinegdb.com/D0j3azZ98

I have also tested the code quickly using a c main function, calling the same function as I do in Python without getting any segmentation fault.

Thanks in advance!