In case there was any doubt, yes, your interpretations are correct, except for virtual base classes :) (speaking as a member of the C++ ANSI committee and co-editor of the standard).
On Wed, Nov 26, 2014 at 02:09:31AM +0000, Zachary Turner wrote: > FWIW I agree with Abid's interpretation of the standard. > > A comment on the inheritance list would be nice here though, indicating > that the order of declaration is important. > On Tue Nov 25 2014 at 4:50:09 PM Jason Molenda <[email protected]> wrote: > > > I think you should commit this patch. I don't know this corner of the > > standard very well but if TOT is crashing for all Linux users, it'd be > > better to tentatively accept the change until Kate is back on-line next > > week. > > > > J > > > > > On Nov 25, 2014, at 5:58 AM, Abid, Hafiz <[email protected]> wrote: > > > > > > Hi Kate, > > > I observed that this change is causing crash on Linux whenever a > > confirmation is shown to the user (e.g. breakpoint delete or quit). I think > > the following code is responsible. It is casting this pointer in > > initializer list to a base class which is still not initialized. > > > > > > IOHandlerConfirm::IOHandlerConfirm (Debugger &debugger, > > > const char *prompt, > > > bool default_response) : > > > IOHandlerEditline(debugger, > > > IOHandler::Type::Confirm, > > > NULL, // NULL editline_name means no history > > loaded/saved > > > NULL, // No prompt > > > NULL, // No continuation prompt > > > false, // Multi-line > > > false, // Don't colorize the prompt (i.e. the > > confirm message.) > > > 0, > > > *this), > > > m_default_response (default_response), > > > m_user_response (default_response) > > > > > > If my reading of C++ standard is correct, the constructor of base > > classes are called in order in which they are declared (12.6.2 (10)). So > > *this is basically casting IOHandlerConfirm to its base IOHandlerDelegate > > and passing it to constructor of IOHandlerEditline which uses it and > > crashes as constructor of IOHandlerDelegate is still not called. > > > > > > I changed the order of base classes in the declaration of > > IOHandlerConfirm and it seems to have fixed this issue. Please have a look > > at the attached patch and let me know if it looks ok to you. > > > > > > Thanks, > > > Abid > > > > > > > > >> -----Original Message----- > > >> From: [email protected] [mailto:lldb-commits- > > >> [email protected]] On Behalf Of Shawn Best > > >> Sent: 18 November 2014 19:03 > > >> To: Ed Maste; Kate Stone > > >> Cc: [email protected] > > >> Subject: Re: [Lldb-commits] [lldb] r222163 - Complete rewrite of > > interactive > > >> editing support for single- and multi-line input. > > >> > > >> I can confirm the two issues you cite also started failing on linux > > around the > > >> time of this changes. Greg's checkin yesterday fixed TestCommandRegex, > > but > > >> TestGlobalVariables is still failing. > > >> > > >> On 11/17/2014 11:46 AM, Ed Maste wrote: > > >>> On 17 November 2014 14:07, Kate Stone <[email protected]> > > >> wrote: > > >>>> Author: kate > > >>>> Date: Mon Nov 17 13:06:59 2014 > > >>>> New Revision: 222163 > > >>>> > > >>>> URL: http://llvm.org/viewvc/llvm-project?rev=222163&view=rev > > >>>> Log: > > >>>> Complete rewrite of interactive editing support for single- and > > multi-line > > >> input. > > >>> FYI, two new test failures appeared on FreeBSD after this change. I'm > > >>> curious if the Linux guys see similar behaviour. > > >>> > > >>> > > >>> FAIL: LLDB (/usr/bin/clang-x86_64) :: test_with_dwarf > > >>> (TestGlobalVariables.GlobalVariablesTestCase) > > >>> > > >> ================================================================ > > >> ====== > > >>> FAIL: test_with_dwarf (TestGlobalVariables.GlobalVariablesTestCase) > > >>> Test 'frame variable --scope --no-args' which omits args and shows > > >> scopes. > > >>> ---------------------------------------------------------------------- > > >>> Traceback (most recent call last): > > >>> File "/tank/emaste/src/llvm/tools/lldb/test/lldbtest.py", line 382, > > in > > >> wrapper > > >>> return func(self, *args, **kwargs) > > >>> File > > >>> "/tank/emaste/src/llvm/tools/lldb/test/lang/c/global_variables/TestGlo > > >>> balVariables.py", > > >>> line 24, in test_with_dwarf > > >>> self.global_variables() > > >>> File > > >>> "/tank/emaste/src/llvm/tools/lldb/test/lang/c/global_variables/TestGlo > > >>> balVariables.py", > > >>> line 60, in global_variables > > >>> 'stop reason = breakpoint']) > > >>> File "/tank/emaste/src/llvm/tools/lldb/test/lldbtest.py", line > > 1886, in > > >> expect > > >>> self.runCmd(str, msg=msg, trace = (True if trace else False), > > >>> check = not error, inHistory=inHistory) > > >>> File "/tank/emaste/src/llvm/tools/lldb/test/lldbtest.py", line > > 1812, in > > >> runCmd > > >>> msg if msg else CMD_MSG(cmd)) > > >>> AssertionError: False is not True : Process should be stopped due to > > >>> breakpoint Config=x86_64-/usr/bin/clang > > >>> ---------------------------------------------------------------------- > > >>> Ran 2 tests in 0.200s > > >>> > > >>> FAILED (failures=1, skipped=1) > > >>> > > >>> > > >>> FAIL: LLDB (/usr/bin/clang-x86_64) :: test_command_regex > > >>> (TestCommandRegex.CommandRegexTestCase) > > >>> > > >> ================================================================ > > >> ====== > > >>> ERROR: test_command_regex > > >> (TestCommandRegex.CommandRegexTestCase) > > >>> Test a simple scenario of 'command regex' invocation and subsequent > > >> use. > > >>> ---------------------------------------------------------------------- > > >>> Traceback (most recent call last): > > >>> File > > >>> "/tank/emaste/src/llvm/tools/lldb/test/functionalities/command_regex/T > > >>> estCommandRegex.py", > > >>> line 38, in test_command_regex > > >>> child.expect('The following is a list of built-in, permanent > > >>> debugger commands:') > > >>> File > > >>> "/tank/emaste/src/llvm/tools/lldb/test/pexpect-2.4/pexpect.py", > > >>> line 1316, in expect > > >>> return self.expect_list(compiled_pattern_list, timeout, > > >> searchwindowsize) > > >>> File > > >>> "/tank/emaste/src/llvm/tools/lldb/test/pexpect-2.4/pexpect.py", > > >>> line 1330, in expect_list > > >>> return self.expect_loop(searcher_re(pattern_list), timeout, > > >>> searchwindowsize) > > >>> File > > >>> "/tank/emaste/src/llvm/tools/lldb/test/pexpect-2.4/pexpect.py", > > >>> line 1414, in expect_loop > > >>> raise TIMEOUT (str(e) + '\n' + str(self)) > > >>> TIMEOUT: Timeout exceeded in read_nonblocking(). > > >>> _______________________________________________ > > >>> lldb-commits mailing list > > >>> [email protected] > > >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits > > >> > > >> _______________________________________________ > > >> lldb-commits mailing list > > >> [email protected] > > >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits > > > <IOHandler.patch>_______________________________________________ > > > lldb-commits mailing list > > > [email protected] > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits > > > > > > _______________________________________________ > > lldb-commits mailing list > > [email protected] > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits > > > _______________________________________________ > lldb-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
