Rust program only starts on certain nixpkgs commits (and not now)

Help
1

I have a rust program that uses egui and thus glutin, an OpenGL library, and it’s been panicking ever since a change sometime in October but I’m having a hard time debugging exactly what is wrong, since different commits are giving me different results when updating my system flake:

More recent commits (via my usual nixos-unstable following ref) always fail every time I update my flake.

The error it logs is

[2023-12-29T00:20:25Z ERROR eframe::native::run] Exiting because of error: Found no glutin configs matching the template: ConfigTemplate { color_buffer_type: Rgb { r_size: 8, g_size: 8, b_size: 8 }, alpha_size: 8, depth_size: 0, stencil_size: 0, num_samples: None, min_swap_interval: None, max_swap_interval: None, config_surface_types: WINDOW, api: None, transparency: false, single_buffering: false, stereoscopy: None, float_pixels: false, max_pbuffer_width: None, hardware_accelerated: None, max_pbuffer_height: None, native_window: None }. Error: Error { raw_code: None, raw_os_message: None, kind: BadConfig } during event Resumed

Note that I can “turn” the issue on and off by just rebuilding my system live, without the need for a reboot in between. The specific commits where it works and doesnt are reproducible from multiple tests.

I have a hunch this may have to do more with some part of the rebuild process than the commits themselves, though I’m not sure.

2

Since this is a graphics thing, are you rebooting between these rebuilds? They may not be required to get stuff to work/break, but the graphics drivers won’t reload without a reboot, at which point the graphics headers might not match the underlying driver and cause failures like this.

It could explain the flaky-but-predictable behavior; maybe whatever driver you’re using is exactly the one from c7e70840c0ea981bc97a265b2294246dcc33775d, so switching between the commits without a reboot means “only” that commit works. That said, the commit times are close enough together that it’d be odd for a graphics driver thing to be causing issues here, so…

3

Since this is a graphics thing, are you rebooting between these rebuilds?

I originally rebooted when manually bisecting where I found the issue which led me to 1cf369, however I stopped doing that for the last few tests since it seemed to have a neglible effect on whether a certain commit worked or not (at least for the extremes “not working since late october/novermeber” and “working prior to my flake udpate on the 14th”). Will sanity check again.

That said, the commit times are close enough together that it’d be odd for a graphics driver thing to be causing issues here, so…

Yeah I specifically chose them as an example of the weird behaviour due to their close times since it didn’t seem like anything noteworthy was happening between them.

Perhaps garbage collecting and trying those commits again might change something, in the small chance it is related to the activation process.

4

Will sanity check again.

Behaviour is the same before and after a reboot. Maybe noteworthy is that it changes from “crash” to “runs” and viceversa right before the activation process starts re-enabling all the services and home-manager (and after it’s initially disabled them)

5

Turns out my flake was old enough to have some sort of version mismatch between the build and system dependencies, a flake update finally took care of that.

Though man that was a cryptic error to decypher if I’ve ever seen one.

2 Likes