Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

1%7C0%7C636679357598185483&sdata=65R5UyPEArGn2q27sklUPc8bUEAOjPK2OBi91SMVuzM%3D&reserved=0>? We can discuss the approach there. On Fri, 20 Jul 2018 at 23:55, Eugene Birukov via lldb-dev wrote: > > I have a small fix – pass platform sysroot to ModuleList::GetSharedModule. > The fix works for me. > &g

Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

m_sdk_sysroot.AsCString()); if (error.Success() && module_sp) module_sp->SetPlatformFileSpec( spec.GetFileSpec()); From: lldb-dev mailto:lldb-dev-boun...@lists.llvm.org>> On Behalf Of Eug

Re: [lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Eugene Birukov via lldb-dev Sent: Friday, July 20, 2018 1:13 PM To: lldb-dev@lists.llvm.org<mailto:lldb

[lldb-dev] LLDB does not respect platform sysroot when loading core on Linux

Hello, I would appreciate advise how to fix this correctly... I have a core dump from somebody's RHEL Linux and I am trying to open it on my Ubuntu. I have all the shared libraries from the target sitting under my local directory. So, GDB happily opens the core after I issue "set sysroot /path

Re: [lldb-dev] ELF header does not hold big modules

h_size member of the initial entry contains 0.) See the second paragraph. I am guessing the same thing would need to happen for program headers? I would check the various ELF file parsers in LLVM and see if they handle this correctly? Greg On Jan 23, 2017, at 3:26 PM, Eugene Biru

Re: [lldb-dev] ELF header does not hold big modules

> By "all" I presume you mean "all fields that refer to section counts or > indexes". Correct. I mean exactly 3 fields: e_phnum, e_shnum, and e_shstrndx that could be redirected to section #0. Sent from Outlook From: Pavel Labath S

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

ch-paths add” as a replacement for “set solib-search-path” > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On B

[lldb-dev] ELF header does not hold big modules

Hello, I have a core dump that LLDB cannot open because it contains more than 64K sections. The "readelf" utility gives me the output in the end of this message. It seems that the actual number of program headers and the index of string table section are written into very first section since t

Re: [lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

own address space. (With a sufficiently large chunk, this should not affect performance of normal reads). hope that helps, pl On 19 January 2017 at 19:41, Eugene Birukov via lldb-dev wrote: > Hi, > > > I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would > greatly

[lldb-dev] LLDB 3.9 on Linux crashes when loading core dump

Hi, I have a Linux core dump that causes LLDB 3.9 on Linux crash. I would greatly appreciate any advise how to deal with the problem or what else I should look at. The core dump was produced by GDB and GDB itself opens it without problems. So, during loading the core we call DynamicLoaderP

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

case it would repro on 3 out of 4 kind of "identical" machines. I do not have simple repro, but I can find victim VM that we do not care much about. Is there a way to cause Linux kernel core dump there? Sent from Outlook<http://aka.ms/weboutlook>

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

ot;identical" machines. I do not have simple repro, but I can find victim VM that we do not care much about. Is there a way to cause Linux kernel core dump there? Sent from Outlook<http://aka.ms/weboutlook> From: lldb-dev mailto:lldb-dev-boun...@lists

Re: [lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

bly detailed repro steps, I can try to investigate (I am fine with the first step being "install ubuntu 16.04 in virtualbox") On 6 December 2016 at 23:41, Eugene Birukov via lldb-dev wrote: > Hi, > 1. I believe that lldb-server spins inside ptrace. I put breakpoint on the >

[lldb-dev] Lldb-server spins forever in ptrace with 100% CPU on Linux Ubuntu 16.04

Hi, I am running Linux Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-51-generic x86_64) in virtual machine. When I am trying to write memory in my process, sometimes it works but sometimes lldb-server goes unresponsive. It spins with 100% CPU utilization and does not respond to any signals except SIGK

Re: [lldb-dev] File::Read does not read everything

th context) to phabricator and add lldb-commits as a subscriber and myself / Greg as reviewers? On Mon, Oct 17, 2016 at 4:59 PM Eugene Birukov via lldb-dev mailto:lldb-dev@lists.llvm.org>> wrote: Here is what I am running now: diff --git a/source/Host/common/File.cpp b/source/Host/common/File.c

Re: [lldb-dev] File::Read does not read everything

ukov; Greg Clayton Cc: LLDB Subject: Re: [lldb-dev] File::Read does not read everything Can you upload a diff (with context) to phabricator and add lldb-commits as a subscriber and myself / Greg as reviewers? On Mon, Oct 17, 2016 at 4:59 PM Eugene Birukov via lldb-dev mailto:lldb-dev@lists.llvm.

