Hi,
now I pretty much see where you are coming from.
What we have here is a Linux-specific implementation issue (which of course is
not going to get fixed anytime soon :-)
What troubles me a little with the overall idea of this patch is that we are
putting a workaround for a lower-level issue in higher-level code.
If we go this route, the same thing might have to be done for
ValueObject::ReadPointedString() which does the same kind of “unbounded read”
I would prefer, if we do this, that at least we put the code around #if defined
(__linux__), as in:
if (error.Fail() || data_read == 0)
{
+ bool found = false;
#if defined (__linux__)
+ if (data_read && error.GetType() == eErrorTypePOSIX) {
+ // Determine if a null terminator was found in spite of an
out-of-bounds read
+ if (error.GetError() == EIO || error.GetError() == EFAULT) {
+ char* buffer = reinterpret_cast<char *>(buffer_sp->GetBytes());
+ char terminator[4] = {'\0', '\0', '\0', '\0'};
+ assert(sizeof(terminator) >= type_size && "Atempting to read a
wchar with more than 4 bytes per character!");
+
+ for (size_t i = 0; !found && (i + type_size <= data_read); i
+= type_size)
+ if (::strncmp(&buffer[i], terminator, type_size) == 0)
+ found = true; // null terminator
+ }
+ }
#endif
+ if (!found) {
+ stream.Printf("unable to read data");
+ return true;
}
}
This will maintain a clean behavior for non-Linux systems (and other systems
with a similarly broken API can opt-in this behavior by adding themselves to
the ifdef)
But I am inclined to believe the best option would be to adopt your
ProcessMonitor fix that reads smaller and smaller chunks and then returns the
number of bytes read and no error - that would make all unbounded-read-based
calls just work without having to add Linux-specific patches around (main issue
being that now we all have to remember that anything that reads a string-like
thing has to add a similar workaround or cause Linux unhappiness)
If that is not going to be viable, or will take some time, I don’t want to keep
you blocked, so I would suggest:
- commit this patch with #ifdef markers to keep it Linux-only
- file a bugzilla issue to make process reads as functional as possible on Linux
Thoughts?
Enrico Granata
✉ egranata@.com
✆ 27683
On Mar 28, 2013, at 8:39 AM, "Thirumurthi, Ashok" <[email protected]>
wrote:
> Thanks for the feedback, Enrico,
>
> I’m relying on the fact that when the wstring is larger than the default size
> (1GB in your example), we won’t get a ptrace error like EIO or EFAULT. So,
> there will be no search for a null terminator.
>
> If we can’t rely on the null terminator, it’s hard to know if a different
> error occurred. The trouble is that there is inconsistency in the
> PTRACE_PEEK implementation on Linux that is more or less arbitrary (sigh), so
> the out-of-bounds read can generate EIO or EFAULT. In particular, EIO can
> mean a number of things:
> “request is invalid, or an attempt was made to read from or write to an
> invalid area in the parent's or child's memory, or there was a word-alignment
> violation, or an invalid signal was specified during a restart request.”
> –http://linux.die.net/man/2/ptrace
>
> In addition, the Linux ProcessMonitor reads in 8-byte chunks, so
> ReadUTFBufferAndDumpToStream will probably fail (for the right reasons) in
> the case where at least part of the null terminator was in that block. I see
> that as an implementation detail that can be resolved in ProcessMonitor by
> reading smaller chunks until PTRACE_PEEK succeeds (i.e. a good follow-up
> patch).
>
> Do let me know if you feel this is okay to commit as is. Cheers,
>
> - Ashok
>
> From: Enrico Granata [mailto:[email protected]]
> Sent: Wednesday, March 27, 2013 6:18 PM
> To: Thirumurthi, Ashok
> Cc: [email protected]
> Subject: Re: [lldb-dev] PATCH for REVIEW - Fix [Bug 15038] LLDB does not
> support printing wide-character variables on Linux
>
> Hi Ashok,
> thanks for submitting an LLDB patch :)
>
> I have looked at the code and while I see where the patch is coming from, I
> see a potential issue with it.
>
> The code in ReadUTFBufferAndDumpToStream, which is what you are editing, is
> meant to work on a partial string (i.e. one that does not have a NULL
> terminator at the end). The reason for that is that you might have a wstring
> that is 1GB long and we would not want to try and read all of it and then
> display it. What we do is pick a size and only extract that much data. For
> obvious reasons, your string might be longer than our upper boundary, so you
> would get a chunk of valid bytes and then no end-of-buffer marker.
>
> It looks like your code would fail in that case and produce no summary for a
> string if an EIO was received before \0.
>
> Is there any reason why you can’t just check if (error == EIO and data_read >
> 0) and if so treat this as a “partial string” condition and keep going?
> Would that break/crash anything?
>
> Best,
> Enrico Granata
> ✉ egranata@.com
> ✆ 27683
>
> On Mar 27, 2013, at 2:52 PM, "Thirumurthi, Ashok"
> <[email protected]> wrote:
>
>
> The root cause for Bug 15038 is a ptrace EIO that can occur because we don't
> know the size of a (UTF) string and so read a fixed number of characters for
> strings. The attached fix accepts EIO in the case where data has been read
> and a null terminator of the correct size and alignment was found.
>
> - Ashok
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf [email protected]
> Sent: Tuesday, January 22, 2013 10:13 AM
> To: [email protected]
> Subject: [lldb-dev] [Bug 15038] New: LLDB does not support printing
> wide-character variables on Linux
>
> http://llvm.org/bugs/show_bug.cgi?id=15038
>
> Bug #: 15038
> Summary: LLDB does not support printing wide-character
> variables on Linux
> Product: lldb
> Version: unspecified
> Platform: PC
> OS/Version: Linux
> Status: NEW
> Severity: enhancement
> Priority: P
> Component: All Bugs
> AssignedTo: [email protected]
> ReportedBy: [email protected]
> Classification: Unclassified
>
>
> Printing a variable of wchar_t type does not behave as expected and results
> in garbage being printed on the screen.
>
> To reproduce, remove the @expectedFailureLinux decorator from
> TestChar1632T.py and TestCxxWCharT.py and run:
>
> python dotest.py --executable <path-to-lldb> lang/cpp/char1632_t
> lang/cpp/wchar_t
>
> --
> Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
> ------- You are receiving this mail because: ------- You are the assignee for
> the bug.
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> <read-strings.diff>_______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
