https://github.com/jimingham closed
https://github.com/llvm/llvm-project/pull/81314
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg approved this pull request.
Ok, LGTM.
https://github.com/llvm/llvm-project/pull/81314
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/81314
>From 1d24f118373af64a212893366051b7da1b02d791 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Fri, 9 Feb 2024 12:09:27 -0800
Subject: [PATCH 1/3] It makes no sense to make a ValueObjectPrinter with a
null
jimingham wrote:
The other thing I'm trying to eliminate is problem arising from the way the old
code started with `m_valobj` primed to `nullptr` and then getting set by
calling GetMostSpecializedValue, but then not always accessing it through that
API, but often accessing `m_valobj`
jimingham wrote:
I don't think this is a lifetime issue. If it were I would see more of the
crashes at random addresses.
Whatever's going on is something odd, so I'm just trying to make the code
easier to reason about. I think in the ValueObjectPrinter's case, it's code
will be cleaner if
clayborg wrote:
None of what I suggested was mandatory. I was mainly trying to make sure things
don't go away on us without us knowing about it. If we have crashes it is
always hard to tell if simple heap corruption is the issue or if we are having
lifetime issues. If you are not concerned
jimingham wrote:
Note, these really are transitory objects and need to be quick to make and
delete because in the course of printing a complex object we make a
ValueObjectPrinter for each node we print. So we're making a lot of them as we
descend and then directly throwing them away when
@@ -18,39 +18,35 @@
using namespace lldb;
using namespace lldb_private;
-ValueObjectPrinter::ValueObjectPrinter(ValueObject *valobj, Stream *s) {
- if (valobj) {
-DumpValueObjectOptions options(*valobj);
-Init(valobj, s, options, m_options.m_max_ptr_depth, 0,
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff ff8c865838b46d0202963b816fbed50aaf96a7f4
dc2c387e357c7cdd6837614f20095d2f4540f9d8 --
@@ -177,7 +177,10 @@ class CommandObjectFrameDiagnose : public
CommandObjectParsed {
DumpValueObjectOptions options;
options.SetDeclPrintingHelper(helper);
-ValueObjectPrinter printer(valobj_sp.get(), (),
+// We've already handled the case where the value
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/81314
>From 1d24f118373af64a212893366051b7da1b02d791 Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Fri, 9 Feb 2024 12:09:27 -0800
Subject: [PATCH 1/2] It makes no sense to make a ValueObjectPrinter with a
null
https://github.com/jimingham edited
https://github.com/llvm/llvm-project/pull/81314
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jimingham edited
https://github.com/llvm/llvm-project/pull/81314
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -177,7 +177,10 @@ class CommandObjectFrameDiagnose : public
CommandObjectParsed {
DumpValueObjectOptions options;
options.SetDeclPrintingHelper(helper);
-ValueObjectPrinter printer(valobj_sp.get(), (),
+// We've already handled the case where the value
jimingham wrote:
Replying to a bunch of Greg's comments in sum.
The way we use the ValueObjectPrinter is that you have a ValueObject and want
to print it, so you make a ValueObjectPrinter passing in that ValueObject, then
tell it to print it. We don't preserve ValueObjectPrinters or try to
@@ -121,8 +135,10 @@ class ValueObjectPrinter {
private:
bool ShouldShowName() const;
- ValueObject *m_orig_valobj;
- ValueObject *m_valobj;
+ ValueObject _orig_valobj;
+ ValueObject *m_cached_valobj; /// Cache the current "most specialized" value.
@@ -177,7 +177,10 @@ class CommandObjectFrameDiagnose : public
CommandObjectParsed {
DumpValueObjectOptions options;
options.SetDeclPrintingHelper(helper);
-ValueObjectPrinter printer(valobj_sp.get(), (),
+// We've already handled the case where the value
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/81314
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -18,39 +18,35 @@
using namespace lldb;
using namespace lldb_private;
-ValueObjectPrinter::ValueObjectPrinter(ValueObject *valobj, Stream *s) {
- if (valobj) {
-DumpValueObjectOptions options(*valobj);
-Init(valobj, s, options, m_options.m_max_ptr_depth, 0,
https://github.com/clayborg commented:
See inlined comments, but maybe we need to start storing a
`std::weak_ptr` instead of raw pointers to things, and possibly
always passsing a `ValueObjectSP` object into the `ValueObjectPrinter` so it
holds a strong reference to the value object while
@@ -177,7 +177,10 @@ class CommandObjectFrameDiagnose : public
CommandObjectParsed {
DumpValueObjectOptions options;
options.SetDeclPrintingHelper(helper);
-ValueObjectPrinter printer(valobj_sp.get(), (),
+// We've already handled the case where the value
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (jimingham)
Changes
I get a small but fairly steady stream of crash reports which I can only
explain by ValueObjectPrinter trying to access its m_valobj field, and finding
it NULL. I have never been able to reproduce any of these,
https://github.com/jimingham created
https://github.com/llvm/llvm-project/pull/81314
I get a small but fairly steady stream of crash reports which I can only
explain by ValueObjectPrinter trying to access its m_valobj field, and finding
it NULL. I have never been able to reproduce any of
23 matches
Mail list logo
