llvm-project/lldb
Greg Clayton d9896733c7 <rdar://problem/11486302>
Fixed a case where multiple threads can be asking to send a packet to the GDB server and one of three things will happen:
1 - everything works
2 - one thread will fail to send the packet due to not being able to get the sequence mutex
3 - one thread will try and interrupt the other packet sending and fail and not send the packet

Now the flow is a bit different. Prior to this fix we did:

if (try_get_sequence_mutex()) {
    send_packet()
    return success;
} else {
   if (async_ok) {
       interrupt()
       send_packet() 
       resume()
       return success;
   }
}
return fail

The issue is that the call to "try_get_sequence_mutex()" could fail if another thread was sending a packet and could cause us to just not send the packet and an error would be returned.

What we really want is to try and get the sequence mutex, and if this succeeds, send the packet. Else check if we are running and if we are, do what we used to do. The big difference is when we aren't running, we wait for the sequence mutex so we don't drop packets. Pseudo code is:

if (try_get_sequence_mutex()) {
    // Safe to send the packet right away
    send_packet()
    return success;
} else {
    if (running) {
       // We are running, interrupt and send async packet if ok to do so,
       // else it is ok to fail
       if (async_ok) {
           interrupt()
           send_packet() 
           resume()
           return success;
        }
    }
    else {
        // Not running, wait for the sequence mutex so we don't drop packets
        get_sequence_mutex()
        send_packet()
        return success;
    }
}
return fail

llvm-svn: 157751
2012-05-31 16:54:51 +00:00
..
docs When unwinding from the first frame, try to ask the remote debugserver 2011-12-13 05:39:38 +00:00
examples Fixes for performance to data formatters - Python < 3.0 is much slower when using True/False as compared to 1/0 for logical values. Wexploit this to our advantage. Other minor tweaks 2012-05-21 21:52:38 +00:00
include <rdar://problem/11328896> Fixing a bug where regex commands were saved in the history even if they came from a 'command sourced' file - this fix introduces a command sourcing depth and disables history for all levels of depth > 0, which means no commands go into history when being sourced from a file. we need an integer depth because command files might themselves source other command files, ... 2012-05-31 01:09:06 +00:00
lib Continue the work started by Dragos' Makefile patch (LLVMLibsOptions usage) 2012-05-29 13:41:50 +00:00
lldb.xcodeproj Bump to lldb 152. 2012-05-25 02:05:58 +00:00
lldb.xcworkspace I accidentally committed some changes to the 2011-12-21 21:30:33 +00:00
resources Bump to lldb 152. 2012-05-25 02:05:58 +00:00
scripts For dump_register_value() sub-routine, issue a return after an error condition occurs. 2012-05-30 00:29:12 +00:00
source <rdar://problem/11486302> 2012-05-31 16:54:51 +00:00
test Mark the test as failing on both architectures, since LLDB won't handle the function to clang. 2012-05-30 05:44:59 +00:00
tools Make dbgnub-config.pl work with multiline env vars. 2012-05-30 00:44:14 +00:00
utils Minor cleanup. 2012-03-05 18:25:29 +00:00
www Added a GDB equivalent for saving binary memory 2012-05-21 17:01:59 +00:00
.gitignore Remove "llvm" from list of things to ignore. This results in the 2012-03-03 06:43:59 +00:00
INSTALL.txt You'll need to be running Mac OS X to get lldb to build right now. 2010-06-09 07:29:26 +00:00
LICENSE.TXT test commit 2010-06-09 03:55:24 +00:00
Makefile Revert the RTTI change from r151187. It make lldb compile with g++ 4.4 but it doesn't link anymore. The bug seems to be fixed in g++ 4.5. 2012-02-22 21:00:17 +00:00