* Pavel Labath:
> Yes, there's a dns lookup being done on the other end. TBH, I'm not
> really sure what's it being used for. Maybe we should try deleting the
> hostname field from the qHostInfo response (or just put an IP address
> there).
Or use the system host name without resorting to DNS (us
On 07/01/2019 13:22, Florian Weimer wrote:
* Pavel Labath:
Thanks. I think this is what I suspected. The server is extremely slow
in responding to the qHostInfo packet. This timeout for this was
recently increased to 10 seconds, but it looks like 7.0 still has the
default (1 second) timeout.
I
* Pavel Labath:
> Thanks. I think this is what I suspected. The server is extremely slow
> in responding to the qHostInfo packet. This timeout for this was
> recently increased to 10 seconds, but it looks like 7.0 still has the
> default (1 second) timeout.
>
> If you don't want to recompile or up
On 07/01/2019 09:29, Florian Weimer wrote:
* Pavel Labath:
On 04/01/2019 17:38, Florian Weimer via lldb-dev wrote:
Consider this example program:
#include
#include
#include
#include
#include
#include
int
main(void)
{
// Target process for the debugger.
pid_t pid = fork();
* Pavel Labath:
> On 04/01/2019 17:38, Florian Weimer via lldb-dev wrote:
>> Consider this example program:
>>
>> #include
>> #include
>> #include
>>
>> #include
>> #include
>> #include
>>
>> int
>> main(void)
>> {
>>// Target process for the debugger.
>>pid_t pid = fork();
>>if
On 04/01/2019 17:38, Florian Weimer via lldb-dev wrote:
Consider this example program:
#include
#include
#include
#include
#include
#include
int
main(void)
{
// Target process for the debugger.
pid_t pid = fork();
if (pid < 0)
err(1, "fork");
if (pid == 0)
while (tr
* Zachary Turner:
> I'd be curious to see if the PID of the process that is failed to
> attach to is the same as one of the PIDs of a process that was
> previously attached to (and if so, if it is the first such case where
> a PID is recycled).
I added logging of the PID, and got this (the failur
I'd be curious to see if the PID of the process that is failed to attach to
is the same as one of the PIDs of a process that was previously attached to
(and if so, if it is the first such case where a PID is recycled).
On Sat, Jan 5, 2019 at 4:42 AM Florian Weimer via lldb-dev <
lldb-dev@lists.llv
* Jan Kratochvil:
> On Fri, 04 Jan 2019 17:38:42 +0100, Florian Weimer via lldb-dev wrote:
>> Run it in a loop like this:
>>
>> $ while ./test-attach ; do date; done
>>
>> On Linux x86-64 (Fedora 29), with LLDB 7 (lldb-7.0.0-1.fc29.x86_64) and
>> kernel 4.19.12 (kernel-4.19.12-301.fc29.x86_64),
On Fri, 04 Jan 2019 17:38:42 +0100, Florian Weimer via lldb-dev wrote:
> Run it in a loop like this:
>
> $ while ./test-attach ; do date; done
>
> On Linux x86-64 (Fedora 29), with LLDB 7 (lldb-7.0.0-1.fc29.x86_64) and
> kernel 4.19.12 (kernel-4.19.12-301.fc29.x86_64), after 100 iterations or
> s
Consider this example program:
#include
#include
#include
#include
#include
#include
int
main(void)
{
// Target process for the debugger.
pid_t pid = fork();
if (pid < 0)
err(1, "fork");
if (pid == 0)
while (true)
pause();
lldb::SBDebugger::Initialize();
{
au
11 matches
Mail list logo
