I'm currently testing my application on Oracle 12 after all tests passed OK on Oracle 11. During testing the application kept losing the connection to Oracle when running a certain query. Here is a simplified example which replicates the problem exactly:
--create an example table
CREATE TABLE ERROR_TABLE(
PKID INT,
STRING_COLUMN VARCHAR2(255 CHAR)
);
--and run the offending query
SELECT
T.*,
ROW_NUMBER() OVER(
ORDER BY TO_NUMBER(REGEXP_SUBSTR(STRING_COLUMN,'^[0-9]*[.]*[0-9]*')) ASC,
STRING_COLUMN ASC,
PKID ASC
)
FROM
(
SELECT
PKID,
(SELECT MIN(STRING_COLUMN) FROM ERROR_TABLE T1 WHERE T1.PKID = T2.PKID) AS STRING_COLUMN
FROM ERROR_TABLE T2
)T;
When I run this query the connection to Oracle is dropped. There is an 'incident' recorded in the Oracle alert log, but it doesn't say why it happened. It seems to be the combination of the TO_NUMBER(... and the SELECT(MIN... part. If I replace either of those the problem goes away. However, I'm reluctant to do this as it's been tested and validated, and this technique appears in multiple places throughout the program.
Has anyone else encountered anything like this? What is causing it?
I'm running Oracle 12.1.0.1.0. The server is 64-bit and the client is 32-bit.
UPDATE
Here is the relevant excerpt from the alert log:
<msg time='2014-09-29T14:57:30.310+01:00' org_id='oracle' comp_id='rdbms'
type='UNKNOWN' level='16' host_id='ADMIN-PC'
host_addr='fe80::5183:eb5:fdd6:8fce%10' module='SQL Developer' pid='2084'>
<txt>Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x0] [PC:0x7FEF691FB5A, qcsogolz()+208]
</txt>
</msg>
<msg time='2014-09-29T14:57:30.435+01:00' org_id='oracle' comp_id='rdbms'
msg_id='1305664044' type='INCIDENT_ERROR' group='Access Violation'
level='1' host_id='ADMIN-PC' host_addr='fe80::5183:eb5:fdd6:8fce%10'
prob_key='ORA 7445 [qcsogolz]' errid='40818' detail_path='C:\APP\ORACLEUSER\diag\rdbms\orcl\orcl\trace\orcl_ora_2084.trc'>
<txt>Errors in file C:\APP\ORACLEUSER\diag\rdbms\orcl\orcl\trace\orcl_ora_2084.trc (incident=40818):
ORA-07445: exception encountered: core dump [qcsogolz()+208] [ACCESS_VIOLATION] [ADDR:0x0] [PC:0x7FEF691FB5A] [UNABLE_TO_READ] []
</txt>
</msg>
<msg time='2014-09-29T14:57:30.451+01:00' org_id='oracle' comp_id='rdbms'
type='UNKNOWN' level='16' host_id='ADMIN-PC'
host_addr='fe80::5183:eb5:fdd6:8fce%10' module='SQL Developer' pid='2084'>
<txt>Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
</txt>
</msg>
<msg time='2014-09-29T14:57:32.760+01:00' org_id='oracle' comp_id='rdbms'
msg_id='dbgripsto_sweep_staged_obj:15783:70631439' type='ERROR' group='ami_comp'
level='8' host_id='ADMIN-PC' host_addr='fe80::5183:eb5:fdd6:8fce%10'>
<txt>Sweep [inc][40818]: completed
</txt>
</msg>
And here is a copy of the resulting trace file:
Trace file C:\APP\ORACLEUSER\diag\rdbms\orcl\orcl\trace\orcl_ora_2084.trc
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Windows NT Version V6.1 Service Pack 1
CPU : 2 - type 8664, 2 Physical Cores
Process Affinity : 0x0x0000000000000000
Memory (Avail/Total): Ph:882M/2038M, Ph+PgF:1864M/4076M
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 50
Windows thread id: 2084, image: ORACLE.EXE (SHAD)
*** 2014-09-29 14:57:30.310
*** SESSION ID:(18.63977) 2014-09-29 14:57:30.310
*** CLIENT ID:() 2014-09-29 14:57:30.310
*** SERVICE NAME:(pdborcl) 2014-09-29 14:57:30.310
*** MODULE NAME:(SQL Developer) 2014-09-29 14:57:30.310
*** ACTION NAME:() 2014-09-29 14:57:30.310
*** CONTAINER ID:(3) 2014-09-29 14:57:30.310
Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x0] [PC:0x7FEF691FB5A, qcsogolz()+208]
DDE: Problem Key 'ORA 7445 [qcsogolz]' was flood controlled (0x4) (incident: 40818)
ORA-07445: exception encountered: core dump [qcsogolz()+208] [ACCESS_VIOLATION] [ADDR:0x0] [PC:0x7FEF691FB5A] [UNABLE_TO_READ] []
Dump file c:\app\oracleuser\diag\rdbms\orcl\orcl\trace\orcl_ora_2084.trc
Mon Sep 29 14:57:30 2014
ORACLE V12.1.0.1.0 - 64bit Production vsnsta=0
vsnsql=16 vsnxtr=3
Dumping diagnostics for abrupt exit from ksedmp
ksedmp exception at address PC:0x0
ksedmp exception at 0000000000000000
Dumping initial exception call-stack
------------------- Call Stack Trace ---------------------
Frameptr RetAddr Param#1 Param#2 Param#3 Param#4 Function Name
000007FEF691FB5A 0000000000000000 0000000000630072 0000000000000000 0000000000000000 0000000000000000 qcsogolz()+208
000007FEF692BD90 000007FEF691FA8A 000000001969AE00 000007FE00000000 0000000000035490 000007FE00000000 qctcopn()+1904
000007FEF692B7B8 000007FEF692B620 0000000019696BC0 0000000022C90F80 000000014A2062A0 000000014657990E qctcopn()+408
000007FEF692B7B8 000007FEF692B620 000000014A2062A0 00000000196954C0 00000000196954C0 000007FF1A0EC938 qctcopn()+408
000007FEF692B7B8 000007FEF692B620 00000000196964E0 000007FEF65DBEE3 000000001522B400 0000000022C90F80 qctcopn()+408
000007FEF692B7B8 000007FEF692B620 0000000000000000 000000001522A7A8 000000001522A2E8 0000000000000000 qctcopn()+408
000007FEF6928BA3 000007FEF692B620 0000000022C91540 000007FEF65DBC6D 0000000000000000 000000001522A9B8 qctcpqb()+291
000007FEF6928A53 000007FEF6928A80 0000000019695C20 0000000022C90F80 0000000000035490 00000001433D61D6 qctcpqbl()+51
000000014561599A 000007FEF6928A20 00000001460088E0 000000002DDB5570 0000000000000001 000000001522A9B8 xtydrv()+138
0000000145FE901F 0000000145615910 0000000015227AC8 0000000000000000 0000000022C91540 000007FEF65DBFCC kkqcttcalo()+383
0000000145FF4C5D 0000000145FE8EA0 0000000000000000 0000000000000000 0000000000008000 0000000002000000 kkqctdrvCVM()+1501
00000001462F36EF 0000000145FF4A37 0000000000000000 0000000000000433 0000000022C91540 000007FEF61F6186 kkqvmTrMrg()+3087
00000001462F2148 00000001462F2AE0 0000000000000000 00000001422DEED1 0000000000000001 0000000000037038 kkqvmdrv2()+872
00000001460059B9 00000001462F1DE0 0000000000000000 000007FEF65E1153 0000000000000000 00000001460D7EAE kkqctdrvTD()+809
0000000145F213E1 0000000146005690 0000000000000000 000000002DDB5ED0 0000000000000002 00000000000000A1 kkqdrv()+6977
000000014600504C 0000000145F1F8A0 0000000015222578 000007FF00000000 000000000003AF58 000007FF1A0ECB80 kkqctdrvIT()+828
0000000145EE8B5A 0000000146004D10 0000000000000000 000000001522FF48 0000000000000038 000000001522FF48 apadrv()+4010
0000000143250A15 0000000145EE7BB0 0000000000000000 0000000000000433 0000000000000000 0000000000000000 opitca()+2565
000000014025C3A6 0000000143250010 00000000196EEB60 000007FF1A0ECB80 000000002DDB8CE8 0000000100000002 kksLoadChild()+8886
0000000140DA2D9E 000000014025A0F0 0000000022C91540 000007FF1839B920 000007FF1CE6F730 000007FF1839B920 kxsGetRuntimeLock()+2414
0000000140BE5A2A 0000000140DA2430 0000000022C91540 00000000196EEB60 000000002DDB8110 000000000000012C kksfbc()+15626
0000000140BDCB6E 0000000140BE1FD0 00000000196EEB60 0000000000000003 000007FF00000108 000000002DDBB020 kkspsc0()+2526
0000000140BDE812 0000000140BDC43E 0000000015242330 000000002DDBB020 0000000000000137 0000000000000003 kksParseCursor()+130
000000014630AC0C 0000000140BDE790 00000000151C6AF8 00000000151C9B98 0000000000000000 000007FEF7C21726 opiosq0()+3004
00000001442E760A 000000014630A050 000007FF00000003 000000014915B0C0 0000000000000000 00000000000000A4 kpooprx()+410
00000001442E3A52 00000001442E7470 0000000022C962AC 0000000000000001 0000000022C962D0 0000000000000001 kpoal8()+994
0000000140E685C1 00000001442E3670 0000000000000001 000000002DDBB2BC 00000000169711A0 000000002DDBB295 opiodr()+1601
000007FEF75CD7A7 0000000140E67F80 000007FF0000005E 000007FF0000001F 000000002DDBD8A0 000007FE00000000 ttcpip()+1223
0000000140E64E10 000007FEF75CD2E0 0000000022CB1140 0000000000000000 0000000000000000 0000000000000000 opitsk()+2160
0000000144768CD7 0000000140E645A0 0000000000000000 0000000000000000 000000002DDBF080 000000002DDBE7F0 opiino()+1079
0000000140E685C1 00000001447688A0 000000000000003C 0000000000000000 000000002DDBF2F0 0000000000000000 opiodr()+1601
000000013FE2F68A 0000000140E67F80 000000000000003C 0000000000000004 000000002DDBF2F0 0000000000000000 opidrv()+842
000000013FE3074E 000000013FE2F3DC 000000010000003C 000007FE00000004 000000002DDBF2F0 0000000015106A28 sou2o()+94
000000013FD612E4 000000013FE306F0 01CFDBED484830FD 0000000014A364D0 000E001D000907DE 0001015900120039 opimai_real()+276
000000013FD610BA 000000013FD611D0 0000000000000000 0000D6736DC2EA78 0000000014A364D0 000000002DDBF4A8 opimai()+170
000000013FD62239 000000013FD61010 0000000000000000 0000000149041F90 0000000000000050 000000000000196C OracleThreadStart()+713
0000000076CC59ED 000000013FD61F70 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000076CC59ED
0000000076EFC541 0000000076CC59E0 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000076EFC541
---------------- End of Call Stack Trace -----------------
This is a bug in 12.1.0.1 (Bug 17633803). It will be fixed in 12.2 and patched in 12.1.0.2.
There is a workaround which is to run
ALTER SESSION SET "_optimizer_unnest_scalar_sq"=false;
I've tried running your sample code above and the workaround does fix the issue in 12.1.0.1
UPDATE
Tested as fixed and working (without the workaround) in 12.1.0.2
Related
I'm attempting to write some ELF parsing logic (in C). Specifically, I'm trying to identify which entries in the GOT correspond to which functions.
I've crafted a simple program which contains references to malloc and free. Some relevant excerpts from readelf -a a.out:
Relocation section '.rela.plt' at offset 0x630 contains 2 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000003fc8 0000000100000007 R_X86_64_JUMP_SLOT 0000000000000000 free#GLIBC_2.2.5 + 0
0000000000003fd0 0000000500000007 R_X86_64_JUMP_SLOT 0000000000000000 malloc#GLIBC_2.2.5 + 0
No processor specific unwind information to decode
Symbol table '.dynsym' contains 8 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND free#GLIBC_2.2.5 (2)
2: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main#GLIBC_2.34 (3)
3: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTable
4: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
5: 0000000000000000 0 FUNC GLOBAL DEFAULT UND malloc#GLIBC_2.2.5 (2)
6: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable
7: 0000000000000000 0 FUNC WEAK DEFAULT UND __cxa_finalize#GLIBC_2.2.5 (2)
I know how to use .dynstr to get the names of the symbols in .dynsym. However, how is readelf populating the symbol names in .rela.plt? I'm not seeing anything in the definitions of either Elf64_Sym or Elf64_Rel which would help. At first, I thought the st_shndx field in Elf64_Sym would be relevant but readelf is showing that value as SHN_UNDEF.
The information is contained in the Elf64_Rel structure. Specifically, the r_info field:
This member gives both the symbol table index with respect to which the relocation must be made and the type of relocation to apply.
The ELF64_R_SYM macro can be used to extract the offset from this field. As seen in the .rela.plt description in the OP, free, for example, has an index of 1 which corresponds to entry 1 in .dynsym.
I'm working with elf64 files and i was wondering two things, the first is, in which segment the shstrtable is stored, because reviewing readelf -l doesn't appear. And the other question (coming from the first one) is it possible for a section not be inside a segment?
Also i noticed some 'gaps' between some segments. What is inside those gaps?
I am using the following example, that is an hello_world.c:
readelf -lW hello
El tipo del fichero elf es DYN (Fichero objeto compartido)
Entry point 0x1040
There are 11 program headers, starting at offset 64
Encabezados de Programa:
Tipo Desplaz DirVirt DirFísica TamFich TamMem Opt Alin
PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x000268 0x000268 R 0x8
INTERP 0x0002a8 0x00000000000002a8 0x00000000000002a8 0x00001c 0x00001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x000560 0x000560 R 0x1000
LOAD 0x001000 0x0000000000001000 0x0000000000001000 0x0001e5 0x0001e5 R E 0x1000
LOAD 0x002000 0x0000000000002000 0x0000000000002000 0x000118 0x000118 R 0x1000
LOAD 0x002de8 0x0000000000003de8 0x0000000000003de8 0x000248 0x000250 RW 0x1000
DYNAMIC 0x002df8 0x0000000000003df8 0x0000000000003df8 0x0001e0 0x0001e0 RW 0x8
NOTE 0x0002c4 0x00000000000002c4 0x00000000000002c4 0x000044 0x000044 R 0x4
GNU_EH_FRAME 0x00200c 0x000000000000200c 0x000000000000200c 0x000034 0x000034 R 0x4
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
GNU_RELRO 0x002de8 0x0000000000003de8 0x0000000000003de8 0x000218 0x000218 R 0x1
mapeo de Sección a Segmento:
Segmento Secciones...
00
01 .interp
02 .interp .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt
03 .init .plt .text .fini
04 .rodata .eh_frame_hdr .eh_frame
05 .init_array .fini_array .dynamic .got .got.plt .data .bss
06 .dynamic
07 .note.gnu.build-id .note.ABI-tag
08 .eh_frame_hdr
09
10 .init_array .fini_array .dynamic .got
in which segment the shstrtable is stored, because reviewing readelf -l doesn't appear.
It doesn't appear in any segment.
And the other question (coming from the first one) is it possible for a section not be inside a segment?
Yes.
Also i noticed some 'gaps' between some segments. What is inside those gaps?
Nothing. Segments tell the kernel or the runtime loader how to mmap the on-disk binary into memory. Since mmap operates on whole pages (4096 bytes here), the contents of memory between 0x560 and 0xFFF will be "whatever happens to be in the file at offsets 0x560 through 0xFFF, but the program shouldn't access it and the contents is effectively undefined. See also this answer.
There were undefined crashes from the game. There is no specific logic for the application crash. After H, the amount of time always flies to the desktop.
There is no definite logic that may accompany the crash of the game itself.
Game - Grand theft Auto 5
I am attaching the file dump code from the procdump
Help, Guys :)
Microsoft (R) Windows Debugger Version 10.0.20153.1000 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\*\*\*\*\Procdump\GTA5.exe_210102_114206.dmp]
Comment: '
*** procdump.exe -accepteula -e -w GTA5.exe C:\*\*\*\*\Procdump
*** Unhandled exception: C0000005.ACCESS_VIOLATION'
User Mini Dump File: Only registers, stack and portions of memory are available
Symbol search path is: srv*
Executable search path is:
Windows 10 Version 18363 MP (12 procs) Free x64
Product: WinNt, suite: SingleUserTS
Edition build lab: 16299.15.amd64fre.rs3_release.170928-1534
Machine Name:
Debug session time: Sat Jan 2 11:42:06.000 2021 (UTC + 3:00)
System Uptime: not available
Process Uptime: 0 days 0:00:24.000
................................................................
................................................................
...........................................
Loading unloaded module list
.........
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(2ca8.4828): Access violation - code c0000005 (first/second chance not available)
For analysis of this file, run !analyze -v
00000001`9647d9da ?? ???
0:099> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
*** WARNING: Unable to verify checksum for v8_libplatform.dll
*** WARNING: Unable to verify checksum for v8_libbase.dll
KEY_VALUES_STRING: 1
Key : AV.Fault
Value: Execute
Key : Analysis.CPU.mSec
Value: 3843
Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on verboten
Key : Analysis.DebugData
Value: CreateObject
Key : Analysis.DebugModel
Value: CreateObject
Key : Analysis.Elapsed.mSec
Value: 53003
Key : Analysis.Memory.CommitPeak.Mb
Value: 422
Key : Analysis.System
Value: CreateObject
Key : Timeline.Process.Start.DeltaSec
Value: 24
Key : WER.OS.Branch
Value: rs3_release
Key : WER.OS.Timestamp
Value: 2017-09-28T15:34:00Z
Key : WER.OS.Version
Value: 10.0.16299.15
Key : WER.Process.Version
Value: 1.0.2189.0
ADDITIONAL_XML: 1
OS_BUILD_LAYERS: 1
COMMENT:
*** procdump.exe -accepteula -e -w GTA5.exe C:\Users\Influence\Downloads\ìàøèíêè\Procdump
*** Unhandled exception: C0000005.ACCESS_VIOLATION
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
CONTEXT: (.ecxr)
rax=000000019647d9da rbx=0000021315c1a780 rcx=000000d2c828f428
rdx=0000000000000000 rsi=000000d2c828f650 rdi=000000000ac3595f
rip=000000019647d9da rsp=000000d2c828f430 rbp=0000000000000008
r8=000000d2c828f228 r9=000000d2c828f290 r10=0000000000000000
r11=0000000000000246 r12=00007ff798a0d110 r13=0000000000000000
r14=0000000000001dac r15=0000000000000000
iopl=0 nv up ei pl nz ac po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010214
00000001`9647d9da ?? ???
Resetting default scope
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 000000019647d9da
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000008
Parameter[1]: 000000019647d9da
Attempt to execute non-executable address 000000019647d9da
PROCESS_NAME: GTA5.exe
EXECUTE_ADDRESS: 19647d9da
FAILED_INSTRUCTION_ADDRESS:
+0
00000001`9647d9da ?? ???
ERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%p 0x%p. %s.
EXCEPTION_CODE_STR: c0000005
EXCEPTION_PARAMETER1: 0000000000000008
EXCEPTION_PARAMETER2: 000000019647d9da
IP_ON_HEAP: 000000019647d9da
The fault address in not in any loaded module, please check your build's rebase
log at <releasedir>\bin\build_logs\timebuild\ntrebase.log for module which may
contain the address if it were loaded.
IP_IN_FREE_BLOCK: 19647d9da
ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [ThreadStartAddress] from Frame:[0] on thread:[4828] ; Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]
IP_ON_STACK:
+0
000000d2`c828f650 480000 add byte ptr [rax],al
FRAME_ONE_INVALID: 1
STACK_TEXT:
00000000`00000000 00000000`00000000 GTA5!Unknown+0x0
SYMBOL_NAME: GTA5!Unknown+0
MODULE_NAME: GTA5
IMAGE_NAME: GTA5.exe
STACK_COMMAND: dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; .ecxr ; ~~[0x4828]s ; .frame 0 ; ** Pseudo Context ** ManagedPseudo ** Value: 245d18ea380 ** ; kb
FAILURE_BUCKET_ID: SOFTWARE_NX_FAULT_c0000005_GTA5.exe!Unknown
OS_VERSION: 10.0.16299.15
BUILDLAB_STR: rs3_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
IMAGE_VERSION: 1.0.2189.0
FAILURE_ID_HASH: {ca327b34-8007-c923-925a-40afa98955f0}
Followup: MachineOwner
---------
readelf -S of a particular binary gives the following output
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .interp PROGBITS 0000000000400238 00000238
000000000000001c 0000000000000000 A 0 0 1
[ 2] .note.ABI-tag NOTE 0000000000400254 00000254
0000000000000020 0000000000000000 A 0 0 4
[ 3] .hash HASH 0000000000400278 00000278
0000000000000a7c 0000000000000004 A 4 0 8
[ 4] .dynsym DYNSYM 0000000000400cf8 00000cf8
.
.
.
Difference between virtual address and offset of first section .interp is 0x400000. I am curious as to:
how is this calculated?
Is there a programmatic way of determining this?
how is this calculated?
You just calculated it yourself: 0x400238 - 0x238 == 0x400000. Your question is probably "why is this particular address selected?".
This is the default link-at address for Linux x86_64 position dependent binaries. You can change that address with -Ttext=... linker flag. The default is different for ix86 (32-bit) binaries: it's 0x8048000.
I am not sure why these particular defaults were chosen.
Is there a programmatic way of determining this?
Sure: read the Elf64_Ehdr from the start of the file. It will tell you offset to the start of program headers (.e_phoff). Seek to that offset, and read Elf64_Phdrs. Now iterate over them, and their .p_vaddr and .p_offset will have the same values.
P.S. You are looking at program sections which are not used and are not guaranteed to be present in a fully-linked binary. You should be looking at program segments instead. Use readelf -Wl a.out to examine them.
Since last week, Word and Excel are often crashing, even on very simple documents. Just now, Firefox also crashed. What can I do to repair it or find the real root cause?
I have already repaired Office installation using the Setup. All regular updates should be installed. Laptop is rebooted every day.
I have configured WinDbg to attach and this is what I get. I also have a dump, so if you need more information, I can still get it. Here's info from my first dump of Word:
0:020> .exr -1
ExceptionAddress: 11fdf91c
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000008
Parameter[1]: 11fdf91c
Attempt to execute non-executable address 11fdf91c
0:020> kb
ChildEBP RetAddr Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
11fdf91c 75d05d3f 00000008 0dc0bbe8 fffffffe 0x11fdf91c
11fdfacc 75d38f82 bf3079e6 0dc0bbe8 00000000 ole32!COIDTable::ThreadCleanup+0xcb [d:\w7rtm\com\ole32\com\dcomrem\idobj.cxx # 1760]
11fdfb10 75d38ec3 00000000 11fdfb60 75e37724 ole32!FinishShutdown+0x9d [d:\w7rtm\com\ole32\com\class\compobj.cxx # 1035]
11fdfb30 75d2bac3 00000000 75d309ad 0dc0bbe8 ole32!ApartmentUninitialize+0x96 [d:\w7rtm\com\ole32\com\class\compobj.cxx # 1291]
11fdfb48 75d388e8 11fdfb60 00000000 00000000 ole32!wCoUninitialize+0x153 [d:\w7rtm\com\ole32\com\class\compobj.cxx # 2766]
11fdfb64 6e77314a 11fdfbf4 75f043c0 0b179b08 ole32!CoUninitialize+0x72 [d:\w7rtm\com\ole32\com\class\compobj.cxx # 2620]
11fdfb6c 75f043c0 0b179b08 00000000 00000000 NetworkItemFactory!FDBackgroundThreadHandler+0x21
11fdfbf4 75bf336a 0da0f624 11fdfc40 773a9f72 SHLWAPI!WrapperThreadProc+0x1b5
11fdfc00 773a9f72 0da0f624 66709c63 00000000 kernel32!BaseThreadInitThunk+0xe
11fdfc40 773a9f45 75f042ed 0da0f624 ffffffff ntdll!__RtlUserThreadStart+0x70
11fdfc58 00000000 75f042ed 0da0f624 00000000 ntdll!_RtlUserThreadStart+0x1b
0:020> vertarget
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
kernel32.dll version: 6.1.7601.18229 (win7sp1_gdr.130801-1533)
Machine Name:
Debug session time: Wed Feb 5 14:55:55.241 2014 (UTC + 1:00)
System Uptime: 0 days 3:46:03.386
Process Uptime: 0 days 0:05:08.582
Kernel time: 0 days 0:00:03.822
User time: 0 days 0:00:11.528
If I recall correctly, it was related to a VOIP software called Netphone Client from Deutsche Telekom, which includes itself into other applications via a COM object.
Therefore this was exactly as projected by Hans Passant in the comments:
You are buried inside the COM plumbing with a clear hint that its internal state is corrupted. This is an environmental problem, some kind of DLL that gets injected into the process and screws things up. Long before the crash occurs so you'll have very little hope of diagnosing it with a debugger. Find the common source of the problem from the modules list. Suspect any shell extension, anti-malware, any utility similar to Dropbox. Use SysInternals' AutoRuns to disable them.
I don't remember how exactly I found the culprit, but I finally used a physical VOIP phone instead of the software + headset.