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
