I'm running the Mac OS "Instruments" app, using the "Leaks Instrument" to monitor an
iPhone app. The major pane is titled "Leaked Blocks", but if you click on that you
get a choice of three: "Leaked Blocks", "Call Tree", and "Console". Click on "Console".
You now have a blank pane ... click in it and hit .
In my case, I get:
foo (4259) >
which is my app name and, presumably, the PID it's running as.
I can enter commands/text (e.g., ls, help, exit) ... they get echoed after awhile but
nothing else happens.
I.e., it looks like a command prompt, but I can't figure out what kinds of commands
I can give it here! Doesn't seem to accept gdb commands, nor "help". Can't find a
mention of this feature in Apple's documents.
Note that if I select a different instrument, e.g. "Allocations", it also has the
same console pane ... with the same "no effect" when I enter text.
I'm hoping that whatever commands it has are (a) interesting, and (b) useful to me
in debugging a memory leak.
thanks,
Stan
sieler#me.com
Isn't this a console window that lets you see messages printed to the console (NSLog and alike), just like Xcode's one? In Xcode too you can write in that console, to no extent...
indeed the Instruments User Guide states:
Options
Use this menu to specify other runtime options. For example, you can direct the application’s output to the Instruments console or the system console, or discard the output. You can also specify whether the application is launched in 32-bit or 64-bit mode.
did not try it, though...
Related
This is what I am doing:
Make a file or use an existing file.
Emacs filename.txt.
Type some new text into the file.
Save file.
After step 2, I receive an error after the emacs editor window pops up.
Here is the error:
2022-01-19 22:11:53.935 Emacs-x86_64-10_14[33893:994906] It's not
legal to call -layoutSubtreeIfNeeded on a view which is already being
laid out. If you are implementing the view's -layout method, you can
call -[super layout] instead. Break on void
_NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future.
I have already tried updating emacs and that didn't help, and googling didn't give me an answer. Currently, I have GNU Emacs 27.1 version.
How do I fix this error?
As far as I know you shouldn't need to "fix" the error at all and it won't cause any problems while you're actually running Emacs. In fact I'm somewhat surprised you see it at all.
I was only able to see the error (in both Emacs 27 and in pretest-28.0.90) only by running the Emacs binary (eg. ./Emacs-27.app/Contents/MacOS/Emacs) directly from a terminal, which isn't the normal way of starting Emacs on macOS. If you just run Emacs by starting it from Finder, the Dock, or via the "open" utility then you shouldn't see the error at all, and it shouldn't cause any problems.
The whole point of keyboard interaction (and emacs in particular) is that there's no need to touch the mouse. It's possible to log in (using e.g. ssh) and edit remotely, with no gui (so no way to drag and drop), and this is the 'normal' way of invoking emacs. Run 'emacs --help' from the command line to see a bunch of options. In particular see 'emacs --no-window-system' which uses a raw terminal even when a gui is available (no error message appears when it's run this way).
The gui however adds font and image support, which can be useful if you're sitting at the machine. The error message you get when you invoke 'emacs' from the command line in its default mode, with no arguments, is a diagnostic describing a bug in the mac gui implementation.
The error's still there if you start emacs through the finder; you can see that by running (e.g.)
$ open /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14
which both opens an emacs gui and a terminal window containing the program's text output.
As it says in the message, 'this may break in the future'; it's not helpful to say 'you're using it wrong.'
Can anyone explain these three debug symbols on VSCode I have found on the internet?
My vs code has the one with the play icon.
All demos online on debugging have the one in the middle. How do I get that?
Also, node js debugging is installed but I think it shows as disabled, with no option I can find to enable it.
To answer your question directly [TL;DR]: you already have it if you are using the latest version of vscode. It will take you to the same view as the one on the right
If you look at the codicon libray ref the middle one you pointed out is not present.
Visual Studio Code made changes in February 2020 ref that incorporates running and debugging to be something more harmonious:
User studies revealed that new users have difficulties finding how to run their programs in VS Code. One reason is that the existing "Debugging" functionality is not something that they relate to "Running" a program. For that reason, we are making "Run" more prominent in the UI.
The main menu Debug has become the Run menu.
The Run and Debug view has become the Run view and the corresponding Activity Bar icon now shows a large "Play" icon with a small "bug" decoration.
So in other words, there is no difference. The 'Run' and 'Debug' view is synonymous and the icon reflects those changes. As they noted, the Debug view is now called the 'Run' view, but it still offers debugging and breakpoints.
There are 2 possibilities you are running into however:
The tutorials and guides you are using are out-dated (showing an outdated version of vscode)
The tutorial or guide is using an extension that offers debugging capabilities. Extensions have some control over the icon you see
The extension is for single file debugging, according to the June 2020 ref notes, vscode recommends the following:
For debug extensions that want to improve the single file debug experience by adding a "Run" and/or "Debug" button to the editor, we recommend following these guidelines for a consistent look and feel:
Contribute Run and/or Debug commands in the package.json (see Mock Debug):
Use the command titles "Run File"/"Debug File" or "Run Python File"/"Debug Python File".
Use the $(play) icon for Run and $(debug-alt-small) for Debug.
Where their codicon library was updated in June to reflect the following:
As you can see, none of them are prefixed with verbiage like 'run', but they all represent the same functionality.
Additionally, you may see this icon as well:
This represents the panel (view) where the output of your debug will go.
Following on from this question: How to communicate between multiple windows of the same chrome app? and answer, is this why when you are developing an app that you have loaded via 'load unpacked extension' and open a new window using chrome.app.window.create() and then right-click on the new window to 'Inspect Element' you get a new developer tools window and not the one already open for the original window of the chrome app? Or is it a bug?
I ask because its very time-consuming having to switch between the different developer tools windows when I'm actually using Dev Tools (with Workspaces) as the actual IDE for writing my Chrome app (I am not using any other external text editor or IDE)
This is a limitation of dev tools in Chrome. What is being suggested would be pretty cool, but it would need some work that we haven't done.
Just to be clear, different windows do not share the same JS "global context". The quotes are there because the "global context" is a thing, it has a real meaning.
Imagine there are two windows A and B, and they live in the same JS universe. All the objects in the universe are accessible to both windows, if they can get a reference. There will be two window objects, windowA and windowB.
"Global context" refers to which window object unscoped identifiers are looked for in.
When running code in the "global context" of window A, unscoped identifiers will be looked up in the context of windowA. E.g. "foo" will be looked for on windowA.foo. If foo is actually on windowB it won't be found. Put another way, if you create a global variable while running code in the "global context" of window A, it will actually be put on windowA. If you then run code in the global context of window B, you will need to have a reference to windowA to be able to access it.
I hope that makes sense; it is kind of hard to explain. I've probably got some finer points of it wrong as well.
My program works great with windows xp. I am trying to add some more functionality and using OutputDebugString() to show some debug information. works flawlessly on XP. Now when i want to use the same program on windows 7x64. I dont see any output in DebugView.
F1! F1! F1!
Sorry for reviving an old question, but we spent a good couple of days searching the internet to answer this one and eventually ended up logging a connect call. I am posting here to help anyone else in the same situation. Our specific problem was getting the output from OutputDebugString, MFC TRACE etc in the debug output window when debugging an x64, mixed mode application.
According to Microsoft, apparently for debugging x64 mixed mode applications the debugger type of 'auto' (set in the Debugging->Debugger Type property page) defaults to managed rather than mixed. This will need to be explicitly set to 'Mixed' for both managed and native debug output to be seen when debugging a 64 bit build.
There are a number of reasons why this may or may not work. I accidentally disabled this -- here are all the things you need to check to get this working:
Is the debug output text getting redirected from the Output pane to the Immediate pane, thus you are not seeing it? To turn this off:
Debug
Options and Settings
[ ] Redirect all Output Windows text to the Immediate Window
Is the Output pane visible?
Debug
Windows
Output
In the Output pane do you have Program Output enabled?
Debug
Windows
Output
Right-Click anywhere inside the pane
[x] Program Output
Do you have the right Debugging Type selected?
In the Solution Explorer (View > Solution Explorer) pane
Right-click on your project
Properties
Debugging
Debugging Type: change from Auto to either Native or Mixed
Is the debugger tried to get attached before the program has started? To turn Attach off:
In the Solution Explorer (View > Solution Explorer) pane
Right-click on your project,
Properties
Debugging
Attach: change to No
Are you using OutputDebugStringW()? Try using OutputDebugStringA() instead.
Lastly, did you start the program in debugging mode? :-) Hey, you never know!
Debug
Start Debugging (F5)
I hadn't seen a comprehensive list before so the above are all the things I had to verify were set correctly.
3 small suggestions:
make sure you are actually capturing events (top menu -> capture -> capture win32 is marked)
if you program is running in low integrity (does it give a security warning when you are running it) you need to run debug view in low integrity as well. to do that you need to change the integrity level of dbgview.exe before running it.
if you are using visual studio and running with debugger (pressed F5) then the debug output is actually captured by visual studio (in the output window). try running your program with ctrl f5.
Is there a more detailed error to be found other than the console's EXC_BAD_ACCESS? Where/how can I see it?
When my app crashes, I see the error in thE XCode status bar, but the console shows nothing else. Where do I see more info about what causes the crash?
The application will have a stack trace, typically in the crash logs. Definitely look there for a bit more detail. Look under ~/Library/Logs/CrashReporter for those details. In general, run the application "Console.app" in your Utilities folder, and click on the button "Show Log List". It gives a detailed view into all the logs available that you'd likely want to check out in your system
If it's code you have written, the debugger (gdb) is the "how" to go to look for more detail. That's typically a "you overreleased" some object if you're working in Objective-C. There's a good set of notes on using the technique "NSZombieEnabled" to find what you're blowing up on.