I wrote a simple C# app:
static void Main(string[] args)
{
var list = new List<int> {500,400,300,200,100};
var listEnumerator = list.GetEnumerator();
listEnumerator.MoveNext();
} // <--- breakpoint here
I put a breakpoint at the end, ran it with Visual Studio, then fired up windbg and attached to the process (with the "non-invasive" checkbox turned on).
I then entered these commands:
.load C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86\sosex.dll
!mframe 17
!mdt listEnumerator
The output I got was clearly wrong (the fields are all messed up, it seems to report the value of 'index' under 'current', the value of 'current' under 'version', and the value of version' under 'index'. It got only one field right - the first one.
Local #0: (System.Collections.Generic.List`1+Enumerator) VALTYPE (MT=72dfd838, ADDR=0029efb8)
list:02632464 (System.Collections.Generic.List`1[[System.Int32, mscorlib]])
index:0x5 (System.Int32)
version:0x1f4 (System.Int32)
current:00000001 (T)
I then tried to use SOS's !DumpVC instead, and got the same confusion:
0:000> !DumpVC 72dfd838 0029efb8
Name: System.Collections.Generic.List`1+Enumerator
MethodTable: 72dfd838
EEClass: 72a32d38
Size: 24(0x18) bytes
File: C:\Windows\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Fields:
MT Field Offset Type VT Attr Value Name
736ae16c 4000c99 0 ...Generic.List`1[T] 0 instance 02632464 list
72e03aa4 4000c9a 8 System.Int32 1 instance 5 index
72e03aa4 4000c9b c System.Int32 1 instance 500 version
00000000 4000c9c 4 VAR 0 instance 00000001 current
Why does this happen?
The problem is that the CLR has re-ordered the fields of the enumerator struct for the closed type (enumerator of int) so that they don't match the open type (enumerator of T). Sosex was using the open type to read the fields instead of the closed type. This bug in sosex has now been fixed.
Related
I need to get the address of the function required by .fnret command in WinDBG.
For example, I want to get the information about return value of apphelp!ApphelpCheckRunApp function.
First, I set a breakpoint on this function:
bp apphelp!ApphelpCheckRunApp
Then I'm continuing the execution, until it breaks on that function.
After breaking, I'm executing .fnret [Address] command.
I already tried to use the 77b345d5 address displayed on the breakpoint:
Breakpoint 0 hit
eax=77b345d5 ebx=7ed320f5 ecx=7ffac000 edx=7c886920 esi=7ffac000 edi=00000018
eip=77b345d5 esp=0378ce90 ebp=0378d108 iopl=0 nv up ei pl nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000213
appHelp!ApphelpCheckRunApp:
77b345d5 8bff mov edi,edi
but that seems to be not what I need, because I get the following error:
^ Unknown or unsupported return type in '.fnret 77b345d5'
Also I used return address 7c818cdf of this function from call stack (got via kb command):
ChildEBP RetAddr Args to Child
0283ce8c 7c818cdf 00000474 046bb7d0 00000000 appHelp!ApphelpCheckRunApp
but it leads me to the same error.
Which WinDBG command I should use for that and which return address it will display (in case it isn't displayed yet on breakpoint)? Will it then properly work for .fnret or .fnret /s commands? Unfortunately, there are no any examples of using them on MSDN, only the documentation.
Hoping on your help. Thanks in advance.
.fnret is only useful if you have private pdb
it is not useful if you have public pdb because it needs to retrieve the type information
here is a sample usage on a compiled code with private pdb
0:000> x /t /v /f myst!towlower
prv func 00007ff6`74ba5f84 7 <function> myst!towlower (unsigned short)
0:000> x /t /v /f myst!toupper
prv func 00007ff6`74b91b10 2a <function> myst!toupper (int)
0:000> .fnret myst!towlower
myst!towlower (00007ff6`74ba5f84) = unsigned short 1
0:000> .fnret myst!toupper
myst!toupper (00007ff6`74b91b10) = int 0n1
error on a known function which returns a HANDLE using public stripped pdb
0:000> .fnret KERNELBASE!CreateFileA
^ Unknown or unsupported return type in '.fnret KERNELBASE!CreateFileA'
success on a system file with private pdb
it casts the forced return value dumped in #rax as a typed return with value of a function with type information
a system file with prrivate pdb
0:000> .printf "%y\n" , 0x00000001`800bace0 ; an arbitrary function
ole32!ToUnicode (00000001`800bace0)
0:000> .printf "%mu\n" , 00000001`8014c17a ; an arbitrary wide string
guageErrorPointerംА
0:000> r rax = 00000001`8014c17a the $retreg is populated with an address of wide string
0:000> .fnret 0x00000001`800bace0 << fnret casts the $retreg as wide string and prints the resulting widestring
ole32!ToUnicode (00000001`800bace0) = wchar_t * 0x00000001`8014c17a
"guageErrorPointer???"
OK, that command is indeed not helpful at all when using public PDBs.
I found better solution here: How to get return value from a function in windbg?.
It is possible to get the memory address of return value by viewing eax/rax register on x86/x64 appropriately, using r command (since it always is stored there). After breakpoint, I'm just typing r eax on x86 or r rax on x64. Output will be look like this:
eax=[Address]
Then, I'm displaying a value of received memory address via d* (dd, du etc. displaying data types commands), like this:
du [Address]
After looking at the output, it becomes understandable which data is returned, and its data type also (at least in most of cases).
But to understand first, which data type is used, I'm trying the different combinations of display memory commands and display referenced memory commands.
In my ada's project I have 2 different libraries with base types. I found two different definition for a boolean :
Library A :
type Bool_Type is new Boolean;
Library B :
type T_BOOL8 is new Boolean;
for T_BOOL8'Size use 8;
So I have a question, what is the size used for Bool_Type ?
Bool_Type will inherit the 'Size of Boolean, which is required to be 1,
see RM 13.3(49)
Compile with switch -gnatR2 to see its representation clause. For example:
main.adb
with Ada.Text_IO; use Ada.Text_IO;
procedure Main is
type Bool_Type is new Boolean;
type T_BOOL8 is new Boolean;
for T_BOOL8'Size use 8;
begin
Put_Line ("Bool_Type'Object_Size = " & Integer'Image (Bool_Type'Object_Size));
Put_Line ("Bool_Type'Value_Size = " & Integer'Image (Bool_Type'Value_Size));
Put_Line ("Bool_Type'Size = " & Integer'Image (Bool_Type'Size));
New_Line;
Put_Line ("T_BOOL8'Object_Size = " & Integer'Image (T_BOOL8'Object_Size));
Put_Line ("T_BOOL8'Value_Size = " & Integer'Image (T_BOOL8'Value_Size));
Put_Line ("T_BOOL8'Size = " & Integer'Image (T_BOOL8'Size));
New_Line;
end Main;
compiler output (partial):
Representation information for unit Main (body)
-----------------------------------------------
for Bool_Type'Object_Size use 8;
for Bool_Type'Value_Size use 1;
for Bool_Type'Alignment use 1;
for T_Bool8'Size use 8;
for T_Bool8'Alignment use 1;
program output
Bool_Type'Object_Size = 8
Bool_Type'Value_Size = 1
Bool_Type'Size = 1
T_BOOL8'Object_Size = 8
T_BOOL8'Value_Size = 8
T_BOOL8'Size = 8
As can be seen, the number returned by the 'Size / 'Value_Size attribute for Bool_Type is equal to 1 (as required by the RM; see egilhh's answer). The attribute 'Size / 'Value_Size states the number of bits used to represent a value of the type. The 'Object_Size attribute, on the other hand, equals 8 bits (1 byte) and states the amount of bits used to store a value of the given type in memory (see Simon Wright's comment). See here and here for details.
Note that the number of bits indicated by 'Size / 'Value_Size must be sufficient to uniquely represent all possible values within the (discrete) type. For Boolean derived types, at least 1 bit is required, for an enumeration type with 3 values, for example, you need at least 2 bits.
An effect of explicitly setting the 'Size / 'Value_Size attribute can be observed when defining a packed array (as mentioned in G_Zeus’ answer):
type Bool_Array_Type is
array (Natural range 0 .. 7) of Bool_Type with Pack;
type T_BOOL8_ARRAY is
array (Natural range 0 .. 7) of T_BOOL8 with Pack;
compiler output (partial):
Representation information for unit Main (body)
-------------------------------------------------
[...]
for Bool_Array_Type'Size use 8;
for Bool_Array_Type'Alignment use 1;
for Bool_Array_Type'Component_Size use 1;
[...]
for T_Bool8_Array'Size use 64;
for T_Bool8_Array'Alignment use 1;
for T_Bool8_Array'Component_Size use 8;
Because the number of bits used to represent a value of type T_BOOL8 is forced to be 8, the size of a single component of a packed array of T_BOOL8s will also be 8, and the total size of T_BOOL8_ARRAY will be 64 bits (8 bytes). Compare this to the total length of 8 bits (1 byte) for Bool_Array_Type.
You should find your answer (or enough information to find the answer to your specific question) in the Ada wikibooks entry for 'Size attribute.
Most likely Bool_Type has a the same size as Boolean, or 1 bit for the type (meaning you can pack Bool_Type elements in an array, for example) and 8 bits for instances (rounded up to full byte).
Whatever size the compiler wants, unless you override as in library B. Probably 8 bits but on some 32 bit RISC targets, 32 bits may be faster than 8. On a tiny microcontroller, 1 bit may save space.
The other answers let you find out for the specific target you compile for.
As your booleans are separate types, you need type conversions between them, providing hooks for the compiler to handle any format or size conversion without any further ado.
I work on an application to add annotation from a fdf file to a Pdf file
With iText can do in this way
FdfReader aFdfReader = new FdfReader(new FileInputStream(args[0]));
PdfReader aReader = new PdfReader(new FileInputStream(args[1]));
PdfStamper aStamper = new PdfStamper(aReader, new FileOutputStream(args[2]));
aStamper.addComments(aFdfReader);
aStamper.close();
But when i load the fdf I have this exception. The fdf have an annotation with the type attachment file.
Exception in thread "main" com.itextpdf.text.exceptions.InvalidPdfException: Error reading string at file pointer 5106590
at com.itextpdf.text.pdf.PRTokeniser.throwError(PRTokeniser.java:220)
at com.itextpdf.text.pdf.PRTokeniser.nextToken(PRTokeniser.java:411)
at com.itextpdf.text.pdf.PRTokeniser.nextValidToken(PRTokeniser.java:282)
at com.itextpdf.text.pdf.PdfReader.readPRObject(PdfReader.java:1908)
at com.itextpdf.text.pdf.PdfReader.readArray(PdfReader.java:1891)
at com.itextpdf.text.pdf.PdfReader.readPRObject(PdfReader.java:1946)
at com.itextpdf.text.pdf.PdfReader.readDictionary(PdfReader.java:1877)
at com.itextpdf.text.pdf.PdfReader.readPRObject(PdfReader.java:1913)
at com.itextpdf.text.pdf.PdfReader.readDocObj(PdfReader.java:1411)
at com.itextpdf.text.pdf.FdfReader.readPdf(FdfReader.java:105)
at com.itextpdf.text.pdf.PdfReader.(PdfReader.java:181)
at com.itextpdf.text.pdf.PdfReader.(PdfReader.java:395)
at com.itextpdf.text.pdf.PdfReader.(PdfReader.java:415)
at com.itextpdf.text.pdf.FdfReader.(FdfReader.java:92)
at com.artesys.pdf.itext.pdf.AddFdf.main(AddFdf.java:18)
I do the test with itext_so.pdf to attach to the annotation
if i made the test with a helloword i works fine
I used the version 5.5.9
Thank in advance for your response
Regards
Fabien
The FDF is special as it contains a PDF in a stream; this PDF stream is partially uncompressed; thus, PDF syntax, in particular PDF indirect object starts are visible.
And the FdfReader works incorrectly: It assumes these starts of indirect objects in a stream content to be top level FDF object starts and fails when trying to read those objects.
One can quick-fix this by making the FdfReader object reading more forgiving.
The FDF
Your FDF looks like this:
%FDF-1.2
%âãÏÓ
1 0 obj
<</FDF<</Annots[2 0 R]/F(http://localhost:8780/PachaServer/downloadpacha?pathpdf=Rendition.pdf&edit=false&loginname=fhfgh)/ID[<2175D5400E41761374A2EB01E7026C68><5E9C3BFFF121CE737ED66FF7318CA58D>]/UF(http://localhost:8780/PachaServer/downloadpacha?pathpdf=Rendition.pdf&edit=false&loginname=fhfgh)>>/Type/Catalog/Version/1.6>>
endobj
2 0 obj
<</C[0.25 0.333328 1.0]/Contents(itext_so.pdf)/CreationDate(D:20160519150439+02'00')/F 28/FS 3 0 R/M(D:20160519150439+02'00')/NM(79bcf116-d9bd-4ade-a8cd-7575351271fd)/Name/Paperclip/Page 0/RC(<?xml version="1.0"?><body xmlns="http://www.w3.org/1999/xhtml" xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/" xfa:APIVersion="Acrobat:15.16.0" xfa:spec="2.0.2" ><p>itext_so.pdf</p></body>)/Rect[183.106 684.663 190.106 701.663]/Subj(Pièce jointe)/Subtype/FileAttachment/T(Fabien.Levalois)/Type/Annot>>
endobj
3 0 obj
<</EF<</F 4 0 R>>/F(itext_so.pdf)/Type/Filespec/UF(itext_so.pdf)>>
endobj
4 0 obj
<</DL 10536008/Filter/FlateDecode/Length 10207532/Params<</CheckSum("}þ¶îô/Óý‡†d’ÒÎ)/CreationDate(D:20160511112202+02'00')/ModDate(D:20160511112205+02'00')/Size 10536008>>/Subtype/application#2Fpdf>>stream
... [10207532 data bytes] ...
endstream
endobj
trailer
<</Root 1 0 R>>
%%EOF
This structure is correct. But the contents of the big stream, the 10207532 data bytes in object 4 are special: They constitute a PDF document, and as this document already is compressed, it partially could not be compressed any further when embedded into the FDF and the original PDF syntax becomes piecewise visible, e.g. some 660000 bytes into the stream there suddenly are byte sequences which represent an end of the current PDF stream and the start of another indirect PDF object:
endstream
endobj
10283 0 obj
<</Extends 10282 0 R/Filter/FlateDecode/First 1139/Length 4195/N 100/Type/ObjStm>>stream
...
endstream
endobj
10284 0 obj
<</Extends 10282 0 R/Filter/FlateDecode/First 1139/Length 4018/N 100/Type/ObjStm>>stream
...
endstream
endobj
10285 0 obj
<</Extends 10282 0 R/Filter/FlateDecode/First 190/Length 1001/N 18/Type/ObjStm>>stream
etc. etc. etc.
As these PDF objects only are piecewise visible, though, trying to read them as is can result in an error.
The FdfReader
As an FDF does not need to contain a cross reference section, the FdfReader as a first step tries to create one by searching the file for byte sequences which appear to be the start of indirect objects and deriving a cross reference section from that.
This is incorrect, though, because in cases like your FDF it creates many false cross reference entries, and while reading these false indirect objects, errors occur unless the false objects are syntactically correct.
In case of your PDF many false objects are syntactically correct until a location near the offset 5106590 mentioned in the exception where a false indirect object is partially re-compressed. And when trying to reading that, FdfReader throws the exception you observed.
But the problem are not only such syntax errors (these could be caught and ignored after all) but that false objects and true objects may have the same object number. Thus, FdfReader might use a false object instead of a true one!
A quick fix
While the cross reference reconstruction code for the FdfReader fundamentally has to be re-implemented for a true fix, there is a quick fix for it allowing it to properly process FDFs in which the "false FDF objects" do not collide with true ones, simply derive a class from FdfReader and override the method readPRObject() like this:
#Override
protected PdfObject readPRObject() throws IOException
{
try
{
return super.readPRObject();
}
catch (InvalidPdfException e)
{
return PdfNull.PDFNULL;
}
}
(ImprovedFdfReader.java)
While reading the provided FDF itext-SO.fdf using the ReadFdf.java test method testReadFdfFabienLevalois with a normal FdfReader fails, doing so using the test method testReadFdfFabienLevaloisImproved with an ImprovedFdfReader succeeds.
i am facing a very strange problem in KDB+. where data type returned from kdb+ server is -79. that i can't find out.
does any body know that type is it. ?
79h is type for mapped list of lists of GUID data type.
Reference: http://code.kx.com/q/ref/datatypes/
Section: Nested Type.
From page:
Nested Type:
These types are used for mapped lists of lists of the same type. The numbering is 77 + primitive type.
Guid type is 2 which gives it's nested type value=79
ex:
q)`:t1.dat set 2 2#0x0 sv 16?0xff
q) a:get `:t1.dat
q) type a
q) 79h
I am writing a program that uses character arrays / c strings. Whenever I run the program, valgrind throws a 'definitely lost' block warning:
==8011== [X] bytes in [Y] blocks are definitely lost in loss record 1 of [Z]
==8011== at 0x4A065BA: operator new[](unsigned long) (vg_replace_malloc.c:264)
==8011== by 0x403D45: File::File(stat*, char const*) (File.cpp:15)
...
This is the source code for the constructor and destructor (the header contains definitions for id, isDir, lastModified, and name (name is of type const char*)):
10 File::File(struct stat *statdat, const char* strName)
11 {
12 id = statdat->st_ino;
13 isDir = S_ISDIR(statdat->st_mode);
14 lastModified = (statdat->st_mtime);
15 char* tempName = new char[strlen(strName)+1];
16 strcpy(tempName, strName);
17 name = tempName;
18 tempName = NULL;
19 }
20
21 File::~File()
22 {
23 //delete [] name;
24 }
I have a couple questions with this.
a) Attempting to leave in delete in the destructor when compiling and running results in an instant crash due to an invalid pointer. Why can't I call delete on the character array?
b) I think I'm allocating the right amount of memory for the array. What is causing the memory leak when allocating new space? The error happens after the program stops (after valgrind's HEAP SUMMERY).
I have determined the issue.
My problem was with the /default/ constructor. Since it did not initialize 'name', the delete keyword was trying to delete a null pointer when the destructor was called on an object created by the default constructor. I modified my default constructor for File in order to initialize name to '\0', which appears to have solved the problem.