Profiling some code with perf, I get a stack trace that looks like this:
+ 7.29% 0.00% test [unknown] [.] 0000000000000000 ▒
- 5.71% 5.68% test libc-2.21.so [.] __memset_sse2 ▒
- __memset_sse2 ▒
- 55.60% 0 ▒
+ 97.30% 0 ▒
2.70% 0x19 ▒
+ 20.92% 0x7 ▒
+ 16.83% 0x34 ▒
+ 2.69% 0x8 ▒
+ 2.00% 0x9 ▒
+ 1.00% 0x11 ▒
0.97% 0xe ▒
+ 5.55% 0.23% test libc-2.21.so [.] epoll_ctl ▒
+ 4.62% 0.15% test [kernel.vmlinux] [k] nf_hook_slow ▒
+ 4.60% 0.23% test [kernel.vmlinux] [k] tcp_data_queue ▒
I have no idea what the 0 addresses mean. When I press the right-arrow key, I don't get an option to disassemble the code, so I can't get any clues from there either.
How do I figure out what's calling memset?
Related
I am analyzing memory dump with bad_alloc exception and find a significant region of memory what windbg call
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
<unknown> 4689 3bdc4000 ( 957.766 MB) 48.75% 46.77%
Heap 2228 2a1db000 ( 673.855 MB) 34.30% 32.90%
Image 1451 b66f000 ( 182.434 MB) 9.29% 8.91%
Stack 444 9400000 ( 148.000 MB) 7.53% 7.23%
Free 1607 5371000 ( 83.441 MB) 4.07%
TEB 148 1ad000 ( 1.676 MB) 0.09% 0.08%
Other 122 c1000 ( 772.000 kB) 0.04% 0.04%
PEB 1 3000 ( 12.000 kB) 0.00% 0.00%
And I'm sure that it's native app. I know address of region
--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
<unknown> aa20000 5f2e000 ( 95.180 MB)
and want to find who allocated this memory. How I can do that?
0:118> !address aa20000
Usage: <unknown>
Base Address: 0aa20000
End Address: 1094e000
Region Size: 05f2e000 ( 95.180 MB)
State: 00001000 MEM_COMMIT
Protect: 00000002 PAGE_READONLY
Type: 00040000 MEM_MAPPED
Allocation Base: 0aa20000
Allocation Protect: 00000002 PAGE_READONLY
Heap function don't work with this peace of memory. I asked about dump with gflags enabled, but now I have to work with data I have. Thank you for your advice!
I'm working on a C++ project on Windows 10, its been noticed that over time the Handles associated with the process increases and continues to grow.
Searching online for a reason I'm not sure if this means that the process has a memory leak or if this is normal.
When memory is allocated and then freed, would I see the handles increase and decrease?
I've been using this as I'm struggling to find what the cause is:
https://learn.microsoft.com/en-us/archive/blogs/markrussinovich/pushing-the-limits-of-windows-handles
I cannot find any calls to anything that creates a handle in the code.
[Edit] Using windbg to open the dumped process content:
Microsoft (R) Windows Debugger Version 10.0.18362.1 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\u49100\Downloads\ManagementServiceGroup.dmp]
User Mini Dump File with Full Memory: Only application data is available
Symbol search path is: srv*
Executable search path is:
Windows 10 Version 16299 MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
16299.637.x86fre.rs3_release_svc.180808-1748
Machine Name:
Debug session time: Wed Feb 5 09:56:54.000 2020 (UTC + 0:00)
System Uptime: 0 days 0:44:55.871
Process Uptime: 0 days 0:02:30.000
................................................................
.....................................
This dump file has a breakpoint exception stored in it.
The stored exception information can be accessed via .ecxr.
For analysis of this file, run !analyze -v
eax=002f1000 ebx=00000000 ecx=7707a080 edx=7707a080 esi=7707a080 edi=7707a080
eip=77041900 esp=0d24ff54 ebp=0d24ff80 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000244
ntdll!DbgBreakPoint:
77041900 cc int 3
0:075> !analyze -v
ERROR: FindPlugIns 8007007b
ERROR: Some plugins may not be available [8007007b]
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
*** WARNING: Unable to verify checksum for PlatformSG.dll
*** WARNING: Unable to verify checksum for ManagementServiceGroup.exe
*** WARNING: Unable to verify checksum for SlaveCommsSG.dll
*** WARNING: Unable to verify checksum for CalibrationFramework.dll
*** WARNING: Unable to verify checksum for SPLINTServer.dll
*** WARNING: Unable to verify checksum for TCPIPManager.dll
*** WARNING: Unable to verify checksum for MillikanFaults.dll
*** WARNING: Unable to verify checksum for MillikanCalibration.dll
*** WARNING: Unable to verify checksum for HBC.dll
*** WARNING: Unable to verify checksum for Machine.dll
*** WARNING: Unable to verify checksum for Vibrator.dll
*** WARNING: Unable to verify checksum for TelnetServer.dll
*** WARNING: Unable to verify checksum for UserDefects.dll
*** WARNING: Unable to verify checksum for HBCStatCollector.dll
*** WARNING: Unable to verify checksum for StatisticsArchiver.dll
*** WARNING: Unable to verify checksum for SplintVibratorCalibration.dll
*** WARNING: Unable to verify checksum for StatisticsHistorian.dll
*** WARNING: Unable to verify checksum for ModeManager.dll
*** WARNING: Unable to verify checksum for SPLINTStatDistributor.dll
*** WARNING: Unable to verify checksum for IOMillikan.dll
*** WARNING: Unable to verify checksum for ProcessControlSG.dll
*** WARNING: Unable to verify checksum for CameraGroup.dll
*** WARNING: Unable to verify checksum for ComponentLifeMonitor.dll
KEY_VALUES_STRING: 1
Key : Timeline.OS.Boot.DeltaSec
Value: 2695
Key : Timeline.Process.Start.DeltaSec
Value: 150
PROCESSES_ANALYSIS: 1
SERVICE_ANALYSIS: 1
STACKHASH_ANALYSIS: 1
TIMELINE_ANALYSIS: 1
Timeline: !analyze.Start
Name: <blank>
Time: 2020-02-05T10:01:43.660Z
Diff: 289660 mSec
Timeline: Dump.Current
Name: <blank>
Time: 2020-02-05T09:56:54.0Z
Diff: 0 mSec
Timeline: Process.Start
Name: <blank>
Time: 2020-02-05T09:54:24.0Z
Diff: 150000 mSec
Timeline: OS.Boot
Name: <blank>
Time: 2020-02-05T09:11:59.0Z
Diff: 2695000 mSec
DUMP_CLASS: 2
DUMP_QUALIFIER: 400
CONTEXT: (.ecxr)
eax=002f1000 ebx=00000000 ecx=7707a080 edx=7707a080 esi=7707a080 edi=7707a080
eip=77041900 esp=0d24ff54 ebp=0d24ff80 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000244
ntdll!DbgBreakPoint:
77041900 cc int 3
Resetting default scope
FAULTING_IP:
ntdll!DbgBreakPoint+0
77041900 cc int 3
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 77041900 (ntdll!DbgBreakPoint)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 1
Parameter[0]: 00000000
PROCESS_NAME: ManagementServiceGroup.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
EXCEPTION_CODE_STR: 80000003
EXCEPTION_PARAMETER1: 00000000
WATSON_BKT_PROCSTAMP: 5e38030b
WATSON_BKT_MODULE: ntdll.dll
WATSON_BKT_MODSTAMP: 7b4896c1
WATSON_BKT_MODOFFSET: 71900
WATSON_BKT_MODVER: 10.0.16299.936
MODULE_VER_PRODUCT: Microsoft® Windows® Operating System
BUILD_VERSION_STRING: 16299.637.x86fre.rs3_release_svc.180808-1748
MODLIST_WITH_TSCHKSUM_HASH: 70177fe8843802a721ebc9381c39ea0930d91d47
MODLIST_SHA1_HASH: 88c13d9b0d70b5ff412cbabd039482499bc59744
NTGLOBALFLAG: 1100
PROCESS_BAM_CURRENT_THROTTLED: 0
PROCESS_BAM_PREVIOUS_THROTTLED: 0
APPLICATION_VERIFIER_FLAGS: 80000004
CHKIMG_EXTENSION: !chkimg -lo 50 -d !ntdll
77030eb0-77030eb4 5 bytes - ntdll!LdrLoadDll
[ 8b ff 55 8b ec:e9 9b 68 8c fc ]
7703f780-7703f784 5 bytes - ntdll!NtAllocateVirtualMemory (+0xe8d0)
[ b8 18 00 00 00:e9 0b 69 8b fc ]
7703f800-7703f804 5 bytes - ntdll!NtFreeVirtualMemory (+0x80)
[ b8 1e 00 00 00:e9 eb 6c 8b fc ]
7703f8a0-7703f8a4 5 bytes - ntdll!NtMapViewOfSection (+0xa0)
[ b8 28 00 00 00:e9 5b 77 8b fc ]
7703f8c0-7703f8c4 5 bytes - ntdll!NtUnmapViewOfSection (+0x20)
[ b8 2a 00 00 00:e9 cb 7b 8b fc ]
7703f9c0-7703f9c4 5 bytes - ntdll!NtWriteVirtualMemory (+0x100)
[ b8 3a 00 00 00:e9 bb 73 8b fc ]
7703fa10-7703fa14 5 bytes - ntdll!NtReadVirtualMemory (+0x50)
[ b8 3f 00 00 00:e9 ab 74 8b fc ]
7703fa70-7703fa74 5 bytes - ntdll!NtQueueApcThread (+0x60)
[ b8 45 00 00 00:e9 cb 7b 8b fc ]
7703fb20-7703fb24 5 bytes - ntdll!NtProtectVirtualMemory (+0xb0)
[ b8 50 00 00 00:e9 db 6a 8b fc ]
7703fd80-7703fd84 5 bytes - ntdll!NtAlpcConnectPort (+0x260)
[ b8 76 00 00 00:e9 ab 89 8b fc ]
77040e30-77040e34 5 bytes - ntdll!NtSetContextThread (+0x10b0)
[ b8 81 01 00 00:e9 eb 76 8b fc ]
77041290-77041294 5 bytes - ntdll!NtWaitForDebugEvent (+0x460)
[ b8 c7 01 00 00:e9 7b 00 8d fc ]
77041930-77041934 5 bytes - ntdll!KiUserApcDispatcher (+0x6a0)
[ 83 3d 98 77 0e:e9 2b 82 91 fc ]
65 errors : !ntdll (77030eb0-77041934)
PRODUCT_TYPE: 1
SUITE_MASK: 272
DUMP_FLAGS: c07
DUMP_TYPE: 3
APPLICATION_VERIFIER_LOADED: 1
ANALYSIS_SESSION_HOST: HW-WOP-113835
ANALYSIS_SESSION_TIME: 02-05-2020 10:01:43.0660
ANALYSIS_VERSION: 10.0.18362.1 x86fre
THREAD_ATTRIBUTES:
ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]
OS_LOCALE: ENG
BUGCHECK_STR: MEMORY_CORRUPTION_PATCH_AVRF
DEFAULT_BUCKET_ID: MEMORY_CORRUPTION_PATCH_AVRF
PRIMARY_PROBLEM_CLASS: MEMORY_CORRUPTION
PROBLEM_CLASSES:
ID: [0n98]
Type: [AVRF]
Class: Addendum
Scope: DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
BUCKET_ID
Name: Add
Data: Omit
PID: [0x4254]
TID: [0x445c]
Frame: [0] : ntdll!DbgBreakPoint
ID: [0n209]
Type: [MEMORY_CORRUPTION]
Class: Primary
Scope: DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
BUCKET_ID
Name: Add
Data: Omit
PID: [0x4254]
TID: [0x445c]
Frame: [Unspecified]
ID: [0n157]
Type: [PATCH]
Class: Addendum
Scope: DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
BUCKET_ID
Name: Add
Data: Omit
PID: [0x4254]
TID: [0x445c]
Frame: [Unspecified]
LAST_CONTROL_TRANSFER: from 7707a0b9 to 77041900
STACK_TEXT:
00000000 00000000 memory_corruption!ntdll+0x0
STACK_COMMAND: ** Pseudo Context ** ManagedPseudo ** Value: 173e49f0 ** ; kb
THREAD_SHA1_HASH_MOD_FUNC: 646019e7612e819fc8aba56460d68e5912f8f117
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 70e2aeaf8a93e9fa2f653f0a0ed9deec52e32f7e
THREAD_SHA1_HASH_MOD: 7da7fbec386ce361a40d03d69a994bc4836f03e8
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: memory_corruption!ntdll
FOLLOWUP_NAME: MachineOwner
DEBUG_FLR_IMAGE_TIMESTAMP: 0
BUCKET_ID: MEMORY_CORRUPTION_PATCH_AVRF_memory_corruption!ntdll
FAILURE_EXCEPTION_CODE: 80000003
IMAGE_NAME: memory_corruption
FAILURE_IMAGE_NAME: memory_corruption
BUCKET_ID_IMAGE_STR: memory_corruption
MODULE_NAME: memory_corruption
FAILURE_MODULE_NAME: memory_corruption
BUCKET_ID_MODULE_STR: memory_corruption
FAILURE_FUNCTION_NAME: ntdll
BUCKET_ID_FUNCTION_STR: ntdll
BUCKET_ID_OFFSET: 0
BUCKET_ID_MODTIMEDATESTAMP: 0
BUCKET_ID_MODCHECKSUM: 0
BUCKET_ID_MODVER_STR: 0.0.0.0
BUCKET_ID_PREFIX_STR:
FAILURE_PROBLEM_CLASS: MEMORY_CORRUPTION
FAILURE_SYMBOL_NAME: memory_corruption!ntdll
FAILURE_BUCKET_ID: MEMORY_CORRUPTION_PATCH_AVRF_80000003_memory_corruption!ntdll
TARGET_TIME: 2020-02-05T09:56:54.000Z
OSBUILD: 16299
OSSERVICEPACK: 1146
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
OSPLATFORM_TYPE: x86
OSNAME: Windows 10
OSEDITION: Windows 10 WinNt SingleUserTS
USER_LCID: 0
OSBUILD_TIMESTAMP: 2014-08-09 10:57:59
BUILDDATESTAMP_STR: 180808-1748
BUILDLAB_STR: rs3_release_svc
BUILDOSVER_STR: 10.0.16299.637.x86fre.rs3_release_svc.180808-1748
ANALYSIS_SESSION_ELAPSED_TIME: 1c133
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:memory_corruption_patch_avrf_80000003_memory_corruption!ntdll
FAILURE_ID_HASH: {fff25d61-b919-7e8b-df9e-56dec8271fe1}
Followup: MachineOwner
---------
This doesn't mean a lot to me, if anyone has expertise in how to interpret this, your input would be very much appreciated.
[Edit 18-02-2020 Another dump and windbg output]
Microsoft (R) Windows Debugger Version 10.0.18362.1 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\Stuff\ManagementServiceGroup.dmp]
User Mini Dump File with Full Memory: Only application data is available
Symbol search path is: srv*
Executable search path is:
Windows 10 Version 14393 MP (2 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
10.0.14393.2430 (rs1_release_inmarket_aim.180806-1810)
Machine Name:
Debug session time: Tue Feb 18 10:22:54.000 2020 (UTC + 0:00)
System Uptime: 0 days 0:41:07.933
Process Uptime: 0 days 0:40:15.000
...............................................................................................
For analysis of this file, run !analyze -v
eax=0000000d ebx=00000000 ecx=0014f96c edx=775d53d0 esi=00000001 edi=00000001
eip=775d53d0 esp=0014f96c ebp=0014fb00 iopl=0 nv up ei pl zr na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000247
ntdll!KiFastSystemCallRet:
775d53d0 c3 ret
windbg !handle will provide a summary after displaying individual handles
the summary will show how many handles are there for each type
screenshot below
cmd.exe pid 5124 has 22 handles
the command below attaches windbg to pid non-invasively executes !handle and quits
gnuwin32-awk filters only the relevant data
cdb -pv -c "!handle;q" -p 5124 | awk "/Handles/,/quit/"
result
:\>cdb -pv -c "!handle;q" -p 5124 | awk "/Handles/,/quit/"
23 Handles
Type Count
Event 2
File 2
Directory 1
WindowStation 2
Key 10
Process 2
Thread 1
Desktop 1
ALPC Port 2
quit:
I built my React Native app fully in Expo and built with expo build:ios, without ever ejecting.
My app was rejected for Beta Testing in Testflight, and there are crash logs in txt file format, and this is the thread that crashed:
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x000000022c4d10dc 0x22c4ae000 + 143580
1 libsystem_pthread.dylib 0x000000022c54a094 0x22c548000 + 8340
2 libsystem_c.dylib 0x000000022c42aea8 0x22c3d0000 + 372392
3 libc++abi.dylib 0x000000022baf7788 0x22baf6000 + 6024
4 libc++abi.dylib 0x000000022baf7934 0x22baf6000 + 6452
5 libobjc.A.dylib 0x000000022bb0ee00 0x22bb09000 + 24064
6 libc++abi.dylib 0x000000022bb03838 0x22baf6000 + 55352
7 libc++abi.dylib 0x000000022bb038c4 0x22baf6000 + 55492
8 libdispatch.dylib 0x000000022c3747e8 0x22c314000 + 395240
9 libdispatch.dylib 0x000000022c322004 0x22c314000 + 57348
10 CoreFoundation 0x000000022c8c5c1c 0x22c81c000 + 695324
11 CoreFoundation 0x000000022c8c0b54 0x22c81c000 + 674644
12 CoreFoundation 0x000000022c8c00b0 0x22c81c000 + 671920
13 GraphicsServices 0x000000022eac079c 0x22eab6000 + 42908
14 UIKitCore 0x0000000258e30978 0x258574000 + 9161080
15 ExpoKitApp 0x00000001007fb2d8 0x1007f4000 + 29400
16 libdyld.dylib 0x000000022c3858e0 0x22c384000 + 6368
I can't figure out how to symbolicate these because all I have is a txt file.
I'm also concerned that even a symbolicated log will be helpful, because it looks like there's a single step, simply labeled ExpoKitApp, that started the crash, and I can't imagine there being much useful information that might come out of that one line.
Does anyone have experience hunting down crash bugs in an unejected Expo app?
If I have a C or CPP program written like
#include <stdio.h>
int bss_section_object[10];
int main()
{
return 0;
}
After compiling the code with gcc/g++,
$g++ -save-temps aa.cpp
If I check the size of generated object and executable files
$ls -ltr
-rw-rw-r-- 1 dinesh dinesh 77 Feb 14 12:42 aa.cpp
-rw-rw-r-- 1 dinesh dinesh 17283 Feb 14 12:45 aa.ii
-rw-rw-r-- 1 dinesh dinesh 517 Feb 14 12:45 aa.s
-rw-rw-r-- 1 dinesh dinesh 1296 Feb 14 12:45 aa.o
-rwxrwxr-x 1 dinesh dinesh 8592 Feb 14 12:45 a.out
$size a.out
text data bss dec hex filename
1099 544 72 1715 6b3 a.out
$size aa.o
text data bss dec hex filename
67 0 40 107 6b aa.o
Now if I comment the object created on .bss section
#include <stdio.h>
//int bss_section_object[10];
int main()
{
return 0;
}
and check the size after compling it:-
$ls -ltr
-rw-rw-r-- 1 dinesh dinesh 79 Feb 14 12:46 aa.cpp
-rw-rw-r-- 1 dinesh dinesh 17256 Feb 14 12:46 aa.ii
-rw-rw-r-- 1 dinesh dinesh 378 Feb 14 12:46 aa.s
-rw-rw-r-- 1 dinesh dinesh 1232 Feb 14 12:46 aa.o
-rwxrwxr-x 1 dinesh dinesh 8552 Feb 14 12:46 a.out
$size a.out
text data bss dec hex filename
1099 544 8 1651 673 a.out
$size aa.o
text data bss dec hex filename
67 0 0 67 43 aa.o
I can see that their size varies based on "bss_section_object" size.
If I read the details of .bss section, then as per wikipedia:-
"The size that BSS will require at runtime is recorded in the object file,
but BSS (unlike the data segment) doesn't take up any actual space in the
object file".
We can see similar description of .bss section in other computer science
books as well.
Now, If the .bss section doesn't take up any space in object file, then why
is the size of object as well as executable file changing based on size of
object created on .bss section?
Can someone please explain the details about it?
You are perfectly right when saying :
"The size that BSS will require at runtime is recorded in the object file, but BSS (unlike the data segment) doesn't take up any actual space in the object file"
Because uninitialized data is placed in the .bss section of the program, which is of type SHT_NOBITS (see the elf(5) manpage).
To convince yourself that this section doesn't takes up any space in the ELF file, try readelf -Wl /bin/ls and look at the fourth segment :
[...]
LOAD 0x01a310 0x000000000061a310 0x000000000061a310 0x0012f0 0x002010 RW 0x200000
[...]
`03 .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss
You can see that it contains (among others), the .bss section, and has file size 0x12f0 but memory size 0x2010. The difference is the size of the .bss section.
This section is not included in the file because the associated memory region will be zeroed out at program startup, and it would be unnecessary to store zeros in the file.
You're right, but your test is wrong
In the example you give, given that you disable optimization and debugger symbols, the difference you see in file size may be explained by the symbol table, and not by the change of the .bss section size.
Here's an experiment you can reproduce :
you$ cat main.cpp
#include <stdio.h>
#ifdef USE_BSS
int bss_section_object[10];
#endif
int main()
{
return 0;
}
you$ g++ -O0 main.cpp -o without.elf
you$ g++ -DUSE_BSS -O0 main.cpp -o with.elf
you$ ls -l *.elf
-rwxr-xr-x. 1 you you 8505 Feb 14 10:00 with.elf
-rwxr-xr-x. 1 you you 8462 Feb 14 10:00 without.elf
At this point, you may believe that changing the .bss section size affects the file size, but in fact the difference is due to the additional symbol bss_section_object in the symbol table (which you can remove using the strip command) :
you$ readelf -WS with.elf > with && readelf -WS without.elf > without
you$ diff with without
30c30
< [25] .bss NOBITS 0000000000601040 00102c 000048 00 WA 0 0 32
---
> [25] .bss NOBITS 000000000060102c 00102c 000004 00 WA 0 0 4
33,34c33,34
< [28] .symtab SYMTAB 0000000000000000 0018e8 000618 18 29 45 8
< [29] .strtab STRTAB 0000000000000000 001f00 000239 00 0 0 1
---
> [28] .symtab SYMTAB 0000000000000000 0018e8 000600 18 29 45 8
> [29] .strtab STRTAB 0000000000000000 001ee8 000226 00 0 0 1
# Yep, the .symtab and .strtab are also different
you$ strip *.elf
you$ ls -l *.elf
-rwxr-xr-x. 1 you you 6232 Feb 14 10:06 with.elf
-rwxr-xr-x. 1 you you 6232 Feb 14 10:06 without.elf
Yay ! By removing the symbol table section .symtab (it its associated string table .strtab), you end up with the same file size, but different .bss section sizes, which is what you expected.
I'm trying to implement the method described here and here which override new and delete in a SWIG module in order to allocate memory on the Java heap instead of natively.
I added the SWIG prescription to my interface file. It compiles fine, and when I run my Java GUI, I can see from cout statements that it appears to be newing and deleteing without problems for a while (over 100k times). Eventually though, I always get this (same stack trace):
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fff8754c0e0, pid=61178, tid=81411
#
# JRE version: Java(TM) SE Runtime Environment (8.0_60-b27) (build 1.8.0_60-b27)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C [libsystem_platform.dylib+0x50e0] _platform_memmove$VARIANT$Haswell+0x1c0
Using my cout statements, it looks like the sample code is using the same addresses inside delete as it used in new, so the code itself appears to be working. There are no known memory issues with my code (I've analyzed it using AddressSanitizer and Valgrind), and furthermore, if I comment out only the cached_jvm = jvm; line (which results in the code using malloc/free instead of on the JVM heap), then it works ok. I'm not running out of heap memory -- for my testing I'm using small sample data.
If I switch the ReleaseByteArrayElements line to use mode JNI_ABORT instead of 0, then the free does not fail in the same place, but other problems occur afterwards which I didn’t bother to figure out.
Why is it segfaulting? Are there certain kinds of memory operations that are not compatible with this approach? I'm not using malloc/free (directly). I'm linking to a 3rd party library in C++, and they might be up to something.
Here's a sample compile line:
/usr/bin/clang++ -DEngine_EXPORTS -m64 -W -Wall -Wconversion -Wshadow -Wno-error=shadow -fdiagnostics-show-option -Wno-sign-conversion -stdlib=libc++ -ftemplate-depth=1000 -O3 -fno-omit-frame-pointer -ffast-math -funroll-loops -dynamic -fPIC -fno-common -fvisibility=hidden -fvisibility-inlines-hidden -Werror -Wno-error -fno-strict-aliasing -g -fPIC -I/third/party/include -I/my/include -I/System/Library/Frameworks/JavaVM.framework/Headers -o CMakeFiles/Engine.dir/engineJAVA_wrap.cxx.o -c engineJAVA_wrap.cxx
Stack trace:
Thread 59 Crashed:: Java: Thread-22
0 libsystem_kernel.dylib 0x00007fff902fbf06 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff98e704ec pthread_kill + 90
2 libsystem_c.dylib 0x00007fff95c736df abort + 129
3 libjvm.dylib 0x000000010a282beb os::abort(bool) + 25
4 libjvm.dylib 0x000000010a3a6a2a VMError::report_and_die() + 2304
5 libjvm.dylib 0x000000010a3a6d9b crash_handler(int, __siginfo*, void*) + 106
6 libsystem_platform.dylib 0x00007fff8754952a _sigtramp + 26
7 ??? 000000000000000000 0 + 0
8 libjvm.dylib 0x000000010a27d0b1 os::print_location(outputStream*, long, bool) + 917
9 libjvm.dylib 0x000000010a283d89 os::print_register_info(outputStream*, void*) + 83
10 libjvm.dylib 0x000000010a3a588c VMError::report(outputStream*) + 2142
11 libjvm.dylib 0x000000010a3a6522 VMError::report_and_die() + 1016
12 libjvm.dylib 0x000000010a284816 JVM_handle_bsd_signal + 1131
13 libjvm.dylib 0x000000010a280a7b signalHandler(int, __siginfo*, void*) + 47
14 libsystem_platform.dylib 0x00007fff8754952a _sigtramp + 26
15 ??? 0x0000000000000001 0 + 1
16 libjvm.dylib 0x000000010a11d830 jni_ReleaseByteArrayElements + 124
17 libengineEngine.jnilib 0x000000012750e41b JNIEnv_::ReleaseByteArrayElements(_jbyteArray*, signed char*, int) + 75 (jni.h:1689)
18 libengineEngine.jnilib 0x000000012750e1f8 operator delete(void*) + 408 (engineJAVA_wrap.cxx:298)
19 libengineEngine.jnilib 0x000000012750f710 Java_engineJNI_delete_1VectorMol + 80 (engineJAVA_wrap.cxx:586)
20 ??? 0x000000010ad9e954 0 + 4477020500
21 ??? 0x000000010ad90c4d 0 + 4476963917
22 ??? 0x000000010ad90c4d 0 + 4476963917
23 ??? 0x000000010ad90c92 0 + 4476963986
24 ??? 0x000000010ad90c4d 0 + 4476963917
25 ??? 0x000000010ad90c4d 0 + 4476963917
26 ??? 0x000000010ad90c4d 0 + 4476963917
27 ??? 0x000000010ad90c4d 0 + 4476963917
28 ??? 0x000000010ad909d0 0 + 4476963280
29 ??? 0x000000010ad90c92 0 + 4476963986
30 ??? 0x000000010ad897a7 0 + 4476934055
31 libjvm.dylib 0x000000010a0eab0e JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710
32 libjvm.dylib 0x000000010a0eb29c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 356
33 libjvm.dylib 0x000000010a0eb448 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74
34 libjvm.dylib 0x000000010a145965 thread_entry(JavaThread*, Thread*) + 124
35 libjvm.dylib 0x000000010a3612d3 JavaThread::thread_main_inner() + 155
36 libjvm.dylib 0x000000010a3629ce JavaThread::run() + 450
37 libjvm.dylib 0x000000010a28343a java_start(Thread*) + 246
38 libsystem_pthread.dylib 0x00007fff98e6d99d _pthread_body + 131
39 libsystem_pthread.dylib 0x00007fff98e6d91a _pthread_start + 168
40 libsystem_pthread.dylib 0x00007fff98e6b351 thread_start + 13
Edit:
I found that if I comment out all my .delete() calls (SWIG generated method) in my Java code, then I get a different error:
# SIGILL (0x4) at pc=0x00007fff95c7379f, pid=85146, tid=80651
#
# JRE version: Java(TM) SE Runtime Environment (8.0_60-b27) (build 1.8.0_60-b27)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C [libsystem_c.dylib+0x5e79f] __abort+0xb1
and SIGILL is a new one to me...