Taping Memory

Fun with Pin UB

2025-07-11T00:00:00+00:00

So, let's say you have a clean and nice function like this.</p>

use </span>std::pin::Pin;
</span>async </span>fn </span>foo</span>() -> </span>u32 </span>{
</span>    </span>let mut</span> x </span>= </span>1</span>;
</span>    tokio::time::sleep(std::time::Duration::from_secs(</span>0</span>)).await;
</span>    x</span>+= </span>1</span>;
</span>    x
</span>}
</span>
</span>#[</span>tokio</span>::</span>main</span>]
</span>async </span>fn </span>main</span>() {
</span>    </span>let mut</span> x </span>= </span>foo</span>();
</span>    </span>let</span> a </span>= </span>unsafe </span>{ Pin::new_unchecked(</span>&</span>mut</span> x) };
</span>    
</span>    println!(</span>"</span>{}</span>"</span>, a.await);
</span>}
</span></code></pre>
Everything looks nice except for that Pin::new_unchecked</code> which we created with unsafe (oh no), so we can do evil things.</p>
I've read a lot about how async</code> creates internal state machines that keep self-referential structs that, if moved, everything could be disastrous.</p>
But how does this look? How can we fail to enforce the safety requirements of Pin</code>, specifically, with futures? Let's see what happens if you move a pinned value after it's created and polled!</p>
Now let's rewrite this in the following way.</p>
use </span>std::task::Poll;
</span>use </span>std::task::Context;
</span>use </span>std::pin::Pin;
</span>async </span>fn </span>foo</span>() -> </span>u32 </span>{
</span>    </span>let mut</span> x </span>= </span>1</span>;
</span>    tokio::time::sleep(std::time::Duration::from_secs(</span>0</span>)).await;
</span>    x</span>+= </span>1</span>;
</span>    x
</span>}
</span>
</span>#[</span>tokio</span>::</span>main</span>]
</span>async </span>fn </span>main</span>() {
</span>
</span>    println!(</span>"</span>{}</span>"</span>, BadFuture.await);
</span>}
</span>
</span>struct </span>BadFuture;
</span>
</span>impl </span>Future </span>for </span>BadFuture {
</span>    </span>type </span>Output </span>= </span>u32</span>;
</span>    </span>fn </span>poll</span>(</span>self</span>: Pin<</span>&</span>mut Self</span>>, </span>cx</span>: </span>&</span>mut </span>Context<'</span>_</span>>) -> Poll<</span>Self::</span>Output> {
</span>        </span>let mut</span> x </span>= </span>foo</span>();
</span>        </span>let mut</span> a </span>= </span>unsafe </span>{ Pin::new_unchecked(</span>&</span>mut</span> x) };
</span>        </span>let mut</span> i </span>= </span>0</span>;
</span>        </span>loop </span>{
</span>            i </span>+= </span>1</span>;
</span>            dbg!(i);
</span>            </span>if let </span>Poll::Ready(a) </span>=</span> a.</span>as_mut</span>().</span>poll</span>(cx) {
</span>                </span>return </span>Poll::Ready(a);
</span>            }
</span>        }
</span>    }
</span>}
</span></code></pre>
Something I didn't expect at all here is that i</code> can go up to values in the hundreds!</p>
But good, it loops at least more than once; now we can do crimes.</p>
First let's try this.</p>
use </span>std::task::Poll;
</span>use </span>std::task::Context;
</span>use </span>std::pin::Pin;
</span>async </span>fn </span>foo</span>() -> </span>u32 </span>{
</span>    </span>let mut</span> x </span>= </span>1</span>;
</span>    tokio::time::sleep(std::time::Duration::from_secs(</span>0</span>)).await;
</span>    x</span>+= </span>1</span>;
</span>    x
</span>}
</span>
</span>#[</span>tokio</span>::</span>main</span>]
</span>async </span>fn </span>main</span>() {
</span>
</span>    println!(</span>"</span>{}</span>"</span>, BadFuture.await);
</span>}
</span>
</span>struct </span>BadFuture;
</span>
</span>impl </span>Future </span>for </span>BadFuture {
</span>    </span>type </span>Output </span>= </span>u32</span>;
</span>    </span>fn </span>poll</span>(</span>self</span>: Pin<</span>&</span>mut Self</span>>, </span>cx</span>: </span>&</span>mut </span>Context<'</span>_</span>>) -> Poll<</span>Self::</span>Output> {
</span>        </span>let mut</span> x </span>= </span>foo</span>();
</span>
</span>        {
</span>            </span>let mut</span> a </span>= </span>unsafe </span>{ Pin::new_unchecked(</span>&</span>mut</span> x) };
</span>            </span>let </span>_ =</span> a.</span>as_mut</span>().</span>poll</span>(cx);
</span>        }
</span>        
</span>        </span>let mut</span> x2 </span>=</span> x;
</span>        
</span>        </span>let mut</span> a </span>= </span>unsafe </span>{ Pin::new_unchecked(</span>&</span>mut</span> x2) };
</span>        </span>let </span>_ =</span> a.</span>as_mut</span>().</span>poll</span>(cx);
</span>        
</span>        </span>let mut</span> i </span>= </span>0</span>;
</span>        </span>loop </span>{
</span>            i </span>+= </span>1</span>;
</span>            dbg!(i);
</span>            </span>if let </span>Poll::Ready(a) </span>=</span> a.</span>as_mut</span>().</span>poll</span>(cx) {
</span>                </span>return </span>Poll::Ready(a);
</span>            }
</span>        }
</span>    }
</span>}
</span></code></pre>
For me, this caused an infinite loop. FUN!</p>
The cause is UB. We moved the future, which contained a self-reference, which might now point to uninitialized memory, so now who knows what crazy things might happen.</p>
Another case mentioned a lot in the pin</code> docs is mem swapping; let's try that.</p>
use </span>std::mem;
</span>use </span>std::task::Poll;
</span>use </span>std::task::Context;
</span>use </span>std::pin::Pin;
</span>async </span>fn </span>foo</span>() -> </span>u32 </span>{
</span>    </span>let mut</span> x </span>= </span>1</span>;
</span>    tokio::time::sleep(std::time::Duration::from_secs(</span>0</span>)).await;
</span>    x</span>+= </span>1</span>;
</span>    x
</span>}
</span>
</span>#[</span>tokio</span>::</span>main</span>]
</span>async </span>fn </span>main</span>() {
</span>
</span>    println!(</span>"</span>{}</span>"</span>, BadFuture.await);
</span>}
</span>
</span>struct </span>BadFuture;
</span>
</span>impl </span>Future </span>for </span>BadFuture {
</span>    </span>type </span>Output </span>= </span>u32</span>;
</span>    </span>fn </span>poll</span>(</span>self</span>: Pin<</span>&</span>mut Self</span>>, </span>cx</span>: </span>&</span>mut </span>Context<'</span>_</span>>) -> Poll<</span>Self::</span>Output> {
</span>        </span>let mut</span> x1 </span>= </span>foo</span>();
</span>        
</span>        {
</span>            </span>let mut</span> a </span>= </span>unsafe </span>{ Pin::new_unchecked(</span>&</span>mut</span> x1) };
</span>            </span>let </span>_ =</span> a.</span>as_mut</span>().</span>poll</span>(cx);
</span>        }
</span>        
</span>        </span>let mut</span> x2 </span>= </span>foo</span>();
</span>        
</span>        mem::swap(</span>&</span>mut</span> x1, </span>&</span>mut</span> x2);
</span>        
</span>        </span>let mut</span> a </span>= </span>unsafe </span>{ Pin::new_unchecked(</span>&</span>mut</span> x2) };
</span>        </span>let </span>_ =</span> a.</span>as_mut</span>().</span>poll</span>(cx);
</span>        
</span>        </span>let mut</span> i </span>= </span>0</span>;
</span>        </span>loop </span>{
</span>            i </span>+= </span>1</span>;
</span>            dbg!(i);
</span>            </span>if let </span>Poll::Ready(a) </span>=</span> a.</span>as_mut</span>().</span>poll</span>(cx) {
</span>                </span>return </span>Poll::Ready(a);
</span>            }
</span>        }
</span>    }
</span>}
</span></code></pre>
Ah, now a much more expected SIGSEV</code>. This means Rust is probably, actually, dereferencing uninitialized memory. But again, this is UB; you might see a different thing.</p>
Now, let's try one more slightly different thing.</p>
use </span>std::mem;
</span>use </span>std::task::Poll;
</span>use </span>std::task::Context;
</span>use </span>std::pin::Pin;
</span>async </span>fn </span>foo</span>() -> </span>u32 </span>{
</span>    </span>let mut</span> x </span>= </span>1</span>;
</span>    tokio::time::sleep(std::time::Duration::from_secs(</span>0</span>)).await;
</span>    x</span>+= </span>1</span>;
</span>    x
</span>}
</span>
</span>#[</span>tokio</span>::</span>main</span>]
</span>async </span>fn </span>main</span>() {
</span>
</span>    println!(</span>"</span>{}</span>"</span>, BadFuture.await);
</span>}
</span>
</span>struct </span>BadFuture;
</span>
</span>impl </span>Future </span>for </span>BadFuture {
</span>    </span>type </span>Output </span>= </span>u32</span>;
</span>    </span>fn </span>poll</span>(</span>self</span>: Pin<</span>&</span>mut Self</span>>, </span>cx</span>: </span>&</span>mut </span>Context<'</span>_</span>>) -> Poll<</span>Self::</span>Output> {
</span>        </span>let mut</span> x1 </span>= </span>foo</span>();
</span>        </span>let mut</span> x2 </span>= </span>foo</span>();
</span>
</span>        {
</span>            </span>let mut</span> a </span>= </span>unsafe </span>{ Pin::new_unchecked(</span>&</span>mut</span> x1) };
</span>            </span>let </span>_ =</span> a.</span>as_mut</span>().</span>poll</span>(cx);
</span>        }
</span>        
</span>        mem::swap(</span>&</span>mut</span> x1, </span>&</span>mut</span> x2);
</span>        
</span>        </span>let mut</span> a </span>= </span>unsafe </span>{ Pin::new_unchecked(</span>&</span>mut</span> x2) };
</span>        </span>let </span>_ =</span> a.</span>as_mut</span>().</span>poll</span>(cx);
</span>        
</span>        </span>let mut</span> i </span>= </span>0</span>;
</span>        </span>loop </span>{
</span>            i </span>+= </span>1</span>;
</span>            dbg!(i);
</span>            </span>if let </span>Poll::Ready(a) </span>=</span> a.</span>as_mut</span>().</span>poll</span>(cx) {
</span>                </span>return </span>Poll::Ready(a);
</span>            }
</span>        }
</span>    }
</span>}
</span></code></pre>
Aha! Now we failed an assertion in Tokio. Specifically, this:</p>
thread 'tokio-runtime-worker' panicked at /playground/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.45.1/src/runtime/time/wheel/mod.rs:233:17:
</span>assertion `left == right` failed
</span>  left: 106587145424240
</span> right: 1
</span></code></pre>
This is the line</a> where it fails. It's the internals of how sleep is implemented, probably; it might have its own state that's address-dependent, so we're probably messing with that.</p>
I'd be happy if someone knows the specifics. But it seems like it's not just our internal x</code> that's the problem; it's also the future in tokio::time::sleep</code>.</p>
So, yeah, it's good to keep this in mind next time you're suffering with Pin</code>.</p>