Re: [lldb-dev] File::Read does not read everything

d more than that it reads nothing. So MAX_READ_SIZE is more for the case where the read will outright fail if given a byte size that is too large. Feel free to submit a patch that can keep calling pread correctly in a loop as long as bytes_read > 0. Greg > On Oct 17, 2016, at 12:20 P

[lldb-dev] File::Read does not read everything

Hello, I am using LLDB 3.9 on Linux Ubuntu. I am loading a 5GiB core which is located on Windows file share mounted on Linux via mount.cifs. I see that we successfully allocated memory and are trying to fill it in one read. Unfortunately pread returns 2GiB and we never check for short read her

Re: [lldb-dev] Memory corruption due to Symtab::AddSymbol growth

Hi, I am looking through LLDB code... Another dangerous operation is Symtab::Finalize() that just swaps the array. This is especially bad since it will defeat something like quick-and-dirty hack of preallocating a huge vector upfront. My first impulse to fix that (maybe just temporary to get me

[lldb-dev] Memory corruption due to Symtab::AddSymbol growth

Hi, I am running into memory corruption in LLDB 3.8 release candidate on Linux Ubuntu 15.10. I am trying to access stack frame and the symbol on this frame is corrupted. Here is what I figured out: "StackFrame" has field "m_sc" of type "SymbolContext""SymbolContext" has field "symbol" which is "

Re: [lldb-dev] SBProcess::Detach kills target

OK, I got the picture, thanks a lot! > What is it that you are trying to do anyway? Well, target termination during detach is unexpected, so my customers might get confused. Fortunately I am in control of the target program too, so I'll just ignore SIGHUP for the time being. Thanks,Eugene

Re: [lldb-dev] SBProcess::Detach kills target

Just a wild guess - is this SIGHUP because stdin/stdout are broken? I.e. the debugger closes its pty's on detach and that causes the signal?What is the behavior on MAC? To: lab...@google.com Date: Wed, 30 Mar 2016 14:49:33 -0700 CC: lldb-dev@lists.llvm.org Subject: Re: [lldb-dev] SBProcess::Deta

Re: [lldb-dev] SBProcess::Detach kills target

Right, my bad. The problem was that when debugger detaches the stdio does not go anywhere so I failed to see my printf. Still, is this how it is supposed to be? I naively assume that if we don't send SIGHUP in attach scenario we should not send it in launch scenario too. Thanks,Eugene > From: la

Re: [lldb-dev] SBProcess::Detach kills target

ach if we attached. > >> But only when we quit without telling it to do something. If we did: > >> > >> % lldb /bin/ls > >> (lldb) b malloc > >> (lldb) run > >> (lldb) detach > >> > >> Then this should always detach if the user explic

[lldb-dev] SBProcess::Detach kills target

Hi, Is this expected behavior or am I doing something wrong? I am running my C++ program that uses LLDB API on Linux Ubuntu 15.10. If I attach to already running process then SBProcess::Detach() behaves as expected - my debugger quits and the target keeps running. But if the target was launched b

Re: [lldb-dev] How to enumerate stopped threads in C++ API?

t; to return a new list for all threads with stop reasons. > > That being said, hundreds of threads should not cause a huge bottleneck for > single stop, but if you doing it many many many times it could be. > > Greg Clayton > > > On Mar 3, 2016, at 9:54 AM, Eugene Biruk

[lldb-dev] How to enumerate stopped threads in C++ API?

Hi, I am working on a custom debugger on Linux and I am using LLDB C++ API for that. So far, from the functionality point of view the life is good, but I am running into severe performance issue. The problem is that the target application has literally hundreds of threads, and when the target pr

Re: [lldb-dev] Problems with core load on Linux and proposed solution

No response. I filed a bug, hopefully somebody will pay attention. https://llvm.org/bugs/show_bug.cgi?id=26322 From: mi...@microsoft.com To: eugen...@hotmail.com; lldb-dev@lists.llvm.org Subject: RE: Problems with core load on Linux and proposed solution Date: Thu, 25 Feb 2016 22:37:45 +

[lldb-dev] Problems with core load on Linux and proposed solution

Hi, LLDB 3.8 has much better support for core load on Linux than 3.7 - thanks a lot! But there are still two problems. 1. The thread ID are lost and there is FIXME in the code2. If core dump is obtained from live process (i.e. gdb attach, gcore, detach) then there is no thread that has any reaso

Re: [lldb-dev] How to load core on a different machine?

Correction: platform trick almost works. For some reason two libraries are not affected, but the rest are OK. Hmm... image list does not have load addresses.I'll trace what read memory does... Does the core contain this memory or is it loaded from the library file? eugene@EUGENEBI-L1:~/tmp$ ~/ll

Re: [lldb-dev] How to load core on a different machine?

-sysroot /path/to/remote/shared/libraries > > > remote-linux > > > (lldb) > > > > > > If this works, there are SBPlatform class calls in the API you can use > > > the select the platform as done above if you need to not do this from the > >

Re: [lldb-dev] How to load core on a different machine?

line. > > The other option is to chroot into /path/to/remote/shared/libraries and you > will need to copy your core file into /path/to/remote/shared/libraries, then > just run LLDB normally and it should work. > > Greg Clayton > > > On Jan 5, 2016, at 12:53 PM, Eugene

[lldb-dev] How to load core on a different machine?

Hi, I am using LLDB-3.7 on Ubuntu Linux. I have a core dump file and all shared libraries from my server but I want to investigate them on a dev box. But I fail to correctly load it in LLDB - it shows wrong stacks. I.e. I am looking for something equivalent to GDB commands "set solib-absolute-pr

Re: [lldb-dev] Is there a way to inspect signaled stack?

ere. Could you file a bug with a small repro case and attach the > output of (thread backtrace) with logging enabled (log enable lldb > unwind). We'll try to look at it. > > thanks, > pl > > > On 13 November 2015 at 19:22, Eugene Birukov via lldb-dev > wrote: >

[lldb-dev] Is there a way to inspect signaled stack?

Hi, I am running on Ubuntu Linux. I am using a custom debugger built upon LLDB C++ API using version 3.7. The target program issues a lot of "legitimate" SIGSEGV signals that it handles itself. Its signal handler runs on a separate stack (it uses sigaltstack() and SA_ONSTACK). Now, sometimes a b

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

Will do! > From: lab...@google.com > Date: Tue, 13 Oct 2015 09:40:28 +0100 > Subject: Re: [lldb-dev] Thread resumes with stale signal after executing > InferiorCallMmap > To: eugen...@hotmail.com > CC: lldb-dev@lists.llvm.org; jing...@apple.com > > Sure, fair enough. > > If you have made a smal

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

I tried to repro it using standard LLDB client on a simple program that I could share. Well, the problem does not exactly repro as in my case - i.e. the signal is not re-delivered to the thread. But LLDB does get confused state: the program continues but at the same time lldb shows its prompt as

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

h stale signal after executing > >> > InferiorCallMmap > >> > From: jing...@apple.com > >> > Date: Wed, 7 Oct 2015 15:08:18 -0700 > >> > CC: lldb-dev@lists.llvm.org > >> > To: eugen...@hotmail.com > >> > > >> &

Re: [lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

e out why it behaves this way on Linux, so whatever > we do we're implementing it consistently. > > Jim > > > > > On Oct 7, 2015, at 12:03 PM, Eugene Birukov via lldb-dev > > wrote: > > > > Hi, > > > > I am using LLDB 3.7.0 C++ API

[lldb-dev] Thread resumes with stale signal after executing InferiorCallMmap

Hi, I am using LLDB 3.7.0 C++ API. My program stops at a certain breakpoint and if I call SBFrame::EvaluateExpression() there, when I let it go it terminates with SIG_ILL on an innocent thread. I dug up into this, and there seems to be two independent problems there, this mail is about the sec

Re: [lldb-dev] How to debug LLDB server?

GDB > Remote in InferiorCallPOSIX.cpp: > > #ifdef LLDB_CONFIGURATION_DEBUG > options.SetTimeoutUsec(5000); > #else > options.SetTimeoutUsec(50); > #endif > > > > On Oct 7, 2015, at 10:33 AM, Eugene Birukov via lldb-dev > > wrote: > > >

[lldb-dev] How to debug LLDB server?

Hello, I am trying to see what is going inside LLDB server 3.7.0 but there are a lot of timeouts scattered everywhere. Say, InferiorCallPOSIX.cpp:74 sets hard-coded timeout to 500,000us, etc. These timeouts fire if I spend any time on breakpoint inside server and make debugging experience mise

[lldb-dev] Is it possible to get core dump on Linux?

Hi, Is there a way to create process dump on Linux using LLDB? I am using Ubuntu 14.04 and LLDB 3.7 that I built from sources a while ago.I tried "process save-core" and it doesn’t work: (lldb) process save-core ~/xxx error: Failed to save core file for process: no ObjectFile plugins were

[lldb-dev] How to deal with STL type names in C++ code?

Hi, I am using LLDB C++ API to create custom debugger and trying to dump variables with their types. To do that I am using SBValue.GetTypeName() API. Some types are OK, but some others - especially ones related to STL - are quite unreadable: (gdb) p value.GetTypeName()$1 = 0x7fffe419be40 "std::_