Archive for March, 2012

Typology, Typological (Debugging Slang, Part 30)

Friday, March 30th, 2012

Typology - a logic of typos in software. Typological - a logical typo.

Examples: A typology of defects in source code. An engineer committed a grave typological mistake.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Semiotics: The Basics

Thursday, March 29th, 2012

In 2008 when writing the first version of this review I admitted that Semiotics was a big gap in my education which mostly lied in natural and computer sciences. I knew less about social sciences and tried to fill various gaps. The reason why I came upon this discipline is that I’m interested in signs and their interpretations, especially their relation to various structures. I started reading this book in September, 2008.

Semiotics: The Basics

Buy from Amazon

As a by-product of reading I was able to provide the kind of a theoretical explanation for the phenomenon of bugtations:

Bugtations: a semiotic approach

Now after more than 3 years of intermittent reading I finally finished this book. In the mean time I was able to apply Semiotics to memory dump and software trace analysis (Memiotics) and now I also use it in connection with Software Narratology (an application of literary narratology to software narratives such as traces and event logs). What is also good about this book in addition to clearly explained concepts is a very good closing chapter summarising the whole book and the field, extensive reading guide, summary of leading schools, and a very good glossary. There is also an online book with extra materials:

http://users.aber.ac.uk/dgc/Documents/S4B/

- Dmitry Vostokov @ LiterateScientist.com -

Bugtation No.158

Wednesday, March 28th, 2012

Always imitate the behavior of the working program when it is crashing.

George Meredith

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Crash Dump Analysis Patterns (Part 25, Mac OS X)

Sunday, March 25th, 2012

This is a Mac OS X / GDB counterpart to Stack Trace pattern previously described for Windows platforms. Here we show a stack trace when symbols are not available and also how to apply symbols:

(gdb) bt
#0  0×000000010d3b0e90 in ?? ()
#1  0×000000010d3b0ea9 in ?? ()
#2  0×000000010d3b0ec4 in ?? ()
#3  0×000000010d3b0e74 in ?? ()