Method call resolution for type parameters
2025-07-08T00:00:00+00:00
The way method resolution works in Rust is specified in this section</a> of the reference.</p>
For a given type T</code> where a method is being called, it follows these steps:</p>

Start with a candidate list containing only T</code> (candidates := [T]</code>)</li>
Try to dereference (*</code>) the last element of the list(last</code>)</li>
If *last</code> is valid, add it to the list (candidates := candidates : [last]</code>) and go to the previous step. Else continue.</li>
AAttempt unsized coercion</a>, meaning vaguely, converting a sized type to its unsized variant (e.g. [T; N]</code> to [T]</code>)</li>
For each element t</code> on candidates</code> add &t</code> and &mut t</code></li>
For each t</code> in candidates</code>:

Check if t</code> inherently implements  (as in impl t { .. }</code> w/o <trait> for</code>) the method. If so, call it and finish.</li>
If t</code> is a type parameter,</a> check all methods on its bounded traits; if there's only one, call it and finish. If there are multiple, error out and finish; if there's none, continue.</li>
Check all methods on t</code> visible trait implementations; if there's one, call it and finish. If there are multiple error out; if there are none, move on to the next step.</li>
</ol>
</li>
Error out since there's no method.</li>
</ol>
Roughly, those are the steps. In the reference it already talks about a potentially unexpected result; all methods on &T</code> are searched before methods on &mut T</code>, so if a trait is implemented on a type &T</code> and &mut T</code> has an inherent impl (see 6.i), it'll call the trait impl on &T</code>.</p>
There are multiple other writings I saw about how reference and dereference interact in this definition.</p>
But I've never seen anything on what 6.ii being before 6.iii means. To put it in other words, the compiler searches traits constrained directly by the bounds on a type parameter before traits implied</em> by that bound.</p>
So in something like this.</p>
struct </span>Foo {}
</span>
</span>trait </span>Bar {
</span>  </span>fn </span>bar</span>(</span>&</span>self</span>); </span>// <--- This
</span>}
</span>
</span>trait </span>Baz {
</span>  </span>fn </span>bar</span>(</span>&</span>self</span>); </span>// <--- And this have the same name
</span>}
</span>
</span>impl </span>Bar </span>for </span>Foo {
</span>  </span>fn </span>bar</span>(</span>&</span>self</span>) {
</span>    println!(</span>"bar"</span>)
</span>  }
</span>}
</span>
</span>impl</span><T: Bar> Baz </span>for </span>T {
</span>  </span>fn </span>bar</span>(</span>&</span>self</span>) {
</span>    println!(</span>"baz"</span>)
</span>  }
</span>}
</span>
</span>fn </span>g</span><T: Bar>(</span>f</span>: T) {
</span>    f.</span>bar</span>();
</span>}
</span>
</span>fn </span>main</span>() {
</span>  </span>let</span> f </span>=</span> Foo{};
</span>  </span>g</span>(f);
</span>}
</span></code></pre>
bar</code> is printed. Because Bar</code> is bounded directly on T</code>. While, of course, this compiles without a problem.</p>
struct </span>Foo {}
</span>
</span>trait </span>Bar {
</span>  </span>fn </span>bar</span>(</span>&</span>self</span>); </span>// <--- Now here the name is different 
</span>}
</span>
</span>trait </span>Baz {
</span>  </span>fn </span>baz</span>(</span>&</span>self</span>); </span>// <--- From here
</span>}
</span>
</span>impl </span>Bar </span>for </span>Foo {
</span>  </span>fn </span>bar</span>(</span>&</span>self</span>) {
</span>    println!(</span>"bar"</span>)
</span>  }
</span>}
</span>
</span>impl</span><T: Bar> Baz </span>for </span>T {
</span>  </span>fn </span>baz</span>(</span>&</span>self</span>) {
</span>    println!(</span>"baz"</span>)
</span>  }
</span>}
</span>
</span>fn </span>g</span><T: Bar>(</span>f</span>: T) {
</span>    f.</span>baz</span>();
</span>}
</span>
</span>fn </span>main</span>() {
</span>  </span>let</span> f </span>=</span> Foo{};
</span>  </span>g</span>(f);
</span>}
</span></code></pre>
Printing baz</code>. Because Baz</code> is implied by Bar</code>. This leads to a small "quirk," if you want to call it so, wherein this next example doesn't compile, in contrast to the first one.</p>
struct </span>Foo {}
</span>
</span>trait </span>Bar {
</span>  </span>fn </span>bar</span>(</span>&</span>self</span>); </span>// <--- Here the name is the same
</span>}
</span>
</span>trait </span>Baz {
</span>  </span>fn </span>bar</span>(</span>&</span>self</span>); </span>// <--- As the name here
</span>}
</span>
</span>impl </span>Bar </span>for </span>Foo {
</span>  </span>fn </span>bar</span>(</span>&</span>self</span>) {
</span>    println!(</span>"bar"</span>)
</span>  }
</span>}
</span>
</span>impl</span><T: Bar> Baz </span>for </span>T {
</span>  </span>fn </span>bar</span>(</span>&</span>self</span>) {
</span>    println!(</span>"baz"</span>)
</span>  }
</span>}
</span>
</span>fn </span>main</span>() {
</span>  </span>let</span> f </span>=</span> Foo{};
</span>  f.</span>bar</span>();
</span>}
</span></code></pre>
Since now, both Bar</code> and Baz</code> are checked in the same step (6.iii) so they conflict with each other.</p>


Method call resolution in Rust for type parameters
2025-07-08T00:00:00+00:00
The way method resolution works in Rust is specified in this section</a> of the reference.</p>


Surprised about drop order behavior
2025-06-30T00:00:00+00:00
I was experimenting with the lifetime constraints for tokio channels, I wanted to understand how it enforces sane lifetimes for the type of the value sended.</p>


The scary and surprisingly deep rabbit hole of Rust's temporaries
2025-06-03T00:00:00+00:00
'twas a lovely Sunday afternoon when I decided to do some fun rust quiz</a>,
but a subtle mistake in the explanation of the answer ended up in hours of research
and a PR.</p>