Bug 32492 - monodis: User Strings table dump shows spurious empty strings
Summary: monodis: User Strings table dump shows spurious empty strings
Status: NEW
Alias: None
Product: Runtime
Classification: Mono
Component: Tools (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2015-07-27 14:42 UTC by Pedro Gimeno
Modified: 2016-04-16 10:14 UTC (History)
5 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments

Description Pedro Gimeno 2015-07-27 14:42:41 UTC
Apologies if I didn't select the right product/component. I don't really know what category the disassembler fits in.

When using monodis --userstrings, some wrong empty strings are dumped.

Test case: monodis_empty_strings_bug.cil

(Begin test case)

.class 'x'
{
  .method void 'y'()
  {
     ldstr "This is a string longer than 64 chars (128 bytes). After it you will see a spurious empty string."
     ldstr "Here comes an actual empty string."
     ldstr ""
  }
}

(End test case)

Assemble with: ilasm /dll monodis_empty_strings_bug.cil

Dump the string table with: monodis --userstrings monodis_empty_strings_bug.dll

Expected output:

User Strings heap contents
01: "This is a string longer than 64 chars (128 bytes). After it you will see a spurious empty string."
c6: "Here comes an actual empty string."
10c: ""

Actual output:

User Strings heap contents
00: ""
01: "This is a string longer than 64 chars (128 bytes). After it you will see a spurious empty string."
c5: ""
c6: "Here comes an actual empty string."
10c: ""
10e: ""
10f: ""

I am not sure about whether the first entry at offset 0 is normal. The cause for the last two entries may be an incorrect value for m->heap_us.size (perhaps due to alignment padding). The cause for the one at c5 is line 1261 here:

https://github.com/mono/mono/blob/2e3ba21e80f3edd03c7c2050c9ba921298b4c176/mono/dis/dump.c#L1246

namely

	i += len + 1;

That assumes that the encoded length always takes one byte, which is not correct for lengths > 127 bytes. To fix that, the difference of pointers before and after the mono_metadata_decode_blob_size() call is what should be added to len in that line. That is, something along these lines:

	const char *us_ptr = mono_metadata_user_string (m, i);
        const char *len_ptr = us_ptr; // <--- added
        int len = mono_metadata_decode_blob_size (us_ptr, (const char**)&us_ptr);
        ...
	i += len + (us_ptr - len_ptr); // <--- changed

Note I have not tested the above fix.

Note You need to log in before you can comment on or make changes to this bug.