When we try to open a pdf file with a big image in it, we get an application crash. Before the crash the method AppDelegate.ReceiveMemoryWarning is being called.
The mupdf-library requires more space than the device can provide.
It is possible to limit the size library can use when processing a file?
(Using the variables max_store and FZ_STORE_DEFAULT does not help)
Related
I tried to add an icon to an app but it gives me an error every time I try
Although I added it to the required size, but I did not understand it
Is there a program like the iPhone that allows complete measurements and replaces the entire file?
picture for clarification
I have a question, after I have whole built the AOSP source code, it generates couple image files, such as ramdisk.img, recovery.img, system.img, res-package.img,etc .
Right now, I am considering partial flashing my Android Box without formatting all of the system, for keeping some previous data remains.
Therefore, I just tried to use the command “adb sideload filename.img”, which filename might be ramdisk,recovery, etc.
Then, after I did so, the android system shows the message :
“footer is wrong”
“signature verification failed”
“Installation aborted”
There, what should I correct my command, to make the process correct?
as the figure shows enter image description here
And, my methods to do so is trying to refresh a new system feature, but keep the previous data, such as APPs, or user data, remain, does anybody have other good suggestions? Thank you in advance.
it depends on the flash type and file-system you are using, and it is not possible to partially flash in the partition, but you can update the partition.
Is there an easy way of generating the memory dump for the crashed application?
I have a situation in which the customer received the code which is generating the crash, as the code itself has no signal handlers for the backtrace generation on abort I was wondering if there is an easy way of telling windows to generate the memory dump of the crashing application.
Ideal solution wouldn't involve the installation of the debug tools (or the code modification) but if this is not possible, it would be really helpful to know.
One simple way to dump memory when application crashes is by using windows taskmanager.
When ever an exception or an application error occurs windows pops up an memory dialog and shows the address location which was causing a crash.Before you click ok on the message box open Task Manger and right click on the crashed application and select Create Dump file.Take a look at the screen shot below.
Select the file
2)Another way of generating user mode dumps is by adding the following registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting >\LocalDumps\application.exe
application.exe should be replaced by the application name which is under scanner.
under this key following values can be added
DumpFolder
The path where the dump files are to be stored. If you do not use the default path, then make sure that the folder contains ACLs that allow the crashing process to write data to the folder.
For service crashes, the dump is written to service specific profile folders depending on the service account used. For example, the profile folder for System services is %WINDIR%\System32\Config\SystemProfile. For Network and Local Services, the folder is %WINDIR%\ServiceProfiles.
DumpCount
The maximum number of dump files in the folder. When the maximum value is exceeded, the oldest dump file in the folder will be replaced with the new dump file.
DumpType
Specify one of the following dump types:
0: Custom dump
1: Mini dump
2: Full dump
CustomDumpFlags
The custom dump options to be used. This value is used only when DumpType is set to 0.
The options are a bitwise combination of the MINIDUMP_TYPE enumeration values.
I have found the answer myself, the msdn specifies the debug registery in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error\LocalDumps
The following values need to be set:
DumpFolder
DumpCount
DumpType
CustomDumpFlags
The extensive documentation is available here.
If the registers do not exist it is possible to create them manually and windows will pick it up.
Also this is possible without directly modifying the registry with following steps:
Click Start, and then click Control Panel.
Double-click System, and then click Advanced system settings.
Click the Advanced tab, and then click Settings under Startup and Recovery.
In the Write debugging information list, click Small memory dump (64k).
How to change the default Firefox error console buffer size? The problem is that there isn't enough time to read messages: old ones get overridden by the newer messages.
I know this is an old one, but this came up as my top search and the setting can now be found in the about:config settings.
Type about:config into the address bar and select ok to the dragons.
type this into the filter
devtools.hud.loglimit.console
AMO :: DevPrefs
Can increase buffer size from the options panel of that addon:
(source: mozilla.net)
EDIT: There are two parts to this answer. The Console Service has one limit, which applies when the Error Console is closed. The Error Console has another limit, which applies when it is open. Normally these limits are both set to 250.
It is not useful to have the Console Service limit is higher than the Error Console limit, since you need to open the Error Console in order to view the errors, but in theory you can do this by debugging the Firefox executable and setting a breakpoint on xul!nsConsoleService::nsConsoleSerice and set mBufferSize to a larger value. Symbols to allow you to do this are available on the Mozilla symbol server.
You can increase the Error Console limit by editing the consoleBindings.xml file. This file is stored in one of the .jar files provided with Firefox (omni.jar in Firefox 4). Note that editing a .jar file will stop partial updates from working, instead the Firefox updater will reinstall the full updated version.
Is any possiblility to save some buffer in any binary file, to view in standalone hex editor.
For example, can I save data from memory window in VS to hex dump, but not as ASCII ?
user142207 has done a great job investigating VS internals, I recommend that solution.
I have another way that was invented by my colleague, Sergey S.,
which is very useful:
Windows:
Use a couple of functions ReadProcessMemory/WriteProcessMemory. It needs a standalone app that calls these functions with a target process id like:
dumper.exe <debugged process id> <memory_start_addr> <memory_length>
This app can be called directly during the VS debug session(compared to Linux, which doesn't have such a possibility). We can capture the memory address in the watch window, then pass the address to the dumper and voila. As user142207 says in his article, it's very useful in long-time recompiled projects.
Linux/MacOS has different approaches. For example: from the gdb console, use command dump memory. This command can also be used directly during the debug session.
StNickolay has the answer that references some tool called "dumper" but, somehow, I was unable to find it around the net (also, user142207 is long gone). So I created the very same tool - it opens up running process (even with a debugger attached) and copies portion of its memory into the file. Very useful when you want to store some structure for later and don't want to struggle with VS Memory View "copy" output. Enjoy!
https://github.com/Alexx999/Dumper
I don't know if this helps, but you can use WinDbg's .writemem command. It takes a filename and a memory range and dumps it (as binary) to the disk.
There is an extension for that: https://marketplace.visualstudio.com/items?itemName=OvidiuIonescu.VSDebugTool. It opens its console in VisualStudio window and allows dumping memory to file and a couple of other memory operation (enter "help" in the console for details).
Also, some hex editors (e.g. Hex Editor Neo) can browse process memory as an ordinary file. Maybe you'll find a free editor with this feature too.
The watch window in the Visual Studio debugger can run functions, if you are debugging your own code, you can just add some function to your code for saving a buffer to file and call it from the watch window.
for example:
void WriteToFile(char* name, void* buffer, size_t size)
{
FILE* fp;
fopen_s(&fp, name, "wb");
fwrite(buffer, 1, size, fp);
fclose(fp);
}
Then just type something like this in the watch window:
WriteToFile("c:\\temp\\dump.dat", buffer, len)
I suspect that you can get what you want from the ClrMD, you can then same the data however you want.
If you literally want a core dump then WinDbg might be what you're looking for?
There is also this post on MSDN Blogs: https://blogs.msdn.microsoft.com/dondu/2010/10/24/writing-minidumps-in-c/
It describes how to create dump-ish things in .NET programmatically.