I am attempting to debug a crash dump from my VB.NET code which is supposed to run 24-7 a Win7 machine which does not have a debugger. The target on all modules is 32-bit, so I don't know why it appears that it is attempting the 64-bit stuff.
It appears that it is trying to attach to a debugger and failing, so it aborts.
I log into the machine and find that it has crashed again, so I make a crashdump.DMP file which stops on the following trace:
wow64.dll!Wow64NotifyDebugger() + 0x1d bytes
wow64.dll!HandleRaiseException() + 0xee bytes
wow64.dll!Wow64NtRaiseException() + 0x88 bytes
wow64.dll!whNtRaiseException() + 0x15 bytes
wow64.dll!Wow64SystemServiceEx() + 0xd7 bytes
wow64cpu.dll!TurboDispatchJumpAddressEnd() + 0x2d bytes
wow64.dll!RunCpuSimulation() + 0xa bytes
wow64.dll!Wow64LdrpInitialize() + 0x429 bytes
ntdll.dll!LdrpInitializeProcess() + 0x1936 bytes
ntdll.dll!string "Enabling heap debug options\n"() - 0x45fe9 bytes
ntdll.dll!LdrInitializeThunk() + 0xe bytes
The same code does not crash at all when a debugger is attached remotely or locally.
Can anyone tell me what to look for? I have compiled the executable as a Debug x86 build so I can attach a debugger at will and view the Debug.Writeline() call output.
On a 64 bit system, '32 bit windows' runs on an emulation layer, called wow64 (which you see) which translates the calls from 32 bits to 64 bits. So that's normal.
I did not fully understand from your question though: is the crash unexpected/somehow caused by a debugger?
This is perfectly normal. "WOW64" is the name for the 32-bit on 64-bit compatibility system in Windows, and is involved when you run 32-bit code on a 64-bit Windows system.
Related
I compile a macOS driverkit system extension as a Universal library so that it contains both x86_64 and arm64. One Apple Silicon computer A the driver starts when I attach the USB device. On Apple Silicon computer B I can see kernel: exec_mach_imgact: disallowing arm64 platform driverkit binary "com.example.driver", should be arm64e being printed in the Console.app when the USB device is attached. I've looked at the source code
of where this is happening but I cannot figure out what the problem is.
If I compile it for arm64e then it get exec_mach_imgact: not running binary "com.example.driver" built against preview arm64e on computer A, bit then it starts on computer B.
None of the computers have -arm64e_preview_abi set in the boot-args.
If I create a new Xcode (12.4) project on each machine and build Release then computer A and otool -fvv com.example.driver gives
Fat headers
fat_magic FAT_MAGIC
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0
offset 16384
size 73856
align 2^14 (16384)
architecture arm64
cputype CPU_TYPE_ARM64
cpusubtype CPU_SUBTYPE_ARM64_ALL
capabilities 0x0
offset 98304
size 73856
align 2^14 (16384)
On computer B the same command gives
Fat headers
fat_magic FAT_MAGIC
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0
offset 16384
size 73280
align 2^14 (16384)
architecture arm64
cputype CPU_TYPE_ARM64
cpusubtype CPU_SUBTYPE_ARM64_ALL
capabilities 0x0
offset 98304
size 73296
align 2^14 (16384)
How can I make the driver start on both machines?
Dexts should indeed be arm64 and x86_64 (but as pmdj explains, system binaries are still arm64e.)
As hinted by the name of (and need for) the -arm64e_preview_abi, arm64e is currently only exposed as a developer preview, to allow for testing.
However, you shouldn't get the disallowing arm64 error: did you set other interesting boot-args on computer B? (in particular, amfi= may be relevant)
My experience so far indicates that arm64e is the correct and only correct Apple Silicon architecture to use for dexts.
For one, there's the "disallowing arm64 platform" error, and also Apple's own DriverKit based drivers are built for arm64e:
% otool -fvv /System/Library/DriverExtensions/com.apple.AppleUserHIDDrivers.dext/com.apple.AppleUserHIDDrivers
Fat headers
fat_magic FAT_MAGIC
nfat_arch 2
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
capabilities 0x0
offset 16384
size 96208
align 2^14 (16384)
architecture arm64e
cputype CPU_TYPE_ARM64
cpusubtype CPU_SUBTYPE_ARM64E
capabilities CPU_SUBTYPE_ARM64E_PTRAUTH_VERSION 0
offset 114688
size 95312
align 2^14 (16384)
That leaves the question of why your arm64e build isn't working. The "built against preview arm64e" error suggests the problem isn't with the computer but the binary. Are you using identical binaries on the 2 systems? Perhaps one has SIP disabled, so it's more permissive of badly built binaries?
Have you tried a "hello world" style dext, in a freshly created project on the latest version of Xcode? Check that runs natively on both machines. Once that's working, compare Xcode's compiler and linker command lines with those from your build script - or if you're also using Xcode, compare your target's build settings with the "clean" one.
I'm using GraphDb Free 8.6.1 in research project, I'm running it with default configuration on linux server having 4GB memory in total.
Currently, we execute quite many CRUD operations in tripplestore.
GraphDB throwed exception in console:
java.lang.OutOfMemoryError: Java heap space
-XX:OnOutOfMemoryError="kill -9 %p"
Executing /bin/sh -c "kill -9 1411"...
Looking into process, GraphDB runs with parameter XX:MaxDirectMemorySize=128G
I was not able to changed, even with ./graph -Xmx3g, process is still running with XX:MaxDirectMemorySize=128G.
I've tried to configure ./grapdh parameter, setting the GDB_HEAP_SIZE=3072m, now process runs with additional -Xms3072m -Xmx3072m parameters, but remains XX:MaxDirectMemorySize=128G.
After update to GDB_HEAP_SIZE=3072m, repository went down again without .hprof file, no exception, nothing suspicious in logs. The following line was flushed into console: Java HotSpot(TM) 64-Bit Server VM warning:
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00007f5b4b6d0000, 65536, 1) failed; error='Cannot allocate memory' (errno=12)
Please, can you help me to properly configure GraphDB tripplestore to get rid of the Heap Space exceptions?
Thank you.
By default, the value of the -XX:MaxDirectMemorySize (off heap memory) parameter in the JVM is equal to the -XMx (on heap memory). For very large repositories the size of the off heap memory may become insufficient so the GraphDB developers made this parameter 128GB or unlimited.
I suspect that your actual issue is actually allocating too much on heap memory, which leaves no space for the off heap in the RAM. When the database tries to allocate off heap RAM you hit this low OS-level error 'Cannot allocate memory'.
You have two options in solving this problem:
Increase the RAM of the server to 8GB and keep the same configuration - this would allow the 8 GB RAM to be distributed: 2GB (OS) + 3GB (on heap) + 3GB (off heap)
Decrease the -Xmx value to 2GB so the 4GB RAM will be distributed: 1GB (OS) + 2GB (on heap) + 1GB (off heap)
To get a good approximation how much RAM GraphDB needs please check the hardware sizing page:
http://graphdb.ontotext.com/documentation/8.6/free/requirements.html
i try to star rockerMQ broker,but i got the error message:
There is insufficient memory for the Java Runtime Environment to continue.
Native memory allocation (mmap) failed to map 8589934592 bytes for committing reserved memory.
An error report file with more information is saved as:
/usr/local/soft/rocketMQ/incubator-rocketmq/distribution/target/apache-rocketmq/hs_err_pid6034.log
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00000005c0000000, 8589934592, 0) failed; error='Cannot allocate memory' (errno=12)
and i got something from the error log file about message of memory:
Memory: 4k page, physical 4089840k(551832k free), swap 2621432k(2621432k free)
vm_info: Java HotSpot(TM) 64-Bit Server VM (25.144-b01) for linux-amd64 JRE (1.8.0_144-b01), built on Jul 21 2017 21:57:33 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)
how can i let the rockerMQ broker working for me
You can reduce the JVM heap size.
Open the distribution/bin/runbroker.sh file of your project and change the following line
JAVA_OPT="${JAVA_OPT} -server -Xms8g -Xmx8g -Xmn4g"
as
JAVA_OPT="${JAVA_OPT} -server -Xms4g -Xmx4g -Xmn2g"
now broker will only generate a 4G heap .I hope it will solve your problem.Now you can try to build and run.
Try modifying the start shell scripts to make a smaller JVM heap size in your dev/test env
I am down the rabbit hole on TNS-12560.
I am working on a windows 7 computer. I have X86 & X64 versions of Oracle clients installed. The DB(s) are on remote computers. I can use TNSPING, SQLPLUS, SQLDEVELOPER to get to the DBs using the various TNSNAMES.ORA files and have no problems.
I am working on an X86 VB.NET program using VS2008 (also tried a different program using VS2010 with similar results). I am using Oracle.DataAccess.dll X86 in my project. The configuration in VS2008 is X86, I have changed my path on the system to have the X86 oracle path first.
When I run TNSPING it points to the X86 path's SQLNET.ORA. When I try to login to the DB I get the following in my SQLNET.LOG file;
TNS-12560: Message 12560 not found; No message file for product=NETWORK, facility=TNS
ns secondary err code: 0
nt main err code: 530
TNS-00530: Message 530 not found; No message file for product=NETWORK, facility=TNS
nt secondary err code: 38
nt OS err code: 0
I turned on tracing and in the trace file I notice that it references one of the other (X64) client home folders;
2017-01-11 13:25:36.744480 : Attempted load of system pfile source C:\app\paul\product\11.2.0\client_2\network\admin\sqlnet.ora
2017-01-11 13:25:36.744535 : Parameter source loaded successfully
Where TNSPING uses the x86 folder;
C:\>tnsping XXXX
TNS Ping Utility for 32-bit Windows: Version 11.2.0.1.0 - Production on 11-JAN-2
017 12:59:33
Copyright (c) 1997, 2010, Oracle. All rights reserved.
Used parameter files:
C:\app\paul\product\11.2.0\client_x86\network\admin\sqlnet.ora
This leads me to believe that it is trying to mix X86 & X64 components, but I do not know what controls where it looks for the path.
The only other bit of error stuff from the trace that I do not know how to interpret is;
2017-01-11 13:25:36.760176 : nserror:nsres: id=0, op=65, ns=12560, ns2=0; nt[0]=530, nt[1]=38, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
2017-01-11 13:25:36.760189 : nsopen:unable to open transport
So, I am down the rabbit hole, and need some help in finding a map to get out. Anyone with pointers, will be rewarded "bigly" (to coin a phrase).
I want to increase the heap size of my Glassfish. For that, I know that I can go up to 4GB:
java -Xmx4000M -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
I tried to set in domain.xml file the -Xmx to 2GB:
<jvm-options>-Xmx2000m</jvm-options>
But I am getting the following error:
asadmin> start-domain
Waiting for ... to start .Error starting domain ...
The server exited prematurely with exit code 1.
Before it died, it produced the following output:
Error occurred during initialization of VM
The size of the object heap + VM data exceeds the maximum representable size
launchctl bsexec failed: Inappropriate ioctl for device
Launching the command with -v option gives this:
12 oct. 2011 11:46:34 com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: JVM invocation command line:
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java
-XX:+UnlockDiagnosticVMOptions
-XX:MaxPermSize=512m
-XX:NewRatio=2
-XX:+CMSClassUnloadingEnabled
-Xmx2000m
-Xms1000m
...
12 oct. 2011 11:46:35 com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: Successfully launched in 45 msec.
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
Command start-domain failed.
I found the problem. For some reasons which I do not understand, the "-d32" argument was passed in the command, asking to start in 32 bits mode. When adding
<jvm-options>-d64</jvm-options>
to the domain.xml file, glassfish starts. Please note that this option is not present by default in the file.
you must be using a different Java install when doing the "-version" and from within GlassFish. I can reproduce the same error with the default "java" in Mac OS' path but not when using an absolute path :
% /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java -Xmx2300m -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-383-11A511)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode)
% java -Xmx2300m -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
Could it be that you don't have enough disk space on your system? Reserving 4GB of RAM may require MAC OS to expand swap space, and you may not have the disk space to do this. Unfortunately, this has burned me before :-/