I have a full memory dump of a process taken through Task Manager.
Can I determine what the time was on the machine at that moment?
It's displayed in the Command window of WinDbg after you open the dump, as 'Debug session time'.
You can have it printed again with the .time meta-command.
Related
When I started mongoDB client application Compass 1.13.1, I get the error like:
How I can solve it? Same issue was here.
Solution that worked for me:
Go to task manager
Kill the process called: "The MongoDB GUI"
Stuck?
open app -> get error -> no reboot ->
task manager -> "The MongoDB GUI" or "MongoDBCompassCommunity" -> kill process
Prevention?
Never quit the app using native close methods ("X" button / "Close window")
Always quit via Connect -> Quit (Ctrl+Q)
No need to disconnect first. It is just badly done electron app.
Answer based on solution from #Senne Verhaegen
Here's some additional ways how to solve:
From \AppData\Local\MongoDBCompass\app-1.13.1\resources delete the file named as app.asar, before it copy somewhere (in my case was desktop). Then paste file app.asar to this path again \AppData\Local\MongoDBCompass\app-1.13.1\resources and rerun Compass.
Restart Windows and try to run again Compass.
If nothing helps, reinstall the application (another version, for instance).
I got this error because I closed the app without disconnecting. I tried to start up the program and received the error. I waited about 30 seconds and then, surprise! Compass popped up and is running - even though the error showed. It must have cleaned itself up. I am using MongoDB Compass 4.0.3 Enterprise.
The problem is that the process "The MongoDB GUI" is still running after the application is closed.
Since I'm a very lazy person to open the Task Manager everytime this happens, I created a batch file with the following content:
#ECHO OFF
taskkill /f /im MongoDBCompass.exe
%LOCALAPPDATA%\MongoDBCompass\MongoDBCompass.exe
exit
I saved this file on the same directory of MongoDBCompass.exe, which can be easily found by checking the properties of your MongoDBCompass shortcut.
I overrided the Target to use that .bat instead of the default .exe and just said to it Run as administrator, never had problems again.
I recommend installing a recent version of Compass. This problem has been fixed in 1.17.
Solution that worked for me:
Go to task manager
Kill the process called: "Error". It will have a mongodb icon
Trying to do a DB2 import as part of a system copy and the transaction logs filled up. Import was cancelled, transaction log backup ran, and number of logs were increased to approximately 90% of the available disk (previously 70%).
Restarted DB and kicked off DB but now that errors due to the tablespace state - running db2 list tablespaces show detail shows I have 4 tablespaces in Backup Pending state.
So I tried db2 backup database <SID> tablespace <SID>#BTABI online but I get the error:
SQL2059W A device full warning was encountered on device "/db2/db2". Do you want to continue(c), terminate this device only(d), abort the utility(t) ? (c/d/t) t
No option works but to terminate.
The thing is, the device isn't full. There's no activities on the DB, running db2 list applications gives:
SQL1611W No data was returned by Database System Monitor.
Running db2 "select log_utilization_percent,dbpartitionnum from sysibmadm.log_utilization order by 2" to show the log utilization returns 0.
There's no logs in use. The filesystem has space free. I even tried reducing the number of logs again to make sure but get the same issue.
I tried db2 "alter tablespace <SID>#BTABI switch online" instead and although this returns a 'success' statement it doesn't actually do anything - my tablespaces are still in Backup pending?
Any ideas please
You're trying to write the backup images to the /db2/db2 file system, which doesn't have enough space to hold the backup image(s).
Note: When you execute BACKUP DATABASE as in your example above without specifying where to send the backup (i.e. you don't use the to /dir/ectory or another option like use TSM), DB2 will write the backup image to the current directory. Make sure you specify where to store the backup image (and that it has enough free space to hold the backup image). If you don't care about recoverability and are just trying to get the table space out of backup pending state, you can specify /dev/null as your location as #mustaccio suggests in the comments above.
Also: You may want to look at the COMMITCOUNT option for the import utility so you're not trying to insert all data in a single massive transaction.
As per above comments - just kept running the import, resetting the 'pending load' status each time with:
load from /dev/null of del terminate into SAPECD.
A few packages fail each time but the rest process. Letting finish, resetting again and restarting the import gets through a little more each time.
I created process memory dump using x64 task manager. For some reason when I execute !runway in debugger I get the following error: !runaway: extension exception 0x80004002.
"Unable to get thread times - dumps may not have time information"
The OS I'm running Windows 2008 R2 x64
Thank you for any assistance in this issue.
I assume you created a dump for a 32-bit process on a 64-bit OS. You need to use a special debugger extension to look at the 32-bit process as if you were using a 32-bit debugger. Enter the following command to load the debugger extension:
!load wow64exts
Enter the following command to tell the debugger extension to switch to x86 (32-bit) mode:
!sw
Now you should be set.
How to see the before image file size in progress DB server?
ls -l
Or, if you're running Windows:
DIR
Or you can get some info from VSTs (Virtual System Tables) like _Logging._Logging-BiLogSize.
The Virtual System Tables are your best bet when checking from within a Progress program.
If you're checking the BI size from the command prompt:
fire up ProMon on the database
Choose the option R&D
Choose option 1, Status displays
Choose option 9, BI Log
This will show you the size of all the bi logs for this database.
I've a memory issue in an iPhone app that I'd like to debug with MallocStackLogging. The error involves the gyroscope so I have to debug on the device not the simulator.
I've set the MallocStackLogging environment variable and the iPhone properly records the mallock stack logs:
MyApp(1856) malloc: recording malloc stacks to disk using standard recorder
MyApp(1856) malloc: stack logs being written into /private/var/mobile/Applications/1FD1F8D2-5D30-4AA7-B426-C52FE20266DE/tmp/stack-logs.1856.MyApp.index
MyApp(1856) malloc: Please issue: cp /private/var/mobile/Applications/1FD1F8D2-5D30-4AA7- B426-C52FE20266DE/tmp/stack-logs.1856.MyApp.e8z3IL.link /tmp/
Now how can I work with them?
I can transfer them to the Mac using the Xcode Organizer. But what should I do with these two files?
stack-logs.1856.MyApp.index
stack-logs.1856.MyApp.e8z3IL.link
I tried moving the files in /tmp on the Mac and called:
$ malloc_history 1856 -all_events
malloc_history cannot examine process 1856 because the process does not exist.
Clearly, the malloc_history command looks for running processes on the local machine. I'm missing an option to specify the log file manually.
Is there any way to get this to work either directly working with Xcode on the (non-jailbroken) device or after transferring the logs to the Mac?
Here is how I debug APP with malloc stack history on idevice, it's really complicate, but I have no other way to deal with an auto release pool memory problem.
You need A jailbreak idevice with developer tools installed, then you have gdb.
To enable malloc stack loggin, you need set environment variables MallocStackLoggingNoCompact and MallocStackLogging, we need some trick to do it.
First, we need grant your app root privilege.
mv -f /User/Application/xxxxxxxxxxxxx/YOUR_APP.app /Application/YOUR_APP.app
cd /Application
chown -R root:wheel YOUR_APP.app
chmod 4755 YOUR_APP.app/YOUR_APP
Rename your program
mv YOUR_APP.app/YOUR_APP YOUR_APP.app/BACK_UP_NAME
Use a short shell scrip to start your program, so we can keep the env. Save it to YOUR_APP.app/YOUR_APP
#!/bin/bash
export MallocStackLogging=1
export MallocStackLoggingNoCompact=1
exec /Applications/YOUR_APP.app/BACK_UP_NAME
Done.
Just start you app, touching on the icon or use open command, you'll see a stack log file in /tmp
directory.
Use ps aux | grep YOUR_APP find process id, gdb -p PROCESS_ID attach to the progress, make a breakpoint, try info malloc ADDRESS, malloc history will show up.
In the Instruments application, which can diagnose an app running in the simulator or on a device, the Allocations instrument records memory addresses and allocation histories. You can browse by object/allocation type or specific memory address. This is likely the most straightforward way to accomplish what you want.
Running malloc_history on the device would require either jailbreaking to enable an ssh connection to the device, or running malloc_history from within your code. But I am not certain whether malloc_history exists on an iOS device. And malloc_history's help text does not mention an option for operating on log files rather than an existing process, which you likely already know.
I don't mean to sound flippant, but have you tried plugging the device in and running it under the debugger whilst connected ?
I do extensive debugging whilst runnning the application on the device. You do need to start the application under the debugger.