<div dir="ltr"><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div dir="ltr">On Tue, 20 Feb 2024 at 21:44, Robert Coup <<a href="mailto:robert.coup@koordinates.com">robert.coup@koordinates.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Simon,</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 20 Feb 2024 at 21:11, Simon Eves <<a href="mailto:simon.eves@heavy.ai" target="_blank">simon.eves@heavy.ai</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Here's the stack trace for the original assert. Something is stepping on scratch_ to make it 0x1000000000 instead of null, which it starts out as when the flatbuffer object is created, but by the time it gets to allocating memory, it's broken.</div></blockquote><div><br></div>What happens if you set a watchpoint in gdb when the flatbuffer is created?<div><br></div><div><span style="color:rgb(0,0,0)"><font face="monospace">watch -l myfb->scratch</font></span></div><div><span style="color:rgb(0,0,0)">or </span><span style="color:rgb(0,0,0);font-family:monospace">watch *0x1234c0ffee</span></div></div></div></blockquote><div><br></div><div dir="ltr">Or I've also had success with Mozilla's rr: <a href="https://rr-project.org/">https://rr-project.org/</a> — you can run to a point where scratch is wrong, set a watchpoint on it, and then run the program backwards to find out what touched it.</div><div dir="ltr"><br></div><div>Rob :)</div></div></div>