I managed to install FastMM4 under C++ Builder 2010 but the log file generated is filled with memory dumps or with statements like
The block is currently used for an object of class: Unknown
Last statement in log is:
5 - 12 bytes: TObject x 1 <------- this is mine! I created this leak intentionally!
13 - 20 bytes: Unknown x 8
53 - 68 bytes: std::locale::_Locimp x 1
181 - 212 bytes: Unknown x 1
I added to my project:
FastMM4.pas
FastMM4Messages.pas
FastMM4Options.inc
The Full Debug Mode (and several other features) were enabled manually in the inc file. The FastMM_FullDebugMode.dll is present in my project's folder.
I use USEOBJ("FastMM4BCB.cpp") in my project file (above 'useform') and I disabled the DynamicRTL (linker) in Project Options.
How to get decent info like stack trace?
Related
Sometimes when I run this command npx hardhat compile on my windows cli I get the error below:
Compiling 72 files with 0.7.0
contracts/libraries/ERC20.sol: Warning: SPDX license identifier not provided in source file. Before publishing, consider adding a comment containing "SPDX-License-Identifier: <SPDX-License>" to each source file. Use "SPDX-License-Identifier: UNLICENSED" for non-open-source code.
Please see https://spdx.org for more information.
contracts/libraries/ERC1155/EnumerableSet.sol:158:5: Warning: Variable is shadowed in inline assembly by an instruction of the same name
function add(Bytes32Set storage set, bytes32 value) internal returns (bool) {
^ (Relevant source part starts here and spans across multiple lines).
contracts/libraries/ERC1155/EnumerableSet.sol:224:5: Warning: Variable is shadowed in inline assembly by an instruction of the same name
function add(AddressSet storage set, address value) internal returns (bool) {
^ (Relevant source part starts here and spans across multiple lines).
Compiling 1 file with 0.8.0
<--- Last few GCs --->
[8432:042B0460] 263058 ms: Mark-sweep (reduce) 349.8 (356.3) -> 248.2 (262.4) MB, 434.4 / 0.2 ms (+ 70.9 ms in 3 steps since start of marking, biggest step 69.6 ms, walltime since start of marking 800 ms) (average mu = 0.989, current mu = 0.990) memory[8432:042B0460] 263627
ms: Mark-sweep (reduce) 248.2 (259.4) -> 248.2 (252.1) MB, 555.5 / 0.0 ms (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 556 ms) (average mu = 0.969, current
mu = 0.023) memory p
<--- JS stacktrace --->
FATAL ERROR: NewNativeModule Allocation failed - process out of memory`
After some time the error just kind of goes away.
It goes away probably after I've restarted my system or created a new Hardhat project and imported the code there.
But this is happening too often, what could be the cause?
I've done quite some research and some answers suggested it might be a problem with Node and the application's memory allocation, but I don't know how I would apply the solutions to a Hardhat project.
Here is a link to one possible solution: https://medium.com/#vuongtran/how-to-solve-process-out-of-memory-in-node-js-5f0de8f8464c
OS: WINDOWS 10
CLI: WINDOWS CMD
I tried to use pynsist to make a windows installer for git-cola from my Ubuntu 15.10 desktop.
I just git clone git-cola project and setup the installer according to the instruction.
Seems OK for pynsist pynsist.cfg.
Here is snippet at the end:
Output: "/home/wni/gitworkspace/git-cola/build/nsis/git-cola_2.7.exe"
Install: 6 pages (384 bytes), 4 sections (1 required) (4192 bytes), 903 instructions (25284 bytes), 609 strings (9986 bytes), 1 language table (334 bytes).
Uninstall: 2 pages (128 bytes),
1 section (1048 bytes), 11 instructions (308 bytes), 57 strings (896 bytes), 1 language table (194 bytes).
Datablock optimizer saved 38103 bytes (~0.0%).
Using lzma compression.
EXE header size: 88064 / 73216 bytes
Install code: 7522 / 40556 bytes
Install data: 39171671 / 87321329 bytes
Uninstall code+data: 9216 / 14775 bytes
CRC (0xCB9A7C26): 4 / 4 bytes
Total size: 39276477 / 87449880 bytes (44.9%)
Installer written to build/nsis/git-cola_2.7.exe
And, here is pynsist.cfg just as default:
[Application]
name=git-cola
version=2.7
entry_point=cola.main:shortcut_launch
icon=share/git-cola/icons/git-cola.ico
[Python]
version=2.7.10
bitness=32
[Include]
packages=cola
PyQt4
qtpy
sip
files = share/
Then, I copy build/nsis to one WIN7 32 bit desktop, and run git-cola_2.7.exe to open the installer.
Everything seems OK till the end indicating git-cola is successfully installed upon the machine.
However, I see there is no icon on the desktop(maybe something wrong yet), then, I route to the installation folder and double click "git-cola.launch.pyw", but no response...
Here is the folder content for git-cola:
Here is folder for pkgs:
I see .dll or .exe files are there under each sub folder then.
updated:
I see in the pynsist log that : qtpy.PythonQtError: No Qt bindings could be found
So, seems pynsist didn't add python to PATH and pkgs folder under installation to PYTHONPATH.
Then, I add python executable to PATH and pkgs to PYTHONPATH, after that, issue still there.
It's successful for me to import PyQt4 within python interpreter.
However, failed to import Qt from PyQt4...
Here is content for pkgs/PyQt4:
So, where is wrong with my setup, is there anything wrong with any configuration?
Thanks.
Wesley
I'm updating the driver of one of my devices and would like to kextunload the old driver and kextload the new one so a restart isn't required anymore.
After the installation I try:
sudo kextunload /System/Library/Extensions/Driver.kext
The error which happens looks like this:
(kernel) Can't unload kext com.driver.Driver; classes have instances:
(kernel) Kext com.driver.Driver class com_driver_Driver_USBAudioDevice has 1 instance.
Failed to unload com.driver.Driver - (libkern/kext) kext is in use or retained (cannot unload).
The device is not present in ioreg.
How can I find out what this instance is which prevents me from unloading the driver?
If you call the command kextstat, it will display a list of all the loaded kernel extensions with info like this one:-
115 3 0xffffff7f814f4000 0x32000 0x32000 com.apple.iokit.IOAudioFamily (1.8.9fc11) <114 5 4 3 1>
The first number (115) is the id of the kernel extension.
At the end, the set of numbers <114 5 4 3 1> are the other kernel extension ids that are being referenced by this particular kext.
If you match the id of your kext to any of those listed in another, then that is a reference that kextunload is referring to.
Also note that when writing any code in the kernel, globals variables are global across the whole kernel, so if you've declared any that may not have a unique name and is used by another kext, I have found this to cause a similar issue. The solution here is to prepend any globals with a reverse company URI (e.g. com_apple_globalVarName).
The accepted answer is incorrect. The trailing numbers at the end of output from kextstat are NOT a listing of the kexts dependent on this one.
They ARE a list of the kexts that this kext is dependent upon.
Using the same example kext as the other answer, com.apple.iokit.IOAudioFamily, I show the following:
~ root# kmutil showloaded -b com.apple.iokit.IOAudioFamily
No variant specified, falling back to release
Index Refs Address Size Wired Name (Version) UUID <Linked Against>
152 3 0xffffff7f9922c000 0x1e000 0x1e000 com.apple.iokit.IOAudioFamily (340.2) 2BC68A45-C1C1-30D1-A7A2-B911CFDB04F2 <151 7 6 3 1>
(Note: I am using kmutil showloaded instead of kextstat as the later is deprecated.)
Breaking this output down we see:
A Refs count of 3 indicates that 3 other kexts "refer" (or link against) this kext.
The <Linked Against> list indicates the Index of other kexts that this kext is dependent upon.
To specifically answer your question, you need to find the other kexts that have your kext's Index listed in their <Linked Against> listing.
Continuing our example with the com.apple.iokit.IOAudioFamily kext we can look at all loaded kexts and search for any referencing index 152 by running: kmutil showloaded | grep '<.*152.*>'
~ root# kmutil showloaded | grep '<.*152.*>'
No variant specified, falling back to release
153 0 0xffffff7f99023000 0x52000 0x52000 com.apple.driver.AppleUSBAudio (416.2) D9A996CC-8118-3E85-B019-F756AC2A4689 <152 150 114 24 23 16 8 7 6 3 1>
190 0 0xffffff7f97a97000 0x5f000 0x5f000 com.apple.driver.AppleGFXHDA (140.3) EED41AF8-3465-37CC-AB65-DB85BD71B595 <152 144 134 16 9 8 7 6 3 1>
219 0 0xffffff7f990ad000 0x3000 0x3000 com.apple.driver.AudioAUUC (1.70) 5C4939F8-12C1-39BF-AD87-8456A450BCF7 <152 134 16 15 9 7 6 3 1>
As you can see, the three kexts that reference (or are Linked Against) com.apple.iokit.IOAudioFamily are:
com.apple.driver.AppleUSBAudio
com.apple.driver.AppleGFXHDA
com.apple.driver.AudioAUUC
You would need to unload these three kexts (and any kexts that they are referenced by in turn) before you could unload the original.
I was trying to use OpenCover (downloaded today) to get coverage of my tests. Here is the command line I've used :
OpenCover.Console.exe -target:"c:\Programmes2\xunit\xunit.console.clr4.x86.exe" -targetargs:"""C:\Sources\Project\BackOffice.Tests\bin\Debug\BackOffice.Tests.dll"" /noshadow " -output:bo.coverage.xml -targetdir:"C:\Sources\Project\BackOffice.Tests\bin\Debug" -filter:+[*]*
And here is the output I get
xUnit.net console test runner (32-bit .NET 4.0.30319.269)
Copyright (C) 2007-11 Microsoft Corporation.
xunit.dll: Version 1.9.0.1566
Test assembly: C:\Sources\Project\BackOffice.Tests\bin\Debug\BackOffice.Tests.dll
31 total, 0 failed, 0 skipped, took 2.760 seconds
Committing...
No results - no assemblies that matched the supplied filter were instrumented
this could be due to missing PDBs for the assemblies that match the filter
please review the output file and refer to the Usage guide (Usage.rtf)
The generated report is always the same:
<?xml version="1.0" encoding="utf-8"?>
<CoverageSession xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Modules />
</CoverageSession>
A bit more context : The PDB's are present in the target folder, I'm running the Command prompt as an administrator. The project tested is an .net 4/mvc 3 application. My computer is running windows 7/32bits. On that topic, not sure if that's relevant in any way, but the x86 folder in the is empty, even if I force the target plateform to be x86.
Also, when I try to register the OpenCover.Profiler.dll with regsvr32, I get an error that says that the dll may not be compatible with my windows version.
If I try to user the -register or the -register:user parameters, I get an exception:
An exception occured: Failed to register(user:True,register:True,is64:False):3 the profiler assembly; you may want to look into permissions or using the -register:user option instead. C:\Windows\system32\regsvr32.exe /s /n /i:user "C:\Sources\Opencover\sawilde-opencover-be6e491\main\bin\Debug\x86\OpenCover.Profiler.dll"
stack:
à OpenCover.Framework.ProfilerRegistration.ExecuteRegsvr32(Boolean userRegistration, Boolean register, Boolean is64) dans C:\Sources\Opencover\sawilde-opencover-be6e491\main\OpenCover.Framework\ProfilerRegistration.cs:ligne 59
à OpenCover.Framework.ProfilerRegistration.ExecuteRegsvr32(Boolean userRegistration, Boolean register) dans C:\Sources\Opencover\sawilde-opencover-be6e491\main\OpenCover.Framework\ProfilerRegistration.cs:ligne 45
à OpenCover.Framework.ProfilerRegistration.Register(Boolean userRegistration) dans C:\Sources\Opencover\sawilde-opencover-be6e491\main\OpenCover.Framework\ProfilerRegistration.cs:ligne 31
à OpenCover.Console.Program.Main(String[] args) dans C:\Sources\Opencover\sawilde-opencover-be6e491\main\OpenCover.Console\Program.cs:ligne 82
I also tried with a DLL project (.net4) tested by a different project (xunit also), with the same (lack of) result.
Any help appreciated !
Downloading the release package solved the exception from the register parameter. But running the same command line generated multiple errors of this kind:
BackOffice.Tests.HomeControllerShould.Redirect_To_Action_Feed_Index [FAIL]
System.MissingMethodException : Méthode introuvable : 'Void System.CannotUnloadAppDomainException.SafeVisited(Int32)'.
Stack Trace:
à BackOffice.Tests.HomeControllerShould..ctor()
with this result:
31 total, 31 failed, 0 skipped, took 0.241 seconds
Committing...
Visited Classes 0 of 44 (0)
Visited Methods 0 of 183 (0)
Visited Points 0 of 1352 (0)
Visited Branches 0 of 322 (0)
==== Alternative Results (includes all methods including those without corresponding source) ====
Alternative Visited Classes 0 of 53 (0)
Alternative Visited Methods 0 of 268 (0)
After looking around for similar issues, I found this issue on github and tried the -oldStyle parameter. It solved mine.
#Shaun Wilde, if by any chance you see this question again, could you tell us if it's the recommended way to solve it and if we lose something from using it against the "normal" way (I would also suggest adding this parameter to the documentation page
For iOS crash reports, it is sufficient to drag and drop the crash report to the Organizer.
Symbolicating iPhone App Crash Reports
But this method doesn't work for Mac OSX crash reports.
How can I symbolicate my Mac OSX crash report ?
Thanks !!
You can use the atos command to get the line number where the app crashed.
Heres a quick guide:
Create a directory for your working files
Open Xcode, select Window->Organizer, goto the Archive tab and find the version of your app that experienced the crash.
Right click on the app archive and select "Show in Finder"
Right click on the .xarchive, select "Show Contents" and find the AppName.dSYM directory and the app and copy them to your working folder
Copy the stack trace to your working folder
Open terminal and change to your working folder. An ls should show YourApp.app YourApp.app.dSYM stacktrace.txt
Open your stack trace in TextEdit. Your going to need to find the Code Type from the header (system architecture - eg. X86-64) and the addresses of the crash. Search through the threads to find the one that crashed (it will say something like "Thread 2 Crashed") then find your objects. You need the two addresses (hex numbers) from that line to get the code line.
Once you've got all the information you need to run the following in the terminal:
atos -o YourApp.app/Contents/MacOS/YourApp -arch x86_64 -l [load-address] [address]
For example, heres an extract from a stacktrace:
Process: MyApp [228]
Path: /Applications/MyApp.app/Contents/MacOS/MyApp
Identifier: uk.co.company.app
Version: 1.0 (1)
App Item ID: 774943227
App External ID: 218062633
Code Type: X86-64 (Native)
Parent Process: launchd [154]
Responsible: MyApp [228]
User ID: 501
Date/Time: 2013-12-17 10:20:45.816 +0100
OS Version: Mac OS X 10.9 (13A603)
Report Version: 11
Anonymous UUID: 7AA662B1-7696-A2C5-AF56-9D4BA2CE9515
Crashed Thread: 2
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
<snip>
Thread 2 Crashed:
0 libsystem_kernel.dylib 0x00007fff8b95a866 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff8bf4f35c pthread_kill + 92
2 libsystem_c.dylib 0x00007fff87571bba abort + 125
3 libsystem_malloc.dylib 0x00007fff897ae093 free + 411
4 uk.co.company.app 0x0000000103580606 0x10356e000 + 75270
5 uk.co.company.app 0x00000001035803da 0x10356e000 + 74714
6 com.apple.Foundation 0x00007fff8d00970b __NSThread__main__ + 1318
7 libsystem_pthread.dylib 0x00007fff8bf4e899 _pthread_body + 138
8 libsystem_pthread.dylib 0x00007fff8bf4e72a _pthread_start + 137
9 libsystem_pthread.dylib 0x00007fff8bf52fc9 thread_start + 13
I can see that the "Code Type" is x86_64, that Thread 2 crashed, and that on line 4 my code was running so we have the addresses we need. Using this information I run the following:
$ atos -o MyApp.app/Contents/MacOS/MyApp -arch x86_64 -l 0x10356e000 0x0000000103580606
This returns:
got symbolicator for MyApp.app/Contents/MacOS/MyApp, base address 100000000
obj_free (in MyApp) (somefile.c:135)
Telling me my app crashed at line 135 of somefile.c
#inkjet 's comment above deserves its own answer.
He built an app that does a full symbolication from your dsym and .crash file.
A free alternative to Sumbolon that I made: bch.us.to/apps/macsymbolicator — It uses atos in the same way described by Rich Able below. – inket Dec 24 '13 at 4:39
putting it all together:
download Mac Symbolicator from here
Open Xcode, select Window->Organizer, goto the Archive tab and find
the version of your app that experienced the crash.
Right click on the app archive and select "Show in Finder"
Right click on the .xarchive, select "Show Contents" and find the
AppName.dSYM directory
Drag your .crash file and AppName.dsym to Sumbolon
Magic happens
this link
this link explains everything to symbolicate the crash log with the line no of crash. you just need to have .dsyms file, .app file and crash log in same folder
i looked around and find nothing better than this. so i am posting it by hoping this will help others.