Re: [lldb-dev] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback
Hello, Ravi - you're welcome. I haven't filled a bug in lldb bug tracker, just
mailed to dev list.
Mikhail
-Original Message-
From: Addepally, Ravitheja [mailto:ravitheja.addepa...@intel.com]
Sent: Tuesday, November 17, 2015 12:34 PM
To: Pavel Labath ; Mikhail Filimonov
Cc: lldb-dev@lists.llvm.org
Subject: RE: [lldb-dev] Invalid iterator dereference in TypeMap::ForEach when
it's invoked with TypeMaptoList callback
Hello,
Yeah you are right Mikhail, thanks for pointing it out, I must ask, is
there any bug already logged for this issue ?
Ravi
-Original Message-
From: Pavel Labath [mailto:lab...@google.com]
Sent: Monday, November 16, 2015 5:34 PM
To: Mikhail Filimonov ; Addepally, Ravitheja
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Invalid iterator dereference in TypeMap::ForEach when
it's invoked with TypeMaptoList callback
Thanks for the heads-up Mikhail.
Ravi,
this looks like your code. Could you take a look at this?
pl
On 16 November 2015 at 16:24, Mikhail Filimonov via lldb-dev
wrote:
> Hi guys and thank you for the excellent community project!
>
>
>
> Recently I’ve stumbled on a pesky, but trivial Invalid iterator
> dereference bug in SymbolContext and TypeMap implementations at
> revisions
>
> https://github.com/llvm-mirror/lldb/blob/e528da256d14ecac7df858462b44d
> ca931879509/source/Symbol/SymbolContext.cpp#L823
>
> and
>
> https://github.com/llvm-mirror/lldb/blob/5ac1fc5bc961688505334395598a2
> bb174eabd3b/source/Symbol/TypeMap.cpp#L172
>
>
>
> From the code below it is obvious that TypeMap::ForEach calls the
> pre-increment operator on m_types iterator right after it has been
> invalidated by m_types.erase
>
>
>
> SymbolContext::SortTypeList(TypeMap &type_map, TypeList &type_list )
> const
>
> {
>
> TypeMaptoList callbackM2L (type_map, type_list);
>
> type_map.ForEach(callbackM2L);
>
> return ;
>
> }
>
>
>
> void
>
> TypeMap::ForEach (std::function const
> &callback)
>
> {
>
> for (auto pos = m_types.begin(), end = m_types.end(); pos != end;
> ++pos)
>
> {
>
> if (!callback(pos->second))
>
> break;
>
> }
>
> }
>
>
>
> bool
>
> TypeMap::RemoveTypeWithUID (user_id_t uid)
>
> {
>
> iterator pos = m_types.find(uid);
>
>
>
> if (pos != m_types.end())
>
> {
>
> m_types.erase(pos);
>
> return true;
>
> }
>
> return false;
>
> }
>
>
>
> class TypeMaptoList
>
> {
>
> public:
>
> TypeMaptoList(TypeMap &typem, TypeList &typel) :
>
> type_map(typem),type_list(typel)
>
> {
>
> }
>
>
>
> bool
>
> operator() (const lldb::TypeSP& type)
>
> {
>
> if(type)
>
> {
>
> type_list.Insert(type);
>
> type_map.RemoveTypeWithUID(type->GetID());
>
> if (type_map.Empty())
>
> return false;
>
> }
>
> return true;
>
> }
>
>
>
> private:
>
> TypeMap &type_map;
>
> TypeList &type_list;
>
> };
>
>
>
> Regards,
>
> Mikhail Filimonov
>
>
>
>
>
>
>
>
> This email message is for the sole use of the intended recipient(s)
> and may contain confidential information. Any unauthorized review,
> use, disclosure or distribution is prohibited. If you are not the
> intended recipient, please contact the sender by reply email and
> destroy all copies of the original message.
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of
the Supervisory Board: Nicole Lau Registered Office: Munich Commercial
Register: Amtsgericht Muenchen HRB 186928
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback
Hello,
Yeah you are right Mikhail, thanks for pointing it out, I
must ask, is there any bug already logged for this issue ?
Ravi
On Mon, Nov 16, 2015 at 5:24 PM, Mikhail Filimonov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi guys and thank you for the excellent community project!
>
>
>
> Recently I’ve stumbled on a pesky, but trivial Invalid iterator
> dereference bug in SymbolContext and TypeMap implementations at revisions
>
>
> https://github.com/llvm-mirror/lldb/blob/e528da256d14ecac7df858462b44dca931879509/source/Symbol/SymbolContext.cpp#L823
>
> and
>
>
> https://github.com/llvm-mirror/lldb/blob/5ac1fc5bc961688505334395598a2bb174eabd3b/source/Symbol/TypeMap.cpp#L172
>
>
>
> From the code below it is obvious that TypeMap::ForEach calls the
> pre-increment operator on m_types iterator right after it has been
> invalidated by m_types.erase
>
>
>
> SymbolContext::SortTypeList(TypeMap &type_map, TypeList &type_list ) const
>
> {
>
> TypeMaptoList callbackM2L (type_map, type_list);
>
> type_map.ForEach(callbackM2L);
>
> return ;
>
> }
>
>
>
> void
>
> TypeMap::ForEach (std::function const
> &callback)
>
> {
>
> for (auto pos = m_types.begin(), end = m_types.end(); pos != end;
> ++pos)
>
> {
>
> if (!callback(pos->second))
>
> break;
>
> }
>
> }
>
>
>
> bool
>
> TypeMap::RemoveTypeWithUID (user_id_t uid)
>
> {
>
> iterator pos = m_types.find(uid);
>
>
>
> if (pos != m_types.end())
>
> {
>
> m_types.erase(pos);
>
> return true;
>
> }
>
> return false;
>
> }
>
>
>
> class TypeMaptoList
>
> {
>
> public:
>
> TypeMaptoList(TypeMap &typem, TypeList &typel) :
>
> type_map(typem),type_list(typel)
>
> {
>
> }
>
>
>
> bool
>
> operator() (const lldb::TypeSP& type)
>
> {
>
> if(type)
>
> {
>
> type_list.Insert(type);
>
> type_map.RemoveTypeWithUID(type->GetID());
>
> if (type_map.Empty())
>
> return false;
>
> }
>
> return true;
>
> }
>
>
>
> private:
>
> TypeMap &type_map;
>
> TypeList &type_list;
>
> };
>
>
>
> Regards,
>
> Mikhail Filimonov
>
>
>
>
>
>
> --
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information. Any unauthorized review, use,
> disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
> --
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] No machine instructions loaded for symbols or target (python api)
Hi, I'm building an application on windows using the python api. I need to be able to access a code symbols instructions but when I launch the process the symbol has no instructions. I can manually read the symbols address space but the symbol also has no end_addr set which makes it difficult to tell where the symbol ends . Can anybody help me to find out how to generate the instructions when the process is loaded ? cheers, Que ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] No machine instructions loaded for symbols or target (python api)
It sounds like the symbols in the symbol table don't have valid sizes when they really should. What kind of executable are you debugging? A PECOFF file? If so, you should take a look at and fix the code in: Symtab * ObjectFilePECOFF::GetSymtab() What we do for mach-o is to parse the symbol table first and then run back through all symbols, and any symbol that have a size of zero, set their sizes to the delta between the current symbol and the next addressed symbol. Since the symbols are usually out of order address wise, we run through all symbols that have addresses and add their indexes to a std::vector, then sort the vector of address indexes, and then we can do the above fixups. Greg Clayton > On Nov 17, 2015, at 4:21 AM, kwadwo amankwa via lldb-dev > wrote: > > Hi, > I'm building an application on windows using the python api. I need to be > able to access a code symbols instructions but when I launch the process the > symbol has no instructions. I can manually read the symbols address space but > the symbol also has no end_addr set which makes it difficult to tell where > the symbol ends . > Can anybody help me to find out how to generate the instructions when the > process is loaded ? > > cheers, > > Que > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] No machine instructions loaded for symbols or target (python api)
Ok I see what you're saying. I was trying to use the next symbol address as a delimeter but I realised they were not in order. It is a PECOFF binary that I'm debugging so I will take a look at the code suggested below. Thanks , Que On 17/11/15 18:07, Greg Clayton wrote: It sounds like the symbols in the symbol table don't have valid sizes when they really should. What kind of executable are you debugging? A PECOFF file? If so, you should take a look at and fix the code in: Symtab * ObjectFilePECOFF::GetSymtab() What we do for mach-o is to parse the symbol table first and then run back through all symbols, and any symbol that have a size of zero, set their sizes to the delta between the current symbol and the next addressed symbol. Since the symbols are usually out of order address wise, we run through all symbols that have addresses and add their indexes to a std::vector, then sort the vector of address indexes, and then we can do the above fixups. Greg Clayton On Nov 17, 2015, at 4:21 AM, kwadwo amankwa via lldb-dev wrote: Hi, I'm building an application on windows using the python api. I need to be able to access a code symbols instructions but when I launch the process the symbol has no instructions. I can manually read the symbols address space but the symbol also has no end_addr set which makes it difficult to tell where the symbol ends . Can anybody help me to find out how to generate the instructions when the process is loaded ? cheers, Que ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 25562] New: Some failing tests are being reported as passes
https://llvm.org/bugs/show_bug.cgi?id=25562 Bug ID: 25562 Summary: Some failing tests are being reported as passes Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ztur...@google.com CC: llvm-b...@lists.llvm.org Classification: Unclassified If I run this test manually, two of the tests fails. Example: d:\src\llvmbuild\ninja\lldb-test-traces>c:\python27_lldb\x86\python_d.exe D:\src\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable D:/src/llvmbuild/ninja/bin/lldb.exe -s D:/src/llvmbuild/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\process_launch --no-multiprocess The 'lldb-mi' executable cannot be located. The lldb-mi tests can not be run as a result. UNSUPPORTED: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_environment_with_special_char_dsym (TestProcessLaunch.ProcessLaunchTestCase) (dsym tests) FAIL: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_environment_with_special_char_dwarf (TestProcessLaunch.ProcessLaunchTestCase) FAIL: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_environment_with_special_char_dwo (TestProcessLaunch.ProcessLaunchTestCase) UNSUPPORTED: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_io_dsym (TestProcessLaunch.ProcessLaunchTestCase) (dsym tests) PASS: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_io_dwarf (TestProcessLaunch.ProcessLaunchTestCase) PASS: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_io_dwo (TestProcessLaunch.ProcessLaunchTestCase) UNSUPPORTED: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_set_working_dir_dsym (TestProcessLaunch.ProcessLaunchTestCase) (dsym tests) When I run the multiprocess test runner via dosep, it's being reported as a success. 410 out of 410 test suites processed - TestAddDsymCommand.py Ran 410 test suites (1 failed) (0.243902%) Ran 318 test cases (4 failed) (1.257862%) Failing Tests (1) FAIL: LLDB (suite) :: TestBreakpointLanguage.py (Windows zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel) [79964 refs] ninja: build stopped: subcommand failed. Stepping through the code, in dosep.py when it goes to print the summary list of failed tests, 'TestProcessLaunch.py' is in the list of passed tests. So something is wrong here, and a potentially unknown number of tests are currently being misreported. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.
Moving this back over to the list since I'm sure others have some input here. Also +lldb-dev since it has more visibility than lldb-commits. On Tue, Nov 17, 2015 at 11:25 AM Zachary Turner wrote: > On Tue, Nov 17, 2015 at 8:18 AM Todd Fiala wrote: > >> Breaking out the binding generation into a separate step will also be >> important for a couple reasons: >> >> * (from before) I want to eliminate the requirement for the vast majority >> of the builds to have a swig on their system, and >> >> * (not stated before) we'd like to move away from swig for binding >> generation at some point. >> >> -Todd >> > > Unless these plans (i.e. moving away from swig) are imminent, I would > prefer to keep the binding generation step automatic so people can use > whatever swig version is installed on their system. I know there are pros > and cons to each, but at the end of the day, we need various bugfixes from > newer versions of SWIG for the Python 3 stuff, and if someone decides they > want bindings for Go, or Rust, or some other languages, they too might need > a different minimum SWIG version. We could start checking in multiple sets > of generated bindings, but then we start having multiple maintainers, and > the checked in bindings become out of sync with each other, and it's more > trouble than it's worth. > > We have buildbots building and testing the various configurations, so if > someone uses something that is incompatible we shoudl catch it. And just > yesterday I added some options to the @expectedFailure and @skipIf > decorators that allow you to skip tests based on the SWIG version and/or > python version. > > Letting people using the SWIG on their system is the easiest way to ensure > that everyone's needs are still met while still getting early notification > when someone does something incompatible, and it can be fixed. > > One possibility (which I mentioned to you offline, but I'll put it here for others to see) is that we make a swig bot which is hosted in the cloud much like our public build bots. We provide a Python script that can be run on your machine, which sends requests over to the swig bot to run swig and send back the results. Availability of the service would be governed by the SLA of Google Compute Engine, viewable here: https://cloud.google.com/compute/sla?hl=en If we do something like this, it would allow us to raise the SWIG version in the upstream, and at that point I can see some benefit in checking the bindings in. Short of that, I still dont' see the value proposition in checking bindings in to the repo. So far all I've heard is that it is so that we don't need swig to be on everyone's machines, but I also don't see the value proposition in that either, given that we already require many other tools on peoples' machines. If it means we can get off of SWIG 1.x in the upstream, I will do the work to make remote swig generation service and get it up and running. From the user's perspective, it's already identical to what you're proposing. No swig executable on your machine (or anyone's machine for that matter), and you run a simple script to generate bindings and check them in whenever you make changes. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.
Stepping one step back further in the thread ... On Wed, Nov 18, 2015 at 8:35 AM, Zachary Turner via lldb-commits < lldb-comm...@lists.llvm.org> wrote: > Moving this back over to the list since I'm sure others have some input > here. Also +lldb-dev since it has more visibility than lldb-commits. > > > On Tue, Nov 17, 2015 at 11:25 AM Zachary Turner > wrote: > >> On Tue, Nov 17, 2015 at 8:18 AM Todd Fiala wrote: >> >>> Breaking out the binding generation into a separate step will also be >>> important for a couple reasons: >>> >>> * (from before) I want to eliminate the requirement for the vast >>> majority of the builds to have a swig on their system, and >>> >>> * (not stated before) we'd like to move away from swig for binding >>> generation at some point. >>> >> Is there any discussion or thoughts about what the options would be for moving away from swig? - Bruce ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.
Nothing concrete at the moment; however, it could be interesting to look at the clang community and see what could be done for llvm-based language implementations. The angle that I think would be interesting would be if we can generate bindings more effectively based on the in-depth understanding of the language that is afforded by languages built on top of LLVM. This is probably less interesting for Python (particularly since we have a functioning solution) and more interesting for languages built on LLVM or clang. Honestly, though, I haven't spent much time on that. For the time being, I am going to not change the path for everyone on swig, and only use a static binding if swig cannot be found. This will be minimal impact for everyone and doesn't interfere with anyone using a specific version of swig. We can revisit larger questions about who/what/when on static bindings after we gain some experience with enabling them for those who don't have swig. We can review and adjust based on our collective experience. The two files this seems like it will be are the LLDBWrapPython.cpp and the lldb.py file that comes out of python. I hope to have this working in the next day or so. On Tue, Nov 17, 2015 at 7:26 PM, Bruce Mitchener wrote: > Stepping one step back further in the thread ... > > On Wed, Nov 18, 2015 at 8:35 AM, Zachary Turner via lldb-commits < > lldb-comm...@lists.llvm.org> wrote: > >> Moving this back over to the list since I'm sure others have some input >> here. Also +lldb-dev since it has more visibility than lldb-commits. >> >> >> On Tue, Nov 17, 2015 at 11:25 AM Zachary Turner >> wrote: >> >>> On Tue, Nov 17, 2015 at 8:18 AM Todd Fiala wrote: >>> Breaking out the binding generation into a separate step will also be important for a couple reasons: * (from before) I want to eliminate the requirement for the vast majority of the builds to have a swig on their system, and * (not stated before) we'd like to move away from swig for binding generation at some point. >>> > Is there any discussion or thoughts about what the options would be for > moving away from swig? > > - Bruce > > -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.
> that comes out of python that comes out of swig, rather (i.e. the binding generation output). On Tue, Nov 17, 2015 at 8:03 PM, Todd Fiala wrote: > Nothing concrete at the moment; however, it could be interesting to look > at the clang community and see what could be done for llvm-based language > implementations. The angle that I think would be interesting would be if > we can generate bindings more effectively based on the in-depth > understanding of the language that is afforded by languages built on top of > LLVM. This is probably less interesting for Python (particularly since we > have a functioning solution) and more interesting for languages built on > LLVM or clang. > > Honestly, though, I haven't spent much time on that. > > For the time being, I am going to not change the path for everyone on > swig, and only use a static binding if swig cannot be found. This will be > minimal impact for everyone and doesn't interfere with anyone using a > specific version of swig. We can revisit larger questions about > who/what/when on static bindings after we gain some experience with > enabling them for those who don't have swig. We can review and adjust > based on our collective experience. The two files this seems like it will > be are the LLDBWrapPython.cpp and the lldb.py file that comes out of > python. I hope to have this working in the next day or so. > > > On Tue, Nov 17, 2015 at 7:26 PM, Bruce Mitchener < > bruce.mitche...@gmail.com> wrote: > >> Stepping one step back further in the thread ... >> >> On Wed, Nov 18, 2015 at 8:35 AM, Zachary Turner via lldb-commits < >> lldb-comm...@lists.llvm.org> wrote: >> >>> Moving this back over to the list since I'm sure others have some input >>> here. Also +lldb-dev since it has more visibility than lldb-commits. >>> >>> >>> On Tue, Nov 17, 2015 at 11:25 AM Zachary Turner >>> wrote: >>> On Tue, Nov 17, 2015 at 8:18 AM Todd Fiala wrote: > Breaking out the binding generation into a separate step will also be > important for a couple reasons: > > * (from before) I want to eliminate the requirement for the vast > majority of the builds to have a swig on their system, and > > * (not stated before) we'd like to move away from swig for binding > generation at some point. > >> Is there any discussion or thoughts about what the options would be for >> moving away from swig? >> >> - Bruce >> >> > > > > -- > -Todd > -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