(gdb) maintenance info sections
Exec file:
[...]
Core file:
`/cores/core.262', file type mach-o-le.
0×000000010d3b0000->0×000000010d3b1000 at 0×00001000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
0×000000010d3b1000->0×000000010d3b2000 at 0×00002000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
0×000000010d3b2000->0×000000010d3b3000 at 0×00003000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
0×000000010d3b3000->0×000000010d3b4000 at 0×00004000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
0×000000010d3b4000->0×000000010d3b5000 at 0×00005000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
0×000000010d3b5000->0×000000010d3b6000 at 0×00006000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
0×000000010d3b6000->0×000000010d3cb000 at 0×00007000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
0×000000010d3cb000->0×000000010d3cc000 at 0×0001c000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
0×000000010d3cc000->0×000000010d3cd000 at 0×0001d000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
0×000000010d3cd000->0×000000010d3e2000 at 0×0001e000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
0×000000010d3e2000->0×000000010d3e3000 at 0×00033000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
0×000000010d3e3000->0×000000010d3e4000 at 0×00034000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
0×000000010d400000->0×000000010d500000 at 0×00035000: LC_SEGMENT. ALLOC LOAD CODE HAS_CONTENTS
[…]

(gdb) add-symbol-file ~/Documents/Work/Test.sym 0×000000010d3b0000
add symbol table from file “/Users/DumpAnalysis/Documents/Work/Test.sym” at
LC_SEGMENT.__TEXT = 0×10d3b0000
(y or n) y
Reading symbols from /Users/DumpAnalysis/Documents/Work/Test.sym…done.

(gdb) bt
#0  0x000000010d3b0e90 in bar () at main.c:15
#1  0x000000010d3b0ea9 in foo () at main.c:20
#2  0x000000010d3b0ec4 in main (argc=1,
argv=0x7fff6cfafbf8) at main.c:25

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Forthcoming Training: Accelerated Mac OS X Core Dump Analysis

GDB Annoyances: Incomplete Stack Trace

Sunday, March 25th, 2012

Users of WinDbg debugger accustomed to full thread stack traces will wonder whether a thread starts from main:

(gdb) where
#0  0x000000010d3b0e90 in bar () at main.c:15
#1  0x000000010d3b0ea9 in foo () at main.c:20
#2  0x000000010d3b0ec4 in main (argc=1,
argv=0x7fff6cfafbf8) at main.c:25

Of course, not and by default a stack trace is shown starting from main function. You can change this behavior by using the following command:

(gdb) set backtrace past-main

Now we see an additional frame:

(gdb) where
#0  0x000000010d3b0e90 in bar () at main.c:15
#1  0x000000010d3b0ea9 in foo () at main.c:20
#2  0x000000010d3b0ec4 in main (argc=1,
argv=0x7fff6cfafbf8) at main.c:25
#3  0×000000010d3b0e74 in start ()

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Forthcoming Training: Accelerated Mac OS X Core Dump Analysis

Crash Dump Analysis Patterns (Part 6b, Mac OS X)

Sunday, March 25th, 2012

This is a Mac OS X / GDB counterpart to NULL Pointer (data) pattern previously described for Windows platforms:

(gdb) bt
#0  0×000000010d3b0e90 in bar () at main.c:15
#1  0×000000010d3b0ea9 in foo () at main.c:20
#2  0×000000010d3b0ec4 in main (argc=1,
argv=0×7fff6cfafbf8) at main.c:25

(gdb) disassemble
Dump of assembler code for function bar:
0x000000010d3b0e80 <bar+0>: push   %rbp
0×000000010d3b0e81 <bar+1>: mov    %rsp,%rbp
0×000000010d3b0e84 <bar+4>: movq   $0×0,-0×8(%rbp)
0×000000010d3b0e8c <bar+12>: mov    -0×8(%rbp),%rax
0×000000010d3b0e90 <bar+16>: movl   $0×1,(%rax)
0×000000010d3b0e96 <bar+22>: pop    %bp
0×000000010d3b0e97 <bar+23>: retq
End of assembler dump.

(gdb) p/x $rax
$1 = 0×0

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Forthcoming Training: Accelerated Mac OS X Core Dump Analysis

RawStackGram

Saturday, March 24th, 2012

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

WinDbg shortcuts: !heap -x -v

Friday, March 23rd, 2012

The following command is useful for searching a process virtual space for any value references:

!heap -x -v <value> ”will search the entire virtual memory space of the current process for pointers to this” value (from WinDbg help).

Example:

0:000> !heap -x -v 6e412d82
Search VM for address range 6e412d82 - 6e412d82 : 778042bc (6e412d82),

0:000> dp 778042bc l1
778042bc  6e412d82

0:000> !heap -x -v c0000005
Search VM for address range c0000005 - c0000005 : 014df8d0 (c0000005), 014dfe8c (c0000005), 0155d908 (c0000005), 0155dd10 (c0000005), 0155ddc8 (c0000005), 0155dfa8 (c0000005), 0155dff0 (c0000005), 0155ea20 (c0000005), 6d000f9c (c0000005), 70d44054 (c0000005), 725c30d4 (c0000005), 7270d20c (c0000005), 7282ef74 (c0000005), 7449a878 (c0000005), 74511958 (c0000005), 74562ec4 (c0000005), 74563280 (c0000005), 74564fc8 (c0000005), 7456562c (c0000005), 74565748 (c0000005), 745664a8 (c0000005), 74566a30 (c0000005), 74566ad8 (c0000005), 747f6730 (c0000005), 747f682c (c0000005), 74861ef0 (c0000005), 7488743c (c0000005), 748aea68 (c0000005), 748b2830 (c0000005), 748c5118 (c0000005), 74935068 (c0000005), 749412a8 (c0000005), 7495caf0 (c0000005), 74a3a780 (c0000005), 74aa462c (c0000005), 74b19b68 (c0000005), 74b61060 (c0000005), 74b8fb44 (c0000005), 74b9d1c8 (c0000005), 74be1ad8 (c0000005), 74be72c8 (c0000005), 74c14b60 (c0000005), 74c83b84 (c0000005), 74c83b88 (c0000005), 74c83b9c (c0000005), 74c83ba0 (c0000005), 74c83ba4 (c0000005), 74c83ba8 (c0000005), 74c83bac (c0000005), 74c83bb0 (c0000005), 74c83bb4 (c0000005), 74c83bb8 (c0000005), 74c83bbc (c0000005), 74c83bc0 (c0000005), 74c83bc8 (c0000005), 74c83bcc (c0000005), 74c83bd0 (c0000005), 74c83bd4 (c0000005), 74c83bd8 (c0000005), 74c83bdc (c0000005), 74c83be0 (c0000005), 74c83be4 (c0000005), 74c83be8 (c0000005), 74c83bec (c0000005), 74c83bf0 (c0000005), 74c83bf4 (c0000005), 74c83bf8 (c0000005), 74c83bfc (c0000005), 74c83c00 (c0000005), 74c83c04 (c0000005), 74c83c08 (c0000005), 74c83c0c (c0000005), 74c83c10 (c0000005), 74c83c14 (c0000005), 74c83c18 (c0000005), 74c83c1c (c0000005), 74c83c20 (c0000005), 74c83c24 (c0000005), 74c83c28 (c0000005), 74c83c2c (c0000005), 74c83c34 (c0000005), 74c83c38 (c0000005), 74c83c3c (c0000005), 74c8c7ac (c0000005), 75019298 (c0000005), 750ff7b0 (c0000005), 751c1adc (c0000005), 751c2514 (c0000005), 7522c530 (c0000005), 752c311c (c0000005), 752d4734 (c0000005), 752d4ae8 (c0000005), 752d534c (c0000005), 752d7038 (c0000005), 752d7e9c (c0000005), 752eda04 (c0000005), 752edab0 (c0000005), 756d6624 (c0000005), 7571adc0 (c0000005), 7571addc (c0000005), 75723780 (c0000005), 757af774 (c0000005), 759c0f10 (c0000005), 76702360 (c0000005), 76703a30 (c0000005), 76d437ac (c0000005), 76d527ec (c0000005), 76dd0fa4 (c0000005), 77581f2c (c0000005), 777a33c0 (c0000005), 777c8b14 (c0000005),

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Trace Analysis Patterns (Part 46)

Thursday, March 22nd, 2012

Narrative theory distinguishes between frame types such as (Fludernik, McHale, Nelles, Wolf):

- introductory framing (missing end frame) [—————————-

- terminal framing (missing opening frame) —————————-]

- [—————————-]

- interpolated framing [—-[  ]—-[     ]——–]

At the level of the software trace or an adjoint thread as a whole the first 3 types correspond to various types of this pattern Partition: Head, Prologue, Core, Epilogue, Tail where certain parts are missing. The first 2 types can also be instances of Truncated Trace pattern. Interpolated framing can be an instance of multiple discontinuities. All 4 types also correspond to foreground component messages and in general we have multiple Trace Frames as depicted:

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Crash Dump Analysis Patterns (Part 169)

Thursday, March 22nd, 2012

This is another “blockage” pattern called Blocked DPC. Here we have blocked per-processor Deferred Procedure Call queues because of threads running on processors with IRQL > DISPATCH_LEVEL. For example, on the processor 11 (0×0b):

11: kd> !dpcs
CPU Type      KDPC       Function
3: Normal  : 0x8accacec 0xf710567a DriverA

5: Normal  : 0x89f449e4 0xf595b83a DriverB

7: Normal  : 0x8a63664c 0xf59e3f04 USBPORT!USBPORT_IsrDpc

11: Normal  : 0x8acb2cec 0xf710567a DriverA
11: Normal  : 0x8b5e955c 0xf73484e6 ACPI!ACPIInterruptServiceRoutineDPC

11: kd> !thread
THREAD 89806428  Cid 0934.0944  Teb: 7ffdb000 Win32Thread: bc17dda0 RUNNING on processor b
Not impersonating
DeviceMap                 e1002258
Owning Process            89972290       Image:         ApplicationA.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      2863772        Ticks: 368905 (0:01:36:04.140)
Context Switch Count      145085                 LargeStack
UserTime                  00:00:00.015
KernelTime                01:36:04.203
Win32 Start Address MSVCR90!_threadstartex (0×7854345e)
Start Address kernel32!BaseThreadStartThunk (0×77e617ec)
Stack Init f3f63000 Current f3f62c4c Base f3f63000 Limit f3f5f000 Call 0
Priority 10 BasePriority 10 PriorityDecrement 0
ChildEBP RetAddr  Args to Child
f777d3b0 f3f62d28 00000010 00000000 00000000 hal!KeAcquireInStackQueuedSpinLockRaiseToSynch+0×36
WARNING: Frame IP not in any known module. Following frames may be wrong.
f777d3b4 00000000 00000000 00000000 00000000 0xf3f62d28

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Meta-Memory Dump Patterns

Thursday, March 22nd, 2012

A page to reference all different kinds of patterns related to memory dumps as a whole and their properties is necessary, so I created this post:

I’ll update it as soon as I add more similar patterns.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Crash Dump Analysis Patterns (Part 168)

Tuesday, March 20th, 2012

This is a binary opposition counterpart to Early Crash Dump pattern called Late Crash Dump. It is usually saved after patterns representing a problem such as an exception thread stack trace are already gone. Most often we see one thread with process termination functions (Special Stack Trace pattern):

0:000> ~*k
ChildEBP RetAddr
0037fcf0 770bd55c ntdll!ZwTerminateProcess+0x12
0037fd0c 750f79f4 ntdll!RtlExitUserProcess+0x85
0037fdf8 750f339a kernel32!ExitProcessStub+0x12
0037fe04 770a9ef2 kernel32!BaseThreadInitThunk+0xe
0037fe44 770a9ec5 ntdll!__RtlUserThreadStart+0x70
0037fe5c 00000000 ntdll!_RtlUserThreadStart+0x1b

0:000> ~*k
ChildEBP RetAddr
0032faf0 77a9d55c ntdll!ZwTerminateProcess+0x12
0032fb0c 775579f4 ntdll!RtlExitUserProcess+0x85
0032fb20 74ac1720 kernel32!ExitProcessStub+0x12
0032fb28 74ac1a03 msvcr80!__crtExitProcess+0x14
0032fb64 74ac1a4b msvcr80!_cinit+0x101
0032fb74 01339bb3 msvcr80!exit+0xd
0032fbf8 7755339a App!__tmainCRTStartup+0x155
0032fc04 77a89ef2 kernel32!BaseThreadInitThunk+0xe
0032fc44 77a89ec5 ntdll!__RtlUserThreadStart+0x70
0032fc5c 00000000 ntdll!_RtlUserThreadStart+0x1b

However, sometimes, it is possible to see some execution residue left on a raw stack such as hidden exceptions, module hints, error codes and handled exceptions that might shed light on possible causes.

Another variant is when a memory dump is saved after a problem message box is dismissed or potentially disastrous exceptions such as access violations are handled and ignored to the fault in exception handling mechanism or severe corruption resuted in unresponsive process (hang).

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

What is a Software Narrative?

Tuesday, March 20th, 2012

The previous definition of software narratology was restricted to software traces and logs (the top left quadrant on a software narrative square, also the part of Memoretics which studies memory snapshots). Now, with the broadening of the domain of software narratology to the whole world of software narrative stories including actor interactions with software in construction requirements use cases and post-construction incidents we give another definition:

Software narrative is a representation of software events and changes of state. Software Narratology is a discipline that studies such software narratives (software narrative science).

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Welcome to Ki* and Ke*!

Monday, March 19th, 2012

Not long ago we became the proud owners of Ke* parrot named after OS kernel functions. It didn’t behave as we expected (heavily used Reflection API) so Ki* parrot counterpart was brought into a space. They now behave and communicate happily ever after:

They also inspired a Computicart (Computical Art) composition: What is to be done?

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Bugtation No.157

Friday, March 16th, 2012

Debugging before profits.

Dmitry Vostokov

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

I Memory Dump

Thursday, March 15th, 2012

This is both a game and serious philosophical and religious tool to guide your life. Basically you need either 32 coin flips to construct a 32-bit pointer (or 64 flips for wide coverage) or 16 flips using a dice where each throw can generate at least 2 bits. Any device can help if you can get a random pointer. Then you use your favourite memory dump and symbol files for interpretation. Double, triple and multiple dereferences from a pointer can also be used to construe a path.

For example, I just played and got:

0:000> ? 0y10010111111000100100011011100111
Evaluate expression: -1746778393 = 97e246e7

0:000> !address 97e246e7
Address 97e246e7 could not be mapped in any available regions

If address is inaccessible switch to another memory dump or continue flips and shift digits to the left. This way I got:

0:000> ? 0y00101111110001001000110111001111
Evaluate expression: 801410511 = 2fc48dcf

0:000> !address 02fc48dcf
Usage:                  Free
Base Address:           1f858000
End Address:            58c30000
Region Size:            393d8000
Type:                   00000000
State:                  00010000 MEM_FREE
Protect:                00000001 PAGE_NOACCESS

Continue flip and shift until you get an output with symbol signs:

0:000> ? 0y01011111100010010001101110011110
Evaluate expression: 1602821022 = 5f891b9e

0:000> dp 5F891B9E
5f891b9e  ???????? ???????? ???????? ????????
5f891bae  ???????? ???????? ???????? ????????
5f891bbe  ???????? ???????? ???????? ????????
5f891bce  ???????? ???????? ???????? ????????
5f891bde  ???????? ???????? ???????? ????????
5f891bee  ???????? ???????? ???????? ????????
5f891bfe  ???????? ???????? ???????? ????????
5f891c0e  ???????? ???????? ???????? ????????

0:000> !address 5F891B9E
Usage:                  Free
Base Address:           5eb8a000
End Address:            60080000
Region Size:            014f6000
Type:                   00000000
State:                  00010000 MEM_FREE
Protect:                00000001 PAGE_NOACCESS

Unloaded modules that overlapped the region in the past:
BaseAddr EndAddr    Size
5ebc0000 5ebcd000     d000 Perfctrs.dll

Dump output for thought: “In the past - perfect control, performance was counted, now - free.”

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Writing and Validation of Historical Narratives (Part 1)

Sunday, March 11th, 2012

Software narratological approach can be useful for writing, analyzing and validating historical narratives. Trace and event log messages play the role of historical events where process ids are assigned to particular historical institutions and their representatives. Threads serve the role of historical entities like persons. Modules play the role of shared ideologies. We already use this approach for writing history books.

This can also work on a different level such as analyzing a history of debugging as a sequence of troubleshooting and debugging stories. More on this later as I plan to provide concrete examples from history. For the time being please read how software narratology and memoretics (the study of memory snapshots) help fiction writers as well.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Software Problem Description Patterns (Part 1)

Sunday, March 11th, 2012

The development of SPDL requires extending pattern-driven analysis approach to software problems such as software defect and software incident descriptions. Such a pattern language should help with accurate problem identification and problem resolution through software behaviour analysis and with choosing, for example, appropriate workaround patterns or, for a debugging strategy, unified debugging patterns. This can also be applicable to software security incident descriptions as well.

For this first part, we introduce a pattern called, Problem Summary. This is a very short description that summarizes the essence of the problem from a submitter point of view such as a software user or a technical support engineer. Whether it is correct or incorrect is another problem itself but the missing summary usually requires close reading of the whole problem description text and analyze together various relevant parts to reconstruct the summary.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Software Narratology Square

Sunday, March 11th, 2012

After introducing software narrative planes it is logical to expand the field of software narratology to cover the whole domain of software construction and post-construction. We therefore combine both pairs of planes to create a narratological square:

Please also register for the forthcoming free Webinar: Introduction to Software Narratology where I plan to provide a coherent overview of the recent developments in this new field.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Software Narrative Planes

Sunday, March 11th, 2012

Based on an idea of expression and content planes from glossematics with a basic unit of glosseme we can organize software traces with corresponding patterns and software trace narremes (basic units of software narrative such as traces and event logs) into 2 planes: software trace narrative plane (expression) with narremes and the corresponding program lines of traces (PLOTs) source code and design plane (content) with their own set of construction narremes such as collaboration of software constructs. All this corresponds to the following diagram:

The same can be said about actor interaction level of software construction (what ought to be) and post-construction (what is) phases having their own construction and post-construction narratives, patterns and narremes such as in requirements (use cases) and in problem and software incident descriptions:

In the forthcoming articles I provide more examples and explanations including specific software narremes useful from the practical post-construction software problem solving perspective. Please also register for the forthcoming free Webinar: Introduction to Software Narratology where I plan to provide a coherent overview of this new field.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -