[lldb-dev] PATCH for REVIEW - Fix [Bug 15038] LLDB does not support printing wide-character variables on Linux

[Thirumurthi, Ashok]

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:egranata at apple.com]
Sent: Wednesday, March 27, 2013 6:18 PM
To: Thirumurthi, Ashok
Cc: lldb-dev at cs.uiuc.edu
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<mailto:egranata@.com>
✆ 27683

On Mar 27, 2013, at 2:52 PM, "Thirumurthi, Ashok" <ashok.thirumurthi at intel.com<mailto:ashok.thirumurthi at intel.com>> 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: lldb-dev-bounces at cs.uiuc.edu<mailto:lldb-dev-bounces at cs.uiuc.edu> [mailto:lldb-dev-bounces at cs.uiuc.edu] On Behalf Ofbugzilla-daemon at llvm.org<mailto:bugzilla-daemon at llvm.org>
Sent: Tuesday, January 22, 2013 10:13 AM
To: lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>
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: lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>
       ReportedBy: daniel.malea at intel.com<mailto:daniel.malea at intel.com>
   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
lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
<read-strings.diff>_______________________________________________
lldb-dev mailing list
lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130328/b9ca6ac8/attachment.html>