<div dir="ltr">I've come up with a consistent repro for this.<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
#include <stdio.h><br>#include <dlfcn.h><br>int main( int argc, char *argv[] )<br>{<br> printf( "hello world\n" );<br> void *blah = dlopen("/usr/lib/libbfd.so", RTLD_NOW);<br> printf("blah is %p\n", blah);<br>
if (blah)<br> dlclose(blah);<br>}</blockquote></div><div><br></div><div>1. Compile the above program.</div><div>2. run "lldb -x -- blah"</div><div>3. b main</div><div>4. r</div><div>5. expr argc = 2</div>
<div>6. n</div><div>7. n</div><div><br></div><div>You should hit the assert on step 7 when you "next" over the dlopen() statement. If you don't do step 5, everything is fine. The difference is info.state comes in as add in the assert case and consistent otherwise.</div>
<div><br></div><div>I'll look at this more tomorrow.<br></div><div> -Mike</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 14, 2013 at 9:54 AM, Kopec, Matt <span dir="ltr"><<a href="mailto:matt.kopec@intel.com" target="_blank">matt.kopec@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Unfortunately, the original author of the majority of the original POSIX/Linux code isn't around anymore.<br>
<br>
However, looking into the issue, I think the code here is expecting an eConsistent state after an eAdd/eDelete since the library entries don't get updated until you actually get the eConsistent state. This is probably why there is an m_previous and m_current.<br>
<br>
Maybe the behaviour you see is ok. I'm not sure. I think better understanding of the system dynamic linker/loader behaviour here may be needed.<br>
<br>
Curiously, do you get the same assert without a step? i.e. just running?<br>
<br>
Thanks,<br>
Matt<br>
<div><div class="h5"><br>
On 2013-06-13, at 9:50 PM, Michael Sartain <<a href="mailto:mikesart@gmail.com">mikesart@gmail.com</a>> wrote:<br>
<br>
> I just hit the below assert on line 138 stepping over a dlclose().<br>
><br>
> 120| bool<br>
> 121| DYLDRendezvous::UpdateSOEntries()<br>
> 122| {<br>
> 123| SOEntry entry;<br>
> 124|<br>
> 125| if (m_current.map_addr == 0)<br>
> 126| return false;<br>
> 127|<br>
> 128| // When the previous and current states are consistent this is the first<br>
> 129| // time we have been asked to update. Just take a snapshot of the currently<br>
> 130| // loaded modules.<br>
> 131| if (m_previous.state == eConsistent && m_current.state == eConsistent)<br>
> 132| return TakeSnapshot(m_soentries);<br>
> 133|<br>
> 134| // If we are about to add or remove a shared object clear out the current<br>
> 135| // state and take a snapshot of the currently loaded images.<br>
> 136| if (m_current.state == eAdd || m_current.state == eDelete)<br>
> 137| {<br>
> 138+> assert(m_previous.state == eConsistent);<br>
> 139| m_soentries.clear();<br>
> 140| m_added_soentries.clear();<br>
> 141| m_removed_soentries.clear();<br>
> 142| return TakeSnapshot(m_soentries);<br>
> 143| }<br>
><br>
> It's called by this code in DYLDRendezvous::Resolve():<br>
><br>
> 106| // The rendezvous was successfully read. Update our internal state.<br>
> 107| m_rendezvous_addr = info_addr;<br>
> 108| m_previous = m_current;<br>
> 109| m_current = info;<br>
> 110|<br>
> 111+> return UpdateSOEntries();<br>
><br>
> m_previous is being set to m_current and both are eDelete now, but that assert above is claiming it should be eConsistent.<br>
><br>
> Is this a bogus assert, or is the Resolve() function messing with m_previous when it shouldn't be?<br>
> -Mike<br>
</div></div>> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div><br></div></div>