| 17 Nov 2025 |
K900 | The good news is that it's consistent I guess lol | 09:03:48 |
Yureka (she/her) | I'm running staging-next | 09:03:53 |
Yureka (she/her) | so that might be another reason | 09:03:58 |
Yureka (she/her) | I can switch back to master and reproduce it there | 09:04:05 |
K900 | Can you just addr2line it | 09:04:10 |
K900 | libgallium-25.3.0.so@0x1a8f444 that is | 09:04:13 |
Yureka (she/her) | how do I use addr2line with separate debug output? | 09:08:04 |
K900 | It should just read the headers I think. | 09:09:13 |
K900 | * It should just read the headers I think? | 09:09:19 |
dramforever | In reply to @k900:0upti.me @hexa we're pushing symbols for the entire closure right? libgallium isn't in the closure, it's in /run/opengl-driver | 09:11:04 |
dramforever | uh | 09:11:16 |
dramforever | not in the library closure | 09:11:23 |
dramforever | if it's not in the nix closure i'd be very surprised | 09:11:33 |
dramforever | but that's all i can think of | 09:11:50 |
Yureka (she/her) | As in how do I invoke it? | 09:12:26 |
dramforever | addr2line -e /path/to/libgallium.so 0x1a8fandsuch | 09:13:09 |
Yureka (she/her) | [yuka@m1:~/proj/nixpkgs]$ addr2line 0x1a8f444 -e result/lib/libgallium-25.3.0.so
??:?
[yuka@m1:~/proj/nixpkgs]$
| 09:13:16 |
Yureka (she/her) | *
[yuka@m1:~/proj/nixpkgs]$ addr2line 0x1a8f444 -e result/lib/libgallium-25.3.0.so
??:?
[yuka@m1:~/proj/nixpkgs]$
| 09:13:23 |
dramforever | -f | 09:13:48 |
Yureka (she/her) | agx_batch_reads
??:?
| 09:14:11 |
dramforever | well | 09:14:25 |
dramforever | there you go | 09:14:47 |
Yureka (she/her) | 3dab73159bc asahi,ail: fix multi-plane imports
84d8e6824be treewide: don't check before free
ed97f7791a1 asahi: enable virtgpu support
20dab5f819f asahi: enable virtgpu support | 09:15:40 |
Yureka (she/her) | * 3dab73159bc asahi,ail: fix multi-plane imports
84d8e6824be treewide: don't check before free
ed97f7791a1 asahi: enable virtgpu support
20dab5f819f asahi: enable virtgpu support
| 09:15:48 |
Yureka (she/her) | that's all the commits touching agx_batch.c in 25.2.6...25.3.0 | 09:16:04 |
dramforever | could be someone else passing a null pointer or something though | 09:16:51 |
dramforever | are you really sure it's not in coredumpctl | 09:16:59 |
Yureka (she/her) | it's not | 09:17:11 |
Yureka (she/her) | probably because firefox is handling it itself | 09:17:38 |
dramforever | they "should" still raise a signal in the signal handler so it's dumped anyway but what do i know.. | 09:18:34 |